1 软件工程与敏捷实践

在和小伙伴们聊起敏捷话题时，伙伴们都知道敏捷是好的，大都能参照教科书说出一些内容来。说起敏捷，难免与瀑布流程进行对比，有的小伙伴也能振振有词的说出一些观点，比如“瀑布已经过时、CMMI老一套已经不合时宜”。但问起来什么是瀑布，CMMI是干什么的，就说不出来了。

细想起来，很多小伙伴并没有参与过大的软件工程，特别是在平台型甲方的伙伴，不停的做迭代增量型研发，但通常不会从软件工程的角度去审视自己的工作。

DP哥前些年供职于一家较大型的日资IT集成企业，主要为日客户提供金融业、ERP等领域的IT解决方案，能够承接客户的一手项目，从上游工程（需求分析、方案设计、概要设计）开始，到下游工程（详细设计、开发、测试等）的项目管理、技术团队管理，最终确保高质量交付。公司制定了瀑布模型的软件项目流程，并通过了CMMI3级认证，在实际项目过程中，也严格按照该流程执行，得到了客户的认可和尊重，与极其挑剔的日资银行客户建立了高度信赖的合作关系。

DP哥当时既做需求分析和系统方案，又做项目管理，做过很多严谨的瀑布模型的项目，无一例外全部实现了优质交付，为企业创造了效益。但交付给甲方爸爸之后，有的效果非常好，一直稳定使用，产生了很高的价值；有的并没有带来任何收益，被束之高阁不了了之，没产生价值。DP哥也曾经复盘，分析问题究竟出在哪儿，也曾经推演如果用敏捷方式重新会是什么情况。

用个简单实际的评判标准，只有交付的系统被使用了，客户才会让我们持续维护。因此可以认为凡是稳定收取维护费的，都是产生了很大价值的；凡是未能收取维护费的，都是没产生价值的。

经过简单分析，发现一个有趣的结果，无论项目规模，凡是需求清晰，业务严谨，功能稳定，不直接面对终端用户的项目，都产生了很大价值。由于交付质量很高，上线后问题很少，维护费基本等于白赚。

而帮银行客户做的面向终端用户的系统，无一例外在上线后都受到了终端客户的挑战，要么反复改来改去，要么勉强提供给终端用户，最终也被事实抛弃。究其原因，在我们的项目管理流程中，我们有严谨的需求分析流程，也有高超的需求挖掘技巧，也有老到的风险对策，但是我们的分析对象只是付钱的客户，我们按照他们的意见去分析设计，最终按时按质交付给他们。客户经常并不能完全代表最终用户，他们也经常忽视这一点，致使在整个过程中也没有终端用户的深度参与，大瀑布的流程也导致不能尽早交付，从而导致最终结果不能得到使用者的认可，也就是说，我们可能用完美的过程生产了一个精致的废品。

但是，话说回来，最近10年，迭代和增量的软件开发方式已经深入人心，敏捷与精益已不再仅仅是软件开发套路和生产管理方法，它们已经成为一种思想，甚至是在VUCA时代的生存方式。在面临项目任务时，我们还是要根据实际情况，选择合适的项目推进方法，而方法并没有对错之分。作为软件项目的决策者和实施者，把这“瀑布”与“敏捷”看作实施项目过程中的方法、手段，在合适的时候挑选合适的方法，可能是一个更好的选择。单纯的选择“敏捷”，与单纯的选择“瀑布”一样，都是一种偏执的做法。

2 简单聊聊CMMI

CMMI一般以乙方软件企业的立场来描述。

甲方客户的核心需求的保证质量和准时交付，乙方软件企业所努力追求的是提高质量，节约成本，提高客户满意度，持续获得利润。

从软件工程的角度来说，开发一个高质量的软件系统，不能只依靠技术人员，甚至尽可能减轻对个人的依赖，还要对软件项目生命周期的各个过程进行有效的管理，从过程改进的角度来提高软件的质量。上世纪80年代，人们借鉴其它领域的管理改进实践，提出CMMI概念，即软件过程能力成熟度模型集成，它是一套针对软件过程的管理、改进与评估的模型，所表达的是精确化管理的理念，其模型有SQA(软件质量保证组)、SEPG(软件工程过程组)、和SEG(软件工程组)，这些概念好比立法、监督和执法，体现了西方文化中互相制衡的法治观念。

在CMMI模型中，描述了企业为了达到CMMI标准而需要完成的目标，并允许企业选择恰当的方式达到自己的目标；但并未告诉企业应该怎样做才会达到目标，还需要企业自己摸索。因此如何借助于CMMI来改善软件及项目管理的质量，需要结合自身特点深入研究和灵活运用。也有基于敏捷项目管理流程的企业通过了CMMI3级认证。

CMMI的5个级别

(1)初始级:对参与者有较高依赖，无法保证同类项目能够肯定成功。

(2)可重复级:通过制定计划、进度管理等方式进行项目管理，一定程度上能够复制同类项目的成功。

(3)已定义级:制定了一整套的管理控制措施，通过科学管理和实施这些措施，能够保证项目的成功率。

(4)已管理级:建立了完善的项目管理和量化评估制度，能够实现高精度的项目管理，从而保证项目质量。

(5)优化级:能够利用成熟的制度和管理手段来管理项目，能够持续提高管理能力和改进项目管理流程，并能够不断完善和优化。

CMMI的过程域

CMMI（V1.3）共有25个过程域(PA)，对于CMMI3级来言，大概关联其中的22个过程，这些过程域说明，如果要完成一个产品开发，需要做哪些工作。（CMMI 2.0已经把过程域改成了实践域）。

如果要做软件产品开发，首先是要做好需求开发(RD)，为了应对需求变更，需要做好需求管理(REQM)；需求明确后，如果通过管理来保质保量完成项目，因此需要做好项目计划(PP)，根据计划做好项目监督和控制(PMC)，如果需要采购，要做好供应商管理(SAM)，项目都会有风险，所以要做好风险管理(RSKM)，如果产品需要集成，可能需要多个部门或者多个公司合作，就要做好集成项目管理(IPM)。为了做到精细化管理，需要进行定量项目管理(QPM)。此外还需要有一定的环境支持，需要做好配置管理(CM)，以免得版本出错。针对工作中的遗漏和不按规范做事，需要做过程和产品质量保证(PPQA)，开发中碰到问题，需要进行决策分析和解决方案(DAR)

在具体的实施过程中，需要做好技术解决方案(TS)，如果是集成产品，则要考虑怎样产品集成(PI)。实施之后，为了确保和设计一致和满足需求，必须做好验证(VER)和确认(VAL)。一个软件产品开发周期之后，要进行经验教训总结、进行改进提高，因此需要做好度量和分析(M&A)，为其它项目和产品计划做依据。

在企业层面，则需要改进组织过程核心(OPF)，改进组织过程定义(OPD)，还要考虑如何进行组织培训(OT)，还并需要经常评估项目过程是否合理，需要组织过程绩效(OPP)，不合理就需要创新改进，并组织创新和实施(OID)。

CMMI与敏捷

CMMI是以工程纪律为基础，要求事情是有依据地开展活动，考虑如何管理一般团队，不依赖个体。而敏捷更强调个体，强调依赖个体的经验、积极性和灵活性来体现效能。CMMI高度强调过程，要求每个人只需要做好自己的事情：需求分析、设计、评审、开发等，它假定每个人更多是一个过程的遵守者，而不是一个创造者。

从本质上说，CMMI与敏捷实践并不是同一维度的话题，不是一个层面的事物。这个话题在网上有很多文章，大家可以自己找找看。

CMMI是评估组织软件能力的，定义了要做什么(What to do)，更适合于外包和大规模团队的分工协作，是一种重量级的过程，属于集团军作战；而敏捷适合一个完整的小团队，更像特种部队作战，偏重怎么做（How to do）。

3 大瀑布项目是怎么做的

3.1 项目基本流程

DP哥当年所在公司的项目流程是这样的：

其中每个过程都设计了明确的流程，指定了必须使用和选择使用的工具模板，设计了各种CheckList。DP哥当年在这套流程上颇下了一番工夫，在项目管理工作中进行了深刻贯彻，确保了每个项目的成功交付。DP哥曾经念过工程硕士，呕心沥血地写了100页硕士论文，就是研究这套流程。DP哥一度认为，软件就应该这么开发。

从合同角度，项目通常分为两阶段。第一阶段是需求分析，交付IT方案、概要设计书、项目实施的报价。方案和报价交付后，如果客户最终决定实施，再组建团队进入项目实施阶段。通常的做法是严格把软件项目分隔成各个开发阶段：需求分析，概要设计，详细设计，编码，单元测试，集成测试，系统测试、验收测试等。会严格定义了各开发阶段的输入和输出。在每一阶段会进行严格的过程评价，如果达不到要求的输出，下一阶段的工作就不展开。流程极度强调过程文档，通过文档把各个细节描述清楚，文档的重要性超过了代码。能否在前期把需求确认清楚，是项目成败的关键，如果出现了大的变更和返工，付出的代价会很大。产生的管理文档(计划书，进度表)等，能让不太了解该项目的人也能看懂项目的进度情况，很适合向领导汇报用。

下图是标准的V型流程。

3.2 各流程的成果物

下图是某个项目的需求分析文档目录。

下图是某个项目的概要设计文档片段。

下图是某个项目详细设计文档片段。每个处理都写了伪代码。到了后续的研发阶段，只不过是把伪代码变成程序，因此纯粹的编码和单元测试阶段会很短，对于程序员的技术并不会有太多依赖，可以直接外包。

以下是集成测试计划书（ITa）的片段，讲述本项目如何进行集成测试，要设置多少测试CASE才符合要求。

以下是集成测试品质评价书的片段。对测试结果进行了充分的定性、定量分析，认为是达到了集成测试的目的，可以进入后续的系统测试。

后面还有系统测试计划、系统测试品质评价，如果涉及外部联调，还有联调计划和联调品质评价，直到最终交付。

3.3 举例说明项目投入与成本

类似项目会严格管控项目进度和工作量投入，以一个70多人月，200多万的纯研发项目为例，持续周期、工作阶段及成本情况请参看下表。

投入人员的成本是不同的，对客户的报价中，成本从高到底的顺序是，需求分析>项目管理>技术管理>系统设计>编码，需求分析通常会是编码的1.5-2倍，偶尔能达到3倍。该项目的人员构成比例如下图。

3.4 项目交付物

在项目最初，会约定项目最终交付哪些内容，一般是文档、代码、安装包，通常构成如下：

需求分析书一套（需求业务描述、前提约束事项、各种备选方案、概算报价、成果物约定等）

概要设计书一套（功能设计、数据库设计、ER图、CRUD图、核心业务逻辑、重要接口等）

项目计划书（项目生命周期计划、质量保证手段、各阶段验收标准、人员体制、会议体制、报告体制）

详细设计书一套（各页面、报表、批处理、共同处理的详细逻辑）

代码及软件包

单元测试品质概要报告

集成测试计划书

集成测试设计书一套（测试方案、测试数据模型、测试数据、测试用例）

集成测试品质评价书（定性分析、定量分析、问题分析一览、测试结论）

系统测试计划书

系统测试设计书一套（测试方案、测试数据模型、测试数据、测试用例）

系统测试品质评价书（定性分析、定量分析、问题分析一览、测试结论）

上线发布计划书

手册一套（使用手册、安装维护手册）

4 CMMI已经非常难，敏捷更难

乍看起来CMMI或者大瀑布流程是一个复杂的，标准化的，程式化的软件研发过程，是相对比较重的。而敏捷是轻量级的，快速响应的所谓高效的研发方式，但综合起来看，很多人还是有很大误区。

敏捷不是快，而是快速反馈和快速响应，真正的老司机都知道，如果需求明确，反而传统瀑布方式是多快好省的。

敏捷其实很贵，无论是迭代和增量，都会有重复的劳动，敏捷更推崇小步快跑，更多尝试，其迭代成果叫做潜在可交付产品增量，会有更多返工或者废弃的风险。同时如果工程实践跟不上，多批次的迭代会非常消耗测试成本，所以敏捷很贵。

CMMI是担心项目失败，不希望依赖任何人，通过更好的“治人”来达到；而敏捷则是担心没有创新，担心比别人慢，更希望个人和团队能强一些，通过“育人”来实现。

说起敏捷转型，敏捷需要更成熟的员工与管理层，CMMI已经非常难，敏捷更难！