分类：
2010-11-30 09:17:35
It's pretty rare for a software development project to go perfectly. In fact, although developers tend to have eternal faith that the next project will succeed completely according to plan, I can't think of a single project that I've been involved with over the past 25 years that went off without a hitch. Dealing with bugs, sudden requirements changes, hardware and software that break down mid-project, unexpected personnel turnover, baffling interactions between components, malevolent servers, and incompetent subcontractors seem to be the order of the day. The question is not so much whether you'll get hit with something unexpected, as how you'll deal with it - and what you can learn from it for the next project.
The difference between average programmers and excellent developers is not a matter of knowing the latest language or buzzword-laden technique. Rather, it can boil down to something as simple as not making the same mistakes over and over again. Fortunately, there's a powerful tool that any developer can use to help learn from the past: the project postmortem.
Though the name is well-established by now, "postmortem" has somewhat unfortunate connotations. The purpose of a good software postmortem isn't to carve up the corpse of a collapsed software project so as to assign blame for failure (though in dysfunctional organizations postmortems get used this way anyhow). Rather, the goal is to build up an institutional memory and develop a set of best practices that work for your own organization by meticulously recording what went right and wrong over the course of a project.
The difference between an organization with a culture of postmortems and one without can be dramatic. This is probably in part because of the good effects of postmortems, and in part because companies that lack the discipline to perform postmortems tend to be at a rather chaotic level of practice. When postmortems are institutionalized, you'll find people saying things like "we organize our source code tree this way, because we've found in the past that it works well" or "we stopped using that particular risk assessment practice because it just wasn't giving us any useful information." Without postmortems, developers are more likely to invent techniques as they go along, without much regard for what may or may not have worked in the past - and more likely to be surprised when something fails for the second (or third, or tenth) time.
Like most other organizational changes, effective use of software postmortems can't be mandated from above without employee understanding of the benefits, and it's very hard to sneak in from below without management support. But management can go a long way to create a welcoming environment for postmortems, and developers can educate management about the benefits. If you're not already using this practice in your own organization, you can start any time - as soon as your next project ends, in fact.
While it's impossible to give a single set of rules that work for every development organization, there are some things that (in my experience, at least) make software postmortems more effective. If you're starting (or refining) a practice of postmortems, you may find some useful advice here.
1. Plan for Postmortems - Your project plan should explicitly set aside time and space for the postmortem. To get the most value out of this activity, you need to take it seriously; people need to have time to think without being thrown immediately into the next project. The postmortem should be a scheduled activity, with time for a meeting of the team to discuss the lessons learned and time for someone (or some group) to write the postmortem report. If you can finagle a nice off-site conference room for this, so much the better; a little physical (and psychic) distance from the day-to-day workspace seems to help some people see more clearly what they spend their regular workday doing.
2. Keep it Close in Time - Don't let memories fade by scheduling the postmortem too long after the end of the project. Ship the software, have the celebration, and then roll right into the postmortem, rather than waiting for a convenient break in the action (which never comes, anyhow) a month or two later. On longer projects (anything over a couple of months), you need to encourage people to keep notes towards an eventual postmortem, or hold a series of mini-postmortems at milestone dates, lest things get forgotten.
3. Record the Project Details - Part of the postmortem report needs to be a recital of the details of the project: how big it was, how long it took, what software was used, what the objectives were, and so on. This is not padding, but a way to help people looking for applicable experience in the future. If you build up a library of dozens of postmortems, a team about to embark on a 5-person, 6-month effort can use the project details to look for similar projects that the organization has tackled in the past.
4. Involve Everyone - There are two facets to this. First, different people will have different insights about the project, and you need to collect them all to really understand what worked and didn't. (In the worst of all possible worlds, the postmortem gets written exclusively by two or three top managers and is worthless except as a pat on the back for management). Second, getting everyone involved - by requiring their attendance at a meeting, if necessary - helps prevent the postmortem from degenerating into scapegoating. It's a lot harder to grouse that "Bob always screwed up the build" if Bob is sitting right across the table - and a lot easier to look for the more important lesson (in this case, likely something to do with the fragility of the build process).
5. Get it in Writing - The postmortem effort will usually kick off with a team meeting (unless the team is very small; fewer than 5 can probably conduct a postmortem entirely in e-mail), but it can't stay there. If it doesn't, you've got a bull session that will soon be forgotten, not a postmortem that will inform people in the future. The project manager needs to own the process of reducing the postmortem lessons to a written report, delegating this if necessary.
6. Record Successes as Well as Failures - Unless your project was an unmitigated failure you need to spend time recording what went right as well as what went wrong. It's easy for a postmortem to degenerate into a blame session, especially if the project went over budget or the team didn't manage to deliver all the promised features. But people need to hear positive messages as well as negative ones, and they need to hear what things are worth repeating as well as which things are worth avoiding in the future.
7. It's Not for Punishment - If people think you're using the postmortem to plan salary cuts or firings, or otherwise hang the blame for a failed or suboptimal project, they'll lie about what happened. It's as simple as that. If you want honest postmortems, management has to develop a reputation for listening openly to input and not punishing people for being honest. And the way to get that reputation is by not punishing people. (Of course, no one ever objects if the postmortem identifies some superior performers who get a bonus. Nobody ever said life was fair for managers either.) If possible, try to juggle the schedule so that postmortems and annual reviews don't come too close to each other.
8. Create an Action Plan - Step 1, meeting; step 2, written postmortem. Don't let it stop there! There should be a step 3: action plan. The written postmortem should make recommendations of how to continue things that worked, and how to fix things that didn't work. Remember, the idea is to learn from your successes and failures, not just to document them.
9. Make it Available - A software postmortem locked in a filing cabinet in the sub-basement does no one any good. Good organizations store the supply of postmortems somewhere that they're easily found. If you're the one responsible for producing one, you should consider sending out an e-mail at the end of the process saying something like, "The XYZ project postmortem is finished and available at \servershare. We recommend that future teams do a, b, and c and avoid d, e, and f. For more details, feel free to read our whole postmortem."
Software postmortems, performed consistently, are a key part of bringing a development organization from chaos to smooth, repeatable functioning. In fact, if your development efforts are completely disorganized, postmortems can be a great way to start turning things around, because they will help you identify and keep the good parts while finding and throwing out the bad parts. If you're not already using this essential tool, it's never too late to start.
Mike Gunderloy is the Senior Technology Partner for , a Washington State consulting firm. You can read more of Mike's work at his Web site, or contact him at .
chinaunix网友2010-11-30 11:06:40
项目反省会可以团结团队成员，给每位TeamMember一个反省自身和反省团队的机会，提供每位TeamMember一个为团队提出改进建议的平台，让每位TeamMember对团队增添一份责任感、归属感和主人翁意识。
