Lately one of the customers expressed the great desire to step on improvement path. They have chosen CMM for a beacon. I appreciated their choice and proposed my help as I was-there-done-that so to speak.
First they have assess as being at CMM2 already which caused a lot of suspicious on my side. First of all, they do not have plans. Even if they do they never follow those. Second, they do not have requirements in any form. Third is the communication. News, issues, problems, goals and the rest are just broad-casted to everyone in hope that a person to whom the message is addressed will somehow guess it. In sum, the whole project performed by another contractor (not my company) looks like a mess or a chaos. The chance that a good product appears out of it is as big as the chance that our country's football team takes the gold in world championships.
I estimated the organization as being at initial level of maturity model and suggested to stick to the selected list of improvements that I like to provide here to your attention. If you have any comments or feedback just let me know. You opinion is important to me.
I sat down and though of the following changes to be made right away. There are no details so far, just a list, so if there is any ambiguity please ask me for the clarification.
a. There must be a plan and everyone must think it’s important
b. Plans must be realistic
c. Risks should be taken into account while planning
d. I can provide a template for the start
2. Product requirements engineering
a. Elaborated before the development starts
b. Reviewed by all parties involved
c. Corrected accordingly to review issues and adjusted to the needs of everyone
d. Numbered uniquely
e. Versioning for requirement documents
i. Throw away, do not evolve
ii. Once you have a solution then sit down and design how to implement it into real product from the scratch!
b. Architecture design prior to coding
c. Module design before coding
d. Review design (peer or by system architect)
e. Continuous code review
f. Test before letting it out (unit or developer testing)
g. Make issues visible by means of metrics, so everyone knows that a failure will be seen to others
a. Test planning
b. Test strategy elaboration (test plan)
c. Test design (test cases)
d. Iterative testing
e. Regression testing
5. Tracking changes
a. Make changes visible to everyone
b. Adjust plans and risks timely
c. Make trade offs
6. Release procedure
a. Feature freeze date
b. Code freeze date
c. Make only really important changes and fix really important issues
a. Communicate the goals clearly and at all levels (let them know the stakes)
b. No broadcasting, there should be one (known to everyone) person to answer a specific question
c. Defined project roles
d. Single points of contact on planning, requirements, development and testing
e. Reporting and metrics
f. Periodic team meetings (Skype, phone calls)
g. Focus the team on one thing at a time
Look forward to your feedback!