Found this old post I made on Software Process Improvement alomost 10 years back.
I think it is still applicable
After a few months of lurking finally decided to de-lurk and contribute my 2
Some more guiding principles I would like to add (or duplicate in some cases)
1) The CMM is not a substitute for common sense. This should be repeated over
and over again. If something doesn't make sense in your context, don't do it
even if the CMM says so. However be very clear on why it does not make sense.
2) Concentrate on the goals of the different KPA's and use the "activities
performed" as guiding principles to achieve the goals. Don't get hung up on the
activities outlined in the CMM. The important thing is the goal.
3) Start a measurement program right from the beginning, keep it as simple as
possible but ensure that you will be able to measure progress. for the long
term it may be a good idea to try and calculate the return on investment of PI
4) Don't bother too early about how you are going to prove compliance. PI
activities are for internal improvement and not to prove to some 3rd party that
they are being done. Once activities are institutionalized it not a big problem
to demonstrate compliance. ( i have seen in many cases the focus on how to
proove something is being done rather on concentrating how to do it).
5) Get buy in from everyone. Never Never mandate some activity because "CMM
6) Never Never make a CMM level a business goal. A business goal should be a
quantitative goal like "cut rework costs by xxxx" or "reduce org. wide effort
slippage by xx%".
7) Remember that processes can only help people, they cannot substitute them.
the CMM is only a model and not a silver bullet, so a level 1 org with great
people can consistently produce better s/w then a l5 org.
An excellent book on s/w pi is by kim caputo, I have forgotten the exact title.
This is one of the few books, which talks of the implementation in a practical
way without too much theoretical issues.
Post a Comment