Ken Sipe
St. Charles, Missouri, U.S.
oFTEn ThE BEST ThIng a software project manager can do is set the vision, set the priorities, and get out of the way. Here’s a true story about a man named Tim.
We found we needed another team member on our project, so we posted the opening and began to interview. One individual soon rose to the top of our candidate list.
His name was Tim. Tim stood out significantly from the other applicants, and it would have been a “no-brainer” decision to hire him. But, there was one dissenting vote. All resources hired into our department may rotate between any one of three project managers. One of those PMs had previous experience working with Tim and indicated that he lacked motivation. She painted a pic- ture of Tim web surfing regularly while on the job, and being a slacker.
This was a tough situation. When making a hiring decision, more weight would normally be applied to a project manager’s personal experience with the candidate as compared to a cold interview. However, from a technical perspec- tive, Tim’s skills significantly exceeded those of other candidates. He was hired despite the dissenting vote. The project was run using an agile development methodology, so we had an open meeting at the start of the iteration.*
The opening meeting has several main purposes:
1. Stories? are created and their priority is established and communicated, based on user input.
* Iteration: A short period of time chosen by an agile project team (a week, two weeks, a month, etc.) during which a key requirement chosen by the customer will be developed, tested, and then delivered to the customer for approval or comment. The next iteration will then begin to develop the next most important requirement and/or correct the work done in the preceding iteration.
? Story: A high-level description of a software requirement, usually broken down into single devel- oper tasks, with just enough information to allow a developer to estimate how long it will take to create, test, and/or implement it.
?
???????????????2. A team vision of the project scope is created through the stories, and good acceptance criteria are established.
3. Stories are broken down into tasks and estimated by the developer who is to complete the task.
After the meeting, the tasks are entered into the task tracking system. The significance of the task tracking system is often misunderstood. It is used for developers to see what tasks are started. If they have finished their own tasks early, they move on by “stealing” (or completing) a task not yet begun by the originally assigned developer.
Tim turned out to be an outstanding hire. He out-produced everyone else on the team. The most obvious measure of his value was in the number of tasks he “stole” from other developers. Completing more tasks meant the project finished quicker.
So the question is, why would another PM see Tim as unproductive? On closer inspection, it became evident that the Tim-basher had a management style that was excessively controlling. She would “spoon-feed” tasks to developers and then leave the team workspace to attend meetings. Tim was so fast that he would complete his assigned task immediately. Without any further direction regarding project priorities or tasks he could begin next, he was left idle.
You’ll be amazed what a good team can do with a clear vision, well-defined acceptance criteria, and shared project priorities not determined by a lone software project manager but known, documented, and managed by the entire team. Sometimes the best thing for the PM to do is get out of the way. Do you manage a Tim?
Empowering Developers: A Man Named Tim
原文地址:http://blog.csdn.net/wangzi11322/article/details/49401313