Thursday, December 9, 2010

The CMMI seems to be for Project Managers. Is there anything for developers or development teams?

Dear Appraiser,

Is there anything in the CMMI for developers and development teams?  It seems focused on project management.

Oh, I always thought only Project Managers cared about process improvement!  hmmm let me think about this for a second . . . . YES!  Turns out there is a lot for developers and teams.

One of the reasons the CMMI is known for "Project Management" is that Maturity Level Two, often the first step, is largely focused around Project Management.  It isn't until ML3 that we start seeing practices related to technology.

It's important to understand that CMMI is not a methodology (like RUP or XP) so you won't read any chapters in the book that give you specific steps for developing software.  This is OK though, because most teams or companies develop their own home-brew that fits in with their culture, often based on one of the popular methods like XP, Scrum, Crystal, RUP, and so forth.  I have one client whose method is called "xRUP" and it's a hybrid of . . . well, you get it.

But there ARE specific guidelines that you can use to help you detemine what your process should be, and more importantly, how to improve on it.  Think of your own process as a v1.0 Release, and then use the CMMI to sprint your way toward v2, v3, and so on - making it better as you go.

Check out the following Process Areas for developers and teams:

Technical Solutions (TS)

TS offers guidance for picking the right technology and tools, developing interface designs, designing software. developing programs, and appropriately documenting your work.  It's "methodology agnostic" so agile methods, traditional methods, or any other approach works equally well.

Product Integration (PI)

PI is helpful in guiding us how our process should handle compilation, integration, and deployment of our software into a production environment, or delivering it to a customer.  It covers interface testing and monitoring, customer documentation, deployment sequence, and a lot of other cool stuff.

Integrated Product and Process Development (IPPD)

IPPD is sandwiched in as Goals within IPM and OPD and covers the team aspect of your development work.  Setting project vision, making sure everyone's roles are defined (who is the ScrumMaster, who is the Product Owner?) and setting rules of engagement between teams.  It's good stuff!

Validation (VAL)

Guidance for how your process creates validation environments, processes tests, reacts to test defects, and communicates the results.  Pair programming fits in here, unit testing, environmental and performance testing also.

Verification (VER)

Guidance for making sure all of the requirements, features, and user stories have been produced in your code.  It also covers peers and code reviews.  Scrum Demo, Fagen Inspection, User Testing, Traceability all fit in here.

Requirement Development (RD)

This is a great PA.  The usual stuff for eliciting needs, and interating through customer meetings.  But also great guidance on how to reduce defects in the requirements by using some pretty robust validation techniques.  Prototyping, proof of concept, use cases, user stories, and the like all fit in here.

So, that's all there is related to software developers and teams.  Think of it as a model for how the greatest development teams behave and don't over-do it!

Good luck!

1 comment:

Unknown said...

Hi, i used to take User Testing as an example of validation and Unit testing as an example of Verification. However, in this blog it has been mentioned the other way round. I am confused now. Can you please clarify?