这学期教一门软件度量课程，学生基本都是有多年业内经验的在职软件工程师和管理人员，每周我们会找一个专题讨论。上周的问题是关于CMMI度量与分析（Measurementand Analysis）过程域的一个问题，大家根据各自的经验，巴拉巴拉的讲了很多不错的体会。我注意到一个同学，在别人讲的时候，表情各种丰富，一副内心戏十足的样子，所以特意点将让他来分享下。
然后，就开启了这哥们儿的美式吐槽模式。多年前他在某家军工企业工作，CMMI的实施让他觉得痛苦不堪，在结束发言时他说：讲真，我宁愿到快餐店做汉堡，也不愿在这样的CMMI的软件企业里写软件。
很明显，他对CMMI的理解是错误的。但错不在他，而在于错误的CMMI实施方式。CMMI是一部常常被念歪的好经，它没有要求我们把简单的事情复杂化、没有逼着我们做违背常理的事。可惜许多人在几百条实践里面挣扎时，没有跳出来理清楚它们的目的是什么？没有考虑到在你的组织、部门、项目又如何体现？没有关注能帮助你解决哪些实际问题？
当你把模型当成过程来理解，当你把子实践也当成标准来落地时，那么恭喜你，你成功的把CMMI做到了骨肉分离。
这位同学讲完估计意犹未尽，把发言整理了一下，邮件发给了我，对于我这种懒癌症患者，实在懒得翻译了，大家凑合看吧。
The question,simplified, seems to be, "If you perform only the specific practices in MA via performing the checklist of tasks, will the MA requirements be met? Why/Why not?"
Well, the short answeris no. Why? From what I remember about CMMI it's not simply enough to go through a list of specific practices and participate in the activities; you have to actually meet the goals and every process area is connected to generic goals and practices as well as specific goals and practices.
But the real question is: Who cares? CMMI is the bane of my academic and professional existence.There is no concept in the programming and project management world that has caused me more anguish. It's a disgusting waste of time and energy and has absolutely no logical use outside of the small handful of government-related entities and large corporations who are using it and have been for a very long time. It's a product of military thinking and it's honestly just the worst type of bureaucratic trash I've ever had the displeasure of studying. Any framework, process, practice or paradigm that requires a 600 page manual to vaguely (and poorly) explain is useless drivel. I am a staunch supporter of Agile methodology and thanks to our group project I've really started to like what I'm reading about Lean as well.
Software engineering, in my view, works best on a very small and modular level. When we start introducing enterprise management architectures that are focused on the holistic view of the business as a whole, it threatens to rob programming and architectural design of the artistic values that make them worth pursuing. Software development's appeal for me is its ability to work in a hive setting; every project can be compartmentalized into small projects that connect with each other to form a larger entity (which can be extended infinitely).
A software team should be guided by a paradigm that is simple, procedural and scalable. Don't get me wrong, CMMI has all the right ideas. Where it fails miserably is by defining them ad nauseam and creating a sub-process wherein learning and following the various activities described in CMMI is, in itself, a huge investment of time and energy. Imagine this analogy:
You have a huge collection of photographs from years worth of vacations and you have finally digitized every file and have them stored on your computer. Being images with no meta data, you find that it's a bit difficult to pinpoint a specific group of images to show to your friends or print, etc. To make things easier you decide to organize the images into folders. What's the best way to go about this? The images span 10 years from 2007 to 2017 so perhaps you could create 10 folders (1 for each year) and then create 12 folders in each of those for the 12 months of each year. You'd end up with 120 folders, 2 levels deep.It might be a lot easier to find images from a particular year and month.
That helps if you're looking by date but that metric may be less important to you; it might make even more sense to organize your pictures by what is actually in them. You could create folders for outdoor/indoor images, portrait/landscape images, images of people, images of scenery, images that are most one color ...there are limitless ways you can categorize the images. After a few hours of sorting and analysis you may find that your 120 folders have expended to a few thousand folders, a few hundred levels deep. Now, even though your images are meticulously categorized by year, month, orientation, size, content, color and several otherfactors, you've actually created more work for yourself because each picture is too compartmentalized to be easily found. All the pictures from one short trip may resides in 30 different folders not connected to each other.
This is what CMMI is to me. Good concepts are broken down into pieces too small and too defined for their own good. Rather than having a generic process that implies many of the necessary practices to succeed, CMMI attempts to micro-manage itself into utter uselessness. The learning curve alone means that CMMI is very much a "Members Only" club where anyone not already familiar with it is basically a bad investment from the company's perspective. Training new individuals is a huge cost that many companies under estimate; not only are fresh employees less productive but the experienced employees that train and guide them become less productive until the fresh employees are fully competent.
So the question, for me, is a bit of an insult because my sincerest answer is simply,"Who cares? Why are we talking about CMMI? I'll flip burgers before I go back to working for a contractor that has to deal with that mess, I did my time with the Department of Defense and I'm not planning on going back."
推荐阅读
1.软件开发过程的迷茫
2.是敏捷还是精益？
（本资讯于2017-10-13首次发布）
