--Originally published at Ce qui est chouette
This post will cover Chapter 17 & 18 & 19 of Software Project Survival Guide and Chapter 8 of The Pragmatic Programmer.
Let’s get to wrapping. To wrap up first hold a change board meeting at the end of each stage that includes the whole staff to evaluate changes that were deferred during each stage. Wrap-up is time to recalibrate estimates, see if milestones were met, whether necessary tasks were omitted, and in general if the project scope still aligns with the estimated at the start.
Evalutate performance against the project plan, whether the team performed technical reviews, kept track of progress and follow the plan. If the plan wasn’t followed, see why, if the plan resulted impossible to follow, replan.
To fully conclude a stage archive the environment that was used to create the software, in the future the team might need to recreate the software at a certain stage, and collect data into logs to serve as reference for future work and estimates. This is stored in Project History.
At the end of the project as a whole, gather all the data you can, e-mails, summaries, and most important, subjective opinions of team members. Hold a meeting, why not? Everybody loves meetings. In it, team members will discuss candidly their insights; a questionnare can be an alternative to this meeting.
To complete the Project History Document include both objective, quantitative information about the project and the team’s subjective, qualitative impressions. Now this document will serve as reference. For full reaping of this document in the future, conclude it in the following two ways: create a planning checklist based on the work done for the project and add the major risks to a general Top 10 Risks List template.
To fully conclude, a list of Do’s.
- Create and follow a Software Development Plan.
- Empower project personnel.
- Minimize the bureaucracy.
- Define the requirements baseline, and manage changes to it.
- Replan when necessary.
- Reestimate system size, effort, and schedule periodically.
- Define and manage phase transitions.
- Foster a team spirit.
- Start the project with a small senior staff.
Now onto the Don’ts:
- Don’t let team members work in an unsystematic way.
- Don’t set unreasonable goals.
- Don’t implement changes without assessing their impact.
- Don’t let additional complexity creep in.
- Don’t overstaff.
- Don’t relax standards.
Onto the last Pragmatic advice. This time it’s pragmatism for the whole team. Teams should be divided based around functionality, some team will cover a certain subsystem defined in the architecture, another will serve as the change board, and so on. Automate everything that must be done systematically, people aren’t as efficient at standard procedures as one may think. Leave testing and installations to machines. Design a test case that can be performed without any human intervention, this way test can be performed more frequently.
No phase can be counted as done until it passes every test designed for it. A fun but risky way to assure a module, class or routine is fully done is to design a project saboteur, to branch out their version of the current software and introduce bugs to see if the automated testing will catch it. Regarding bugs, once a developer finds one, they should make it their mission that no one else finds that bug, put it under change control to be dealt with.
On documentation, it should be done in parallel to development. Each module should be accompanied by its respective documentation, in code and in a separate markup language document, signed by its developer in some way, be proud of your work, developer.
This is it, the about guy