carfield.com.hk

project management.txt

2018-06-06T03:59:50Z

Linus share about project management, most importance is people, and also discuss about tools, how to collabrate people and how to delegate - http://h30565.www3.hp.com[..]Software-Development-Management/ba-p/440

Only the programmer who is going to write the code can schedule it. Any system where management writes a schedule and hands it off to programmers is doomed to fail. Only the programmer who is going to do the work can figure out what steps they will need to take to implement that feature. - http://www.joelonsoftware.com/articles/fog0000000245.html

Never, ever let managers tell programmers to reduce an estimate. Many rookie software managers think that they can "motivate" their programmers to work faster by giving them nice, "tight" (unrealistically short) schedules. I think this kind of motivation is brain-dead. - http://www.joelonsoftware.com/articles/fog0000000245.html

Micromanagement or Macromanagement? http://boncey.org/2006_10_29_how_to_mentor_programmers

But, unfortunately, as a general rule, Project Managers have no training. Even if they do have training in the form of an MBA, MBA education is impractical and useless; the academic community has completely failed us in this respect. Furthermore, Project Managers are more often based on personal friendships and company politics; they are rarely based on management skill.
And, finally, most managers do not acknowledge that management is a skill that they must study and learn so they don't study or learn it.

http://discuss.joelonsoftware.com[..]DiscussTopicParent=8469&ixDiscussGroup=5

An explanation of agile, I think it is more about project management - http://blog.objectmentor.com/articles/2007/04/23/short-reach

Some common problem of software project management - http://ajaxwidgets.com[..]thomas/9_reasons_why_software_project.bb
http://ntschutta.com[..]ou-know-your-project-is-in-trouble-when/

http://www.goodproductmanager.com[..]roduct-management-vs-project-management/

Brief description of thoughtworks codejam - http://blog.nona.name/200804274.html

Listen first. Measure later. http://digerati-illuminatus.blogspot.com[..]gspot.com/2008/05/measure-or-listen.html

Paper of burn up and burn down - http://alistair.cockburn.us/Earned-value+and+burn+charts Per my understanding, we can say burn down is push by management where DEV work as task consumer and completing per define tasks within limited time; where burn up work in the other way round.

Why rewrite usually bad - http://www.jroller.com[..]astianKuebeck/entry/why_version_2_0_will

Why need to manage user/client - http://dreamhead.blogbus.com/logs/48408290.html

The blog list several software projects fail case study - http://www.codinghorror.com/blog/archives/000588.html

The law of late project - http://www.commonsense4commonpeople.net[..]et/2009/11/the-law-of-late-projects.html

Friendship, what make one big team working - http://blog.objectmentor.com/articles/2010/04/26/pair-management

On an Agile Team, a person is removed from the team by assigning them work. - http://www.agileadvice.com[..]e-between-agile-teams-and-project-teamd/

Some say an method "Impact Mapping" is very useful - http://mysoftwarequality.wordpress.com[..]com/2014/07/15/complexity-is-the-excuse/

Transfer project to products - https://www.infoq.com/articles/transform-projects-products

Frequent planning - https://www.jrothman.com[..]can-lead-to-short-and-frequent-planning/

version.txt

2015-10-15T07:28:11Z

Semantic Versioning 2.0.0 - http://semver.org/

owner.txt

2013-10-24T02:54:18Z

Product Owner’s Rule #1: Don’t do everything alone
Product Owner’s Rule #2: No rush
Product Owner’s Rule #3: Spread the knowledge, use diversity, delegate
Product Owner’s Rule #4: Learn and try new things

http://www.targetprocess.com[..]/blog/2013/02/product-owner-retires.html

How facebook manage code ownership - http://swreflections.blogspot.hk[..]/code-ownership-who-should-own-code.html

Product owner checklist - http://larelekman.com/productownerchecklist/

A Tale of Two Terminals.txt

2011-01-16T16:44:41Z

1. Cutover to any new system should be in small increments. Impossible? Don’t give up on increments too quickly – and don’t leave this to “customers” to decide! The technical risk of a big-bang cut-over is immense. And it’s almost always easier to divide the system in some way to facilitate incremental deployment than it is to deal with the virtually guaranteed chaos of a big-bang cutover.

2. Simplify before you automate. Never automate a work process until the work teams have devised as simple a work process as they possibly can. Automating the right thing is at least as important as automating it right.

3. Do not freeze work design into code! Leave as much work design as possible for work teams to determine and modify. If that is not possible, make sure that the people who will live with the new system are involved in the design of their work.

4. Rehearse! Don’t just test the technical part, include the people who will use the new system in end-to-end rehearsals. Be prepared to adapt the technical system to the social system and to refine the social system as well. Be sure everyone knows what to do; be sure that the new work design makes sense. Leave time to adjust and adapt. Don’t cut this part short.

5. Organize to manage complexity. Structure work around work teams that can adapt to changing situations, especially if the environment is complex, could change rapidly, or is mission critical. At minimum, have emergency response teams on hand when the new system goes live.

http://www.leanessays.com/2011/01/tale-of-two-terminals.html

project status checking.txt

2009-12-08T00:42:14Z

Can everyone on the team write the aim of the project on a post-it note with a thick flip-chart marker? If not, then the end game is not clearly defined and universally understood.

Come up to a colleague and say ‘can I ask a favour?’ just to see how they will react. If you get told off, the person is probably not very happy about the work. Richards advised building teams with “those who say can” , even when they are dealing with problems. Such people will improve collaboration and team spirit on the team.

When a phase of project is officially done, ask yourself “is it safe enough to move on?”. If this question gives you a bad gut-feel, you aren’t done yet.

How many of your projects ended with a serious project review? This is, according to Richards, crucial for organisational improvement, preventing repeated mistakes and sharing knowledge between teams.

How would people on the team feel about the customer saying “I’ve changed my mind”. If the response is negative, the system isn’t as flexible as it should be.

Ask someone for an update on a task and stay completely silent for 10 seconds – don’t do anything to provoke a response. If the other person is unsure or nervous about something, they will start spilling that out. If they too remain silent, things are going OK.

Do you know how much time was spent on testing on your last project / iteration? If you can’t even estimate this, you aren’t collecting good actual measurements of the project. Collecting actual measurements is, according to Richards, crucial for getting to realistic work estimates.

Pick up a document, turn it over and see what’s on the back. If you find diagrams, that suggest the need for clarity as people were drawing on it to explain things.

http://gojko.net[..]chniques-to-test-how-a-project-is-going/

big project.txt

2005-11-28T10:01:35Z

The problem with big projects like Java or rewriting Unix or designing the Sparc chip is that they require a five-year commitment. So when you come right down to it, I had to decide, "Do I want to push this big rock up a hill again?" Not this time.

Bill Gates faced a similar choice with his Longhorn project. He probably has a lot of great ideas and all these brilliant people, but he also has this antecedent condition he has to take into account?Xkeeping it somewhat in sync with the old Windows. So the beautiful vision may fail because it has to be compatible. I've often wondered why they can't, for once, do something new. I mean really, really new? But then, when I asked myself that same question, that's when I knew I had to leave Sun.

http://www.fortune.com/fortune/print/0,15935,490598,00.html