- To track your project. A basic task of any software project manager is to track the project progress. Examples are the defect rate, the size of finished functionality versus not finished. A very good technique which reads this measurement and displays it in a graphical format is the burn-up/burn-down charts which are heavily used in Agile development.
- To improve the process of producing software. Very similar to six-sigma projects, CMMI level 4 and 5 have techniques which starts with an evidence of a mal-functioning process (most commonly supported by measurements).Then, it digs into the root causes, and suggests corrective actions. Finally, it designs measurements to quantify the impact of corrective actions, and start over again. This ‘Continuous Improvement’ cycle is one of the techniques used in any engineering discipline.
Wednesday, August 19, 2009
Wednesday, August 12, 2009
- Motivate the team to work towards achieving better measurements.
- Motivate the team to record measurements more accurately.
- Get the team to the point that they trust the value of the measurements as a means for project management, and as a means for process improvement.
- More process Patterns, by Scott Ambler.
- Rapid Software Development: Taming Wild Software Schedules, by Steve McConnell.
Sunday, February 8, 2009
Sometimes we here some devastating (yes literally devastating) ideas like:
- Process is pure overhead.
- Process is discovered while working on the project (after we start the project).
- Let’s start coding, we will refactor anyways.
- Just jump in the code, things will get crystallized as you go.
The problems of such sayings is that it tempts poor developers to start a project with the unhandled risks inherent in the software development endeavor.
Famous processes like RUP markets for itself as “a risk removal process”. Agile methods assume to mitigate many risks of software development, even if not having a list of risks which we keep an eye on, which is true in my humble opinion.
The fact of starting a project without a clear view of how to do configuration management, how to do estimation, how to document requirements, how to involve stakeholders and get feedback on requirements, when and how to test, what are the bugs types, and which of them are to be fixed first, how, when and by whom architecture and design is going to be done, how to do tracking and what measures will indicate progress, how you will handle change, and many others. The fact of starting the project without a clear answer of such questions is pure act of failing the project, causing some persons to suffer sometime of their lives and get disappointed and demotivated at the end of the way (the developers), and causing others to lose some money, lose business opportunities, and lose trust in software development teams (the customers).
I hope this is a clear answer to the question. Please take some time and think of how you will develop software before you take the responsibility of any projects.
The next question is: Does process limit develop creativity? This needs a separate post.