CMMI与Agile敏捷开发比较之二：需求管理篇（兼谈用敏捷实现和满足CMMI的ReqM过程域）
作者：陈勇
出处：blog.csdn.net/cheny_com
这是CMMI与敏捷开发比较系列的第二篇（之一，之二，之三）。
CMMI
前面在提到CMMI与敏捷的根本差异时提到CMMI是美国用于筛选其供应商的，而其项目的特点也在于大型团队/强分工/长周期，这样就不难理解CMMI为何提出了以下要求（基于CMMI V1.1）：
- GP1：管理需求
- SP1：与客户达成一致理解
- SP2：取得开发团队的承诺
- SP3：管理变更
- SP4：追溯不同层次的需求关系
- SP5：追溯需求与后续工作的关系
笔者之前做过一些军工项目，所以对军工项目有所了解，以下这些词汇在军工项目里边是非常关键的：甲方乙方，系统工程，预算，结帐，多个供应商联合开发，集成，验收……因此：
- SP1/SP2带有很强的甲方乙方买卖的色彩
- “一致”“承诺”是在买卖合同语境下无奈之举，在外包环境中无论做法如何都是必要的。
- 不应在企业内部开发中也过度强调，比如在自主研发中实施产品经理/开发团队签字等“仪式性”举措。
- SP3/4带有很强的系统工程的色彩
- 就是每个项目多半是一个软硬结合的大系统（比如一种型号的飞机），很少有一家企业能完全包揽。Telelogic有一个工具叫做DOORS，其主要客户群就是制造业（包括军工），其核心思想不是敏捷中的那种条目化的需求分析及跟踪/优先级排序（也有），而是系统需求逐级分解/层层对应：整架飞机可能十年前设计的，但今天组装起来，不少一个零件，不多一个零件。在大型系统工程中，按部就班地完成事先预想保证项目成功的必要性远远超过创新性（尤其是飞机已经定位好了，但几个程序员在开发过程中因为“被激励”了所以想进行创新……这在军工项目里边是不可思议的，他们应该以更受控的方式参与创新）
- SP3突出了在跨企业研发的语境中，一个变化应该被多个可能受到影响的企业理解和实现
- SP4则突出了多个企业开发，却“不多一个零件，不少一个零件”
- SP5也带有系统工程的色彩
- 阿波罗计划有2万家企业的30万人参与，11年完成，这里边就有一个“他们在干什么”的问题，以及“他们能按时完成吗”“有没有漏掉什么需求”的问题
从这一点看，在大型系统工程中，CMMI作为其“神”而存在是很恰当的。尽管有很多人强调军工/航空航天也能应用敏捷开发，但这和Intel说自己参与了奥运会因为奥运会用了Intel Inside的电脑一样，只是“形”和配角而已。笔者认为推广敏捷开发的同好们不应该追求这种虚荣，而是应该在自己擅长的领域先把事情做好。
另一方面，如果实施CMMI的企业并非处于上述语境中，应该恰当地选取适合自己的实践。
敏捷-Scrum与XP
仅从需求管理的角度看，可以排一个顺序：CMMI-Scrum-XP，越往前越强调可追溯性/一致性，越往后越强调创新型/灵活性。这个倒没有好坏之分，而是我们想要什么的问题。
Scrum中对需求管理的解决方法与CMMI的要求很相似。注意这里的用词：对Scrum，是一种具体解决方法；而对CMMI，是一种要求。不过CMMI的要求还包括一些GP（Generic Practices通用要求，主要包括计划，角色与技能，记录，对记录的管理等内容），因此不能认为实施了Scrum就满足CMMI的需求管理了（满足CMMI3的含义就是：如果没有别的限制，任何时候都可以参与美国国防部招标了）。
下面是用敏捷方法来满足CMMI要求的一些对应。
- GP1：管理需求
- SP1：与客户达成一致理解
- 敏捷对需求的理解，较少提到合同的死条文。敏捷假设你已经告诉我你的商业价值，而我正是要交付这些价值。
- 在Scrum中未提及太多与客户进行需求沟通的过程（这个不等于Scrum要求“不要管理与客户的需求沟通”，只是“我不管”的意思）。在XP中提到了现场客户的解决方案，不过XP的提法不涉及需求的范围这个至关重要的因素，而是更关注要实现的需求是什么的问题。之所以有这个“明显的失误”，是因为敏捷的创始者（们）绝大多数并不负责与客户洽谈合同，当他们开始介入工作的时候，项目已经进入“遵循（一个令人无奈的）合同”的阶段了。
- 因此在使用敏捷的时候，不能持有“我们已经用敏捷的方法管理与客户的沟通，所以一切应该万事大吉了”的观点，应该补充对需求范围的管理，尤其是在甲方乙方的语境中。需求范围的管理应该基于商业心法，而不是开发心法，在这一点上澳大利亚（SouthenScope方法）/韩国（软件成本估算标准-知识经济部公告）/日本/芬兰都有相应的法律和条文，大致都基于IFPUG或NESMA功能点分析方法（FPA）。
- 具体应用方法：
- 在使用XP的现场客户时，应配合Scrum的PO制度，也就是说由于甲方（也包含内部的甲方）很难找到一个高度足够，而又能天天处于现场的代表，极有可能导致产品在最终验收时被推翻。引入PO可以缓解现场客户的局限性，尤其是如果建立PO团队，可以有效避免现场客户个体的局限性。
- 即使使用现场客户，定期利用Scrum中的评审会，引入客户（含内部客户）的高层参与，保证大方向不偏。
- 如果在甲乙方的语境中，评审会应留下纪要。
- 应该配合早期范围管理，防止需求开发的过程变成需求蔓延的过程。请关注“早期软件成本估算”这个词汇，未来两年中将会出现面向政府行业的中国的一系列国标，也适合其他行业。
- SP2：取得开发团队的承诺
- 这是Scrum和XP尤其前者做得很好的地方，即通过计划会来取得开发团队的承诺。
- 值得注意的是承诺包含两部分，一部分是理解了要做什么，第二部分是要花费多少工作量。因此在缺少充分沟通的情况下，简单地由开发人员提交一个估算请但是不行的。
- 具体应用方法：
- 应确保使用Scrum中的共同估算制度，也就是说承诺是一种在充分理解、集体智慧下的产物，而不是给你一个清单，填多了算你赚，填少了算你赔的赌博。
- 为承诺划定“模糊界限”，也就是使用MoSCoW方法，用一种透明的管理方法平衡冒险、保守、缓冲、激励……等各种矛盾因素
- 承诺的变更管理，既然承诺=理解+工作量，理解变了，承诺就相应变了。
- SP3：管理变更
- 先说一下管理变更的心法，所谓心法，就是做一件事情的时候心里所想的事情。如果变更过程中心法如下，则任何技术管理方法都无解：
- 甲乙方语境：甲方-不用加钱把这功能加上；乙方-价钱工期已定，千万别变
- 内部研发语境：高层-加上这功能但工期别变；乙方-工期快到了，千万别变
- 敏捷既拥抱变化，又迭代期内无变更，其实在一定程度上默认改变了上述语境（但历来敏捷相关文章中都没有说破）。
- 拥抱变化在于如果你感觉变化有价值，又愿意为变化付出，开发团队乐意效劳。因此不能理解为无条件的拥抱，尤其在甲乙方语境。
- 迭代期内无变更在于项目（产品）是有其商业目标的，迭代期内无变更表明在迭代前，应该从商业目标出发做出版本计划，从而保证大家不是跟着某个人的脑子在跑而是跟着商业目标在跑。因此如果PO在之前不正确理解商业目标做出计划，而是认为可以随时变化，是对开发团队工作的不尊重，也迟早会造成项目/产品的失败。
- 关于以上两点另有两篇博文详述。
- 具体应用方法：
- 应配合早期需求范围管理方法（参考SP1中），防止变更过程变成不受控的蔓延过程。
- 应建立长周期的商业目标和版本计划，要变化的是怎么实现，而不是实现什么。在无框架约束下进行变更，是一件非常危险的事情。
- 应使用MoSCoW方法，平衡变更与承诺的矛盾。
- 在甲乙方语境下，变更管理应以商务人员的意见为主。
- 如果是采用XP方法，应引入Scrum的PO制度。尤其是在甲乙方语境下，PO必须是基于企业（供应商）利益思考的，而不是甲方派来的打着“追求客户价值最大化”招牌的卧底。
- 先说一下管理变更的心法，所谓心法，就是做一件事情的时候心里所想的事情。如果变更过程中心法如下，则任何技术管理方法都无解：
- SP4：追溯不同层次的需求关系
- XP中提到的史诗故事-用户故事较好地支撑了这个实践，不过这个和前面提到的系统工程中的需求拆解不是一个概念，两者目的和颗粒度差别很大。
- 具体应用方法：
- 在产品研发语境中，应基于目标客户群（用户建模）和商业目标来导出产品的需求条目和结构，也就是所有功能最后都多少地被某些客户经常使用，并因此促成了采购。有很多产品不断升级但却没有人购买新版本（比如多数人都在用7年前的2003 Office，和更早一点的XP操作系统），就是因为缺少代表产品之神的上级需求；可怕的是无论有没有神，任何产品都能找到需要升级的功能。
- SP5：追溯需求与后续工作的关系
- XP中的TDD和持续集成与此非常相关，因为每次测试和集成，都是对某些需求满足情况的验证和证明。
- Scrum中提到PB的颗粒度较大，到SB中需要拆解为具体任务（也有观点说不拆解的，下详），也支撑了这个实践。
- 具体应用方法：
- 面向用户故事（或者说用户价值，用户需求，PB）来进行迭代评审，而不是开发任务。这也是笔者整体偏向在SB中直接使用PB中的故事而不进行任务拆分的原因，因为一旦拆分了任务，极有可能任务全都完成了，故事却不能交付。
- SP1：与客户达成一致理解
其他说明
CMMI中的GP的满足，敏捷中较少提及（也没有必要提及），比如所需的技能是否有培训等；如果正好在做CMMI，请做好相关记录。
这些GP并不是说不做项目就不能成功，产品就不能热卖，只是说作为美国国防部（DOD）选择供应商，或许Google转身很快，或许IPad很热卖，但我还是很想找个稳当点的公司来造飞机。
这不是方法论之争，只是商业目标造成的价值观差异而已。
点击下载免费的敏捷开发教材：《火星人敏捷开发手册》
