Wednesday, April 22, 2009
Enterprise Architecture: CMMi is evil...
Is the goal of CMMI to create consistent suckage...
How many times in your career have you ran across an enterprise architect who is an employee of a Fortune enterprise where they were advocates of CMMI?
Long procedure documents full of obvious statements are evil, because they distract the reader with trivial details. Therefore nobody will read them more than once, and most people will not read them at all (with the exception of folks doing Indian Outsourcing and others who have zero clue about anything).
Of course one cannot simply state that CMM is evil. Making that statement without an auditable artifact flow is against evil best practice. Please create an Evil Requirements Definition document to be submit to an Evil Review Committee as directed in the Evil Development Life Cycle Manual. Once you have obtained the appropriate signatures of the Evil Personnel, you can begin to prepare and Evil Design Document that must be reviewed not once but at least twice. Once you have completed and Evil Preliminary Design Review and an Evil Critical Design Review and again received the necessary Evil Signatures, you can begin to develop your Evil Statement. Once complete, you will have to submit your Evil Statement to an Evil Independent Test consisting of testers who do not know what Evil is but have read through your Evil Requirements Definition.
Of course, you can be Agile and Evil. Evil is flexible. Feel free to generate your own tailored versions of the thousands of pages of standard Evil Procedures. These will be carefully reviewed by the Evil Process Waiver Committee and rejected after wasting even more time and effort.
| | View blog reactionsHow many times in your career have you ran across an enterprise architect who is an employee of a Fortune enterprise where they were advocates of CMMI?
Long procedure documents full of obvious statements are evil, because they distract the reader with trivial details. Therefore nobody will read them more than once, and most people will not read them at all (with the exception of folks doing Indian Outsourcing and others who have zero clue about anything).
Of course one cannot simply state that CMM is evil. Making that statement without an auditable artifact flow is against evil best practice. Please create an Evil Requirements Definition document to be submit to an Evil Review Committee as directed in the Evil Development Life Cycle Manual. Once you have obtained the appropriate signatures of the Evil Personnel, you can begin to prepare and Evil Design Document that must be reviewed not once but at least twice. Once you have completed and Evil Preliminary Design Review and an Evil Critical Design Review and again received the necessary Evil Signatures, you can begin to develop your Evil Statement. Once complete, you will have to submit your Evil Statement to an Evil Independent Test consisting of testers who do not know what Evil is but have read through your Evil Requirements Definition.
Of course, you can be Agile and Evil. Evil is flexible. Feel free to generate your own tailored versions of the thousands of pages of standard Evil Procedures. These will be carefully reviewed by the Evil Process Waiver Committee and rejected after wasting even more time and effort.
