敏捷思想在软件研发中的研究与实践

丁慧、余亚萍、陈杰 /北京京航计算通讯研究所

随着信息技术的快速发展，硬件配置在不断升级优化，所承载的软件功能也日趋庞大和复杂。对于软件研发企业，是否能够采用高效、适宜的开发方法，以快速响应市场需求，交付用户有价值的产品，是其取得核心竞争力的关键。

传统的开发方法，如影响软件业40 年之久、至今仍被广泛应用的瀑布型开发模式，借鉴创造业流水线的开发思路，将软件研发过程划分为需求、设计、开发、验证、确认、维护等阶段，前一个阶段夯实了，下一个阶段才开启，这种接力的开发方法在应对需求多变、开发周期较长的复杂项目时，显得力不从心。

传统开发方式弊端的暴露诱发了敏捷运动。2001 年，一群志同道合的软件开发实践者提出了新的开发方法，称之为敏捷开发方法，它以轻量级、高适应性的特点赢得了业界的认可和推广。

北京京航计算通讯研究所从2018 年开始组织敏捷开发理念和应用实践的研究，并选择部分项目做试点，经过近两年的实践已取得一定成效。因此，本文的核心内容是基于敏捷思想，总结敏捷开发方法在项目中的实践经验。

一、敏捷开发思想

1.敏捷思想的核心价值观

敏捷的先行实践者对达成一致的敏捷理念形成了4 条敏捷宣言，如图1 所示。

图1 敏捷宣言

敏捷思想的第一条价值观是以人为本。软件开发是一个高智力活动，在开发复杂系统时，人才是最重要的，敏捷开发将个人潜能的激发及团队协作作为首要价值目标，流程和工具是保证团队成员能够有效工作的机制，只有在人的能效充分发挥的基础上才能起到作用。

敏捷思想的第二条价值观是目标导向。敏捷同其他的管理理论和模型一样，也认同目标导向是项目成功的关键，明确阐明软件开发的目标是可工作的软件，而非面面俱到的文档，文档在某种程度上可以支持开发和项目后期运维，需要但要把控度，避免掉入纷繁和迷失目标。

敏捷思想的第三条价值观是客户为先。合同约定了项目范围及双方应尽的义务和责任，是双方利益的保障，但项目的前期用户通常没有能力准确描述产品需求，成功的开发团队会把用户看成团队成员，通过迭代不断获取用户反馈，在开发中逐步理解用户的真正需求，从而在产品价值上与用户达成一致。

敏捷的第四条价值观是拥抱变化。变化是项目开发中的常态，客户对业务领域理解的加深、商业环境变化、技术变化、人员变动都能引起项目的变化。传统的开发方法不愿意正视变化，总是试图用详尽的计划去穷举变化，试图通过严格的执行计划来控制变化的发生。事实上，不可避免的变化很可能将项目带到绝境。而敏捷开发承认变化是开发的一部分，认为用户正是在不断的需求变化中明晰自己的真正需要，所以敏捷积极拥抱变化，并能坦然应对变化。

2.敏捷开发遵循的12 条原则

（1）尽早、持续交付有价值的软件是满足客户的最优先考虑因素。

（2）即使到了开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。

（3）频繁交付可以工作的软件，交付周期越短越好，可以从一两周到一两个月。

（4）在项目开发期间，业务人员和开发人员必须随时保持沟通。

（5）围绕项目中有动力的人开展工作，并给与他们所需的支持和信任。

（6）面对面的沟通是一个团队最有效的信息传递方式。

（7）可工作的软件是软件研发进度的首要度量指标。

（8）提倡可持续开发。产品的开发者、用户等相关干系人应能保持一个长期、恒定的开发节奏。

（9）持续关注卓越的技术及优秀设计能力能够增强敏捷能力。

（10）最大化地减少不必要的工作。

（11）自我组织的团队在不断实践中能够形成最适合的架构、需求和设计。

（12）团队应定期就如何更有效工作进行反省总结，并就问题作出相应调整。

敏捷的4 条价值及12 条原则，明确表达了支持什么反对什么，也清楚地指明了什么是敏捷。一个开发模式如果能够身体力行地践行这些价值观和原则，那么它就是敏捷模式，否则就不是。敏捷原则体现了敏捷开发的典型特征：循序渐进的迭代开发、简洁轻量、自组织自管理，交付用户刚好价值的产品。这更加符合事物的发展规律和人对事物的认识过程，如果说把软件开发过程比喻成一株植物的生长，那么传统开发模式展现给用户的是一粒种子而后是枝繁叶茂的大树，敏捷开发模式则是从种子到萌芽，再到抽枝散叶、开花结果，是一个延续的从雏形到成熟的演变过程，每一个阶段呈现的都是一株植物完整的样子。

二、敏捷开发实践

敏捷实践推行的前期产生了很多错误的理解，包括敏捷是一种小瀑布，敏捷是无序的，敏捷不需要文档、设计和计划等，因此有必要对敏捷建立统一的认识。对敏捷的理解可以分3 个层次：敏捷思想、优秀实践和具体应用。敏捷开发过程是团队在透彻理解敏捷思想的基础上，因地制宜地选择适合自己的优秀实践并应用到项目中的过程，实践的组合是多样的，实践的选择也遵从“增量实施，先易后难”，如图2 所示。对于一个需求多变的项目来说，Scrum 架构是最为理想的选择之一，它是一个简单的实验过程，规定了敏捷的流程约束、角色职责、文档要求及相应的管理与技术实践活动，很好地诠释了敏捷价值和敏捷原则。

图2 敏捷开发的实践组合

1.Scrum 管理流程

Scrum 管理流程将整个项目周期划分为多次迭代的过程，每次迭代遵循一定的流程约束，如图3 所示。在一个迭代周期中，产品负责人首先要与用户及开发团队对产品业务目标形成共识，建立和维护一个动态的需求列表。在迭代开始前，开发团队需要从产品列表中筛选出高优先级的需求纳入本轮的迭代开发中；在迭代周期内，开发团队细化本轮的迭代需求，开展每日站会、特性开发、持续集成，保证在迭代周期内完成本轮的迭代任务；迭代结束后，开展评审会和反思会。在整个迭代过程中，Scrum过程经理会指导团队关注迭代目标的实现并遵循Scrum实践原则。

图3 Scrum管理流程

2.Scrum 团队组建

Scrum 的项目实践包括3 个重要角色：产品负责人、过程经理和团队。

产品负责人在传统开发模式与敏捷模式下，对项目的参与程度不同。在传统模式下，产品责任人的介入主要是一头一尾；而在敏捷模式下，产品责任人要全程参与，所以在前期组建团队时要充分考虑产品责任人的适宜性，这个角色必须对市场前景有很好的感知能力，能够很好地梳理市场和用户反馈。在组织中，产品经理的角色选择要视情况而定，产品线经理、业务分析师、运维负责人都是在可选择的范围内。

过程经理在传统开发模式下不存在，敏捷模式下的主要职责是确保敏捷实践过程的正确开展，该角色可以兼职或轮岗，一般由项目经理、QA 人员、开发经理、资深开发人员担任。

在敏捷开发中团队的组建覆盖了需求分析师、设计师、开发人员、测试人员、配置人员等岗位人员，以这种跨功能领域的组队方式完成以用户故事为单位的持续交付。

3 个核心角色的定义及职责如表1 所示。

表1 Scrum的项目实践中个角色的定义及职责

3.Scrum 管理实践

（1）迭代计划会议。每次迭代启动前，团队共同讨论本轮迭代详细的开发计划，澄清需求，对完成标准达成一致；完成迭代需求工作量的评估，细化、分配迭代任务。迭代计划会议的输入是产品需求列表，输出是迭代需求列表。

（2）每日站立会议。每日工作前，由过程经理组织全体团队成员召开站立例会，时间不超过15 分钟，参会的人员就“昨天我做了什么？”“今天我要做什么？”“我需要什么样的帮助？”3 方面依次发言。每日站会有利于增强团队凝聚力，促进团队内部成员的沟通与协调，有利于及时暴露风险和问题。

（3）可视化管理。将项目状态（进度、效率和燃尽图等）用白板、大屏幕等实时展示，让团队成员能直观地获取当前项目的进展信息。

（4）迭代评审会。每次迭代结束时，团队成员对本次迭代完成的可工作软件进行演示，由产品经理判断是否满足验收标准，同时收集参会人员对产品的反馈，作为对后续需求列表调整的依据。

（5）迭代反思会。每次迭代结束后，团队成员对本轮迭代过程进行反思，达到分享好的实践经验和发现改进点的目的。反思会一般要先预定会议基调，限定某些讨论的问题，如果识别的人和事在团队之外，反思会就没有太大价值。

4.Scrum 文档要求

Scrum 架构中规定了3 个文档的输出：产品需求列表、迭代需求列表、版本计划，除此之外并未对其它文档做出明确要求。敏捷开发强调快速交付有价值、可工作的软件，弱化文档要求，但在与用户的需求沟通、后期系统维护、知识传递及项目交接中仍需文档做支撑，只是在敏捷中允许文档的多样化，如文字、多媒体、演示等，把杜绝冗余、仅提供有价值的文档作为指导思想。表2 是在满足CMMI 三级要求下实施Scrum 团队角色、活动及输出文档清单。

表2 Scrum团队角色、活动及输出文档清单

5.Scrum 实施成效

质量。敏捷从项目一开始就随时构建质量，发现缺陷就立即停止，避免技术债务的发生；测试人员与开发人员紧密协作，提前介入软件的设计与开发中，共同预防缺陷的产生。从交付的软件看，遗留至用户方的缺陷占比明显降低。

效率。敏捷中所倡导的面对面沟通、资源共享、不受干扰持续专注做好工作，使得团队成员能够快速进入工作状态、掌控工作局面，充分利用资源，提高工作效率。

成本。由于前期需求的不明朗，不是用户提出的每个需求都有价值，但每个需求都有相应开发成本。在敏捷开发中，最有价值的需求被最优先开发，交付刚刚好的系统，减少因开发无用功能而造成的成本浪费。

用户满意度。软件的复杂、多变、不可见决定了开发过程的不可控性，敏捷通过迭代的方式实现多次交付，在每次迭代过程中及时、充分收集用户反馈并作出相应调整，确保每次交付的可工作软件都能满足用户最大价值的功能需求。

团队能力。敏捷倡导以人为本，要求团队成员积极主动、自我管理，在这种团队氛围下，每个团队成员的技术、社交、领导能力都能得以提升。