一位同志的心得：
 
CMMI是重量型的开发方法，内容繁多，覆盖软件开发的方方面面。培训并不能让我对CMMI整体有一个很清晰的认识，但对CMMI强调的一些思想和方法，我觉得还是有收获。
这里谈几点：
1. CMMI强调过程标准化及最佳实践，认为最佳实践就是经验教训的积累，而我们经常想当然不加实践的认为某个最佳实践不适合我们，就随意修改，显示是违背了CMMI思想的。
2. 杨老师在课上经常强调的一点:我们不是为了学习而学习，需要通过学习改变我们的行为方式，这样的培训才是有效的。我很认同。那么我想，即使我对CMMI整体认识不清晰，对于我所能认可的一些流程和方法，也需要去应用在工作中来尝试提高我们的效率。这样才不是白参加培训了。
 稍微跑题一点，我最近也看了一些敏捷软件开发和XP的书和资料，里面很多思想和方法与CMMI所强调的完全是相反的。比如它强调个体和交互远胜过过程，另外有些评论也会认为CMMI这种重型方法适合于大型开发项目，对于大多数20人以下团队开发XP更适用。这导致我在学习CMMI时有一种矛盾的心理。
 
 
老杨的回复：
 
谢谢你的心得。写的非常好。好的原因在于你是思考过的。有些听不进去的，你没有提，对你有用的，你就急着了。心得就是这个意思，希望大家可以过滤一下听到的。CMMI和敏捷是两个非常不同的思路，但是他们其实也有相同的地方，而且它们都是有价值的。
 
不同之处，在于CMMI是以工程纪律为基础，要求事情是有依据地开展活动。Agile 的理论是以个人的创意为主，依赖员工自己的经验、积极性和灵活性来体现效能。两种方法的对象不一样。CMMI是考虑如何管理一般（不单单是规模大的）的团队。Agile不关注一般的团队，它假设员工们都是成熟的。这个假设非常重要。在某些情况下，员工可以成熟的快一点，但不是每一个员工都能够是成熟的。所以Agile在某种条件下，非常成功。但是没有成功推广到一般的团队的层面。
 
两种方法一致的地方，在于大家都关注质量。Agile 也要求纪律，但这个纪律是远远比CMMI 灵活的。后果就是，如果员工成熟，能力（包括技术、人际、工作态度）强大，积极主动，团队的沟通畅顺，有默契，Agile 的效果非常好。但是如果员工的态度与能力稍有不及，效果就非常混乱。
 
Agile 是高水平的开发人员，为保持开发人员的主动性，而找到的一个符合他们个性的开发方法。但从过程管理的角度出发，Agile 不是一个过程，最低限度，不是一个完整的过程，他有点像 6 sigma，是一组方法。同时，因为它的成功，依赖某些不一定普遍的员工技能，它的效果不能保证。在使用Agile的时候，员工会开心好多，但是他们不能如CMMI一样推广积累的经验。
 
我从70年×××始从事开发，对于开发的过程与方法，都有一个实际的经历和体会。Agile有其作用，尤其是在满足员工的积极性方面。当年在国外也有一定的成效，这是因为项目经理知道如何利用这个模式。但我认为不是一个可以在现在的中国推广的方法或是过程。
 
谢谢你的支持与兴趣。

 
同志的回复：
非常感谢您的耐心解释，关于CMMI和Agile的问题，我还想再和您讨论几句，希望不会耽误您的时间。
 
CMMI高度强调过程，过程如果能建立完善，那么我们每个人只需要做好自己的事情：需求分析、设计、评审、走查...。而我们每个人更多是一个过程的遵守者，而不是一个创造者，这一点我觉得也是妨碍我理解CMMI的一个原因：缺乏动力（当然CMMI比较复杂也是原因）。
 
而Agile高度强调个体和交互；比如Test Driving Development， Pair Programming等，这些重点活动都是我们可以亲身实践的而且可以亲自主导的，因此我大概读一两本好书，我就能大概把握Agile的思想了，而且急切想在工作中体验。
 
我这里并非主张Agile比CMMI好，因为无论Agile还是CMMI的倡导者都是软件工程界的大师，而且都宣称有非常成功的案例。作为我们这些开发经验不到10年的小兵，在学习这些方法时，遭遇这两种比较对立的思想时，有时就比较迷惑了。
 
您提到“Agile不关注一般的团队，它假设员工们都是成熟的。”，这点我倒不很认同，因为Agile里面Pair Programming的方法就是一个以老带新的方式，并不要求大家都成熟。
我现在的想法倒是不管CMMI/Agile强调过程或个体哪个是对的，我们先去试着做一下我所能理解的一些实践活动，如果能真正提高我们的研发效率，就行了。
 
 
老杨的回复：
Agile 是一系列的方法，比较实在，没有CMMI那么抽象。它离工程活动比较近，开发人员容易理解。而且它的理念，的确是非常符合开发人员所喜欢的。
 
CMMI是一个过程概念，有很多团队之间协作有关的管理理念，对我们中国的情况，的确是比较困难的。我们有一个自然的重技术、轻管理的倾向。所以国外的人觉得我们的管理落后很多。要讨论这个问题的确需要比较长的时间。因为我们“轻管理”所以我们对于了解管理有关的议题会比较困难。
 
你说：“CMMI高度强调过程，过程如果能建立完善，那么我们每个人只需要做好自己的事情：需求分析、设计、评审、走查...。而我们每个人更多是一个过程的遵守者，而不是一个创造者，”对于这句话，我有两个觉得不舒服的地方：
1）你认为CMMI因为强调过程，就会把人变成了一个遵守者。
2）每个人“只需要做好自己的事。。。”
1）这里我们可能把CMMI看成一套规范、限制着我们的行动。希望你留意到我从来不这样看CMMI。
 
CMMI是一系列的最佳实践和这些实践之间的依赖关系。我们要如何利用它，实施他，是我们自己决定的。但是CMMI作为最佳实践，的确提到很多“限制”我们的东西：要有估算、要跟踪需求、要追踪问题直到关闭。等等，很多很多。我们觉得这些都是“限制”，因为我们以前没有考虑过它们。有些人就把他们定在规程里，但是有不明白考虑这些因素有什么好处。反而我只把它们当成有效的习惯。如果我们有这些习惯，我们成功的机会就会大一些。
 
在我们养成这些习惯的过程中，尤其是这些习惯我们不很认同，我们的确觉得它是框框，可能破坏了我们的创造性。但当我们养成了这些习惯的时候，我希望你也可以看像得出来，这些习惯不但没有破坏我们的创造性，反而帮助我们在创造的过程中，可以减少混乱，可以更有序，从而变得更有效。
 
2）这里我害怕你变得“个人自扫门前雪”那就可怕了。我希望你不是这个意思。
“职责明确”这个概念，我们还掌握的不好。我们有主要的任务、职责，我们一定要把他们做好，但也有一些职责之外的任务和义务，一些潜规矩，如评审他人的工作产品，我们需要履行的。这是一个过程的概念，也是一个态度。所以我们不能说，把自己的事情做好就够了。我们要考虑的，是如何把产品做的好，让客户满意。
 
Agile里的一些东西，可以在CMMI的范围之内应用。比如 Test-Driven Development， Pair Programming，都可以在CMMI里实施。CMMI只是一个框架，让大家可以把最佳实践作为过程单元放进去。反而是CMMI的要求，Agile 的人觉得太过分了。比如需求的变更，太频繁，就不要求文档记录。这些事情，在小团队是可以的。但是团队大了，就会发生混乱了。这些都是发生过的。Agile 从来没有大规模地成功过。它的困难，不单单在于一个团队的大小，也在于员工的数量。大项目，需要很多成员，平均水平就没有那么高了。水平，不单单是技术的，比如系统概念，沟通能力，主动性、甚至过程习惯等等。Agile的成功，一定要有有效的沟通，并且有一个明确的、共同的项目目标，大家按这个目标沟通、反馈，同心合力。你看我们的情况，哪一个单位可以做得到？
 
我希望再明确一下Agile对于个人能力的要求。对开发员工，不一定要技术很高。当然如果不够高，不能通过Agile来提高效果是明显的。我说的水平，是员工的成熟度，就是团队建立默契，让工作流程畅顺。同时，也要对领导的能力有要求。他要知道什么是员工可以应付、解决的，不会管的太细。但是如果风险快出现了，（风险会比非 Agile 的团队高）领导要能够及时发现与有效应对。再一个多变的情况底下，又能掌握方向与进展。这个在国内实在是比较少见。
 
其实无论管理的对象是CMMI或是Agile，管理的目的在于“确保成功”，而不是在于“规范行为”。过程的意义，在于提高效率，只能通过“育人”而非“治人”来达到。在这方面，Agile 需要更成熟的员工与管理层，才能成功。在中国，CMMI已经非常难，Agile 更难！
 
其实Agile也要求文档记录的。但是那个记录的方法比较灵活而已。但是上面的情况还大概是对的。有些开发方法从需求分析到编码，都用同一套图标，只是内容不断按阶段变动。这样比较方便。我们要考虑是否需要更详细的记录。如果不需要，就不需要有好几份文档。我的个人意见是，很难完全抛开一些阶段性的文档的。
 
又比如，需求的了解。CMMI要求项目和需求提供者有一致的了解。在项目里也是。Agile 是否也是如此呢？它可能不这样么？但是Agile没有一个规范的活动来达到这个目标。这里，也有如何最佳的沟通的问题。不同水平的员工，就需要不同的沟通方法。CMMI没有限制如何得到一致的了解，只是要求达到一致的了解。
 
对于 Pair Programming 的目标，重点不是以老带新。他是一个任务备份和排错的方法。“以老带新”，是次要的，也可能破坏它的任务备份和排错的目标，比如其中的“新”的备份和排错的能力，就比不上用两个“老”的效率了。请你留意这一点。
 
总之，我们看到有用的东西，就要利用。第一，不要过分被“品牌”欺骗了。第二，我们要清楚“品牌”里面卖的是什么。不要被假“品牌”糊弄了。
 
Agile里面有好东西。这是可以肯定地。但是从过去十多年来的发展，CMM/CMMI的确是软件成熟的一个很大的动力。Agile可能比CMM/CMMI出现的更早，它的效果如何，也是可以查看的。大家不妨对比对比。
 
谢谢你的兴趣与努力。