重新理解敏捷开发（下）

Posted 2021-04-25 代码力量

敏捷开发的实现方法

其实早在敏捷开发出现之前，就有了很多轻量级开发方法，如Scrum和XP都诞生于上个世纪90年代，同时期的还有FDD、DSDM、Crystal、ASD等。由于各种轻量级方法发展还处于萌芽阶段，所以面对当时软件工程街占据主导地位的SEI CMM、RUP、IEEE、ISO等重型模型，轻量级方法进行了联合，组成统一的联盟即敏捷联盟（2001年）提出了敏捷开发，其实是所有轻量开发价值观的方法统称，所以这里大家有个鸡生蛋蛋生鸡的印象。

敏捷开发方法的共同特征就是跌代式开发、增量交付、开发团队和用户反馈推动产品开发、持续集成和开发团队自我管理。

在敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭代开发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：

• 组织文化必须支持谈判

• 人员彼此信任

• 人少但是精干

• 开发人员所作决定得到认可

• 环境设施满足成员间快速沟通之需要

最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。大规模的敏捷软件开发尚处于积极研究的领域。

另外的问题是项目初期的大量假定或者快速收集需求可能导致项目走入误区，特别是客户对其自身需要毫无概念的情况下。

与之类似，人之天性很容易造成某个人成为主导并将项目目标和设计引入错误方向的境况。开发者经常能把不恰当的方案授予客户，并且直到最后发现问题前都能获得客户认同。

虽然理论上快速交互的过程可以限制这些错误的发生，但前提是要有效的“负反馈”，否则错误会迅速膨胀，并在最终提交时造成极大返工。

敏捷软件开发支持广泛的软件开发生命周期。有的专注于实践（例如，极限编程、务实编程，敏捷建模），而有的专注于管理工作流程（例如Scrum，看板）。有的支持需求规范和开发（例如FDD）的活动，而另一些则试图涵盖整个开发生命周期（例如DSDM，RUP）。

敏捷软件开发得到了许多具体实践的支持，涵盖了需求、设计、建模、编码、测试、计划、风险管理、流程、质量等方面。

敏捷开发作为一种指导思想或开发方式，并没有明确告诉我们到底采用什么样的流程进行开发，这种明确流程的就是敏捷方法，它是敏捷开发的具体方式。

目前被列为敏捷方法的有：

• 软件开发之韵，Software Development Rhythms

• 敏捷数据库技术，AD/Agile Database Techniques

• 敏捷建模，AM/Agile Modeling

• 自适应软件开发，ASD/Adaptive Software Development

• 水晶方法，Crystal

• 特性驱动开发，FDD/Feature Driven Development

• 动态系统开发方法，DSDM/Dynamic Systems Development Method

• 精益软件开发，Lean Software Development

• AUP（Agile Unified Process）

• Scrum

• XBreed

• 极限编程，（Extreme Programming）

• 探索性测试

• ATDD

还有一些你可能经常听到的技术也被纳入到敏捷的范畴，即敏捷技术，常见的有：

• 测试驱动开发，TDD/Test-Driven Development

• 行为驱动开发，BDD/Behavior-Driven Development

• Scrum

在敏捷开发的所有方法中，目前最为流行、影响最大的是极限编程XP和Scrum。你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。

极限编程

极限编程（Extreme Programming，简称XP）是由Kent Beck在1996年提出的。极限编程是一个轻量级的、灵巧、高效、低风险、柔性、可预测、充满乐趣的软件开发方法；同时它也是一个非常严谨和科学周密的方法。

XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

Kent Beck曾经说过“开车”就是一个XP的范例，即使看上去进行得很顺利，也不要把视线从公路上移开，因为路况的变化，将使得你必须随时做出一些这样那样的调整。而在软件项目中，客户就是司机，他们也没有办法确切地知道软件应该做什么，因此程序员就需要向客户提供方向盘，并且告知我们现在的位置。

XP的核心是其总结的沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）四大价值观，它们是XP的基础，也是XP的灵魂。此外还扩展了第五个价值观“谦逊”。

“Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它所不提倡的，XP则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。

极限编程的操作流程主要包含12个最佳实践，这些实践并不是创新的概念，大多数概念和编程一样古老，主要的创新点在于提供了一种良好的思路，将这些最佳实践结合在一起，并确保尽可能彻底地执行他们，使它们在最大程度上相互支持。12个最佳实践包含以下内容：

• 计划游戏：先快速地制定一份概要的计划，然后随着项目细节的不断清晰，再逐步完善这份计划。一般在大公司基本是这样的流程：<1>初始计划 – 确定重要的需求，进行快速响应，工时评估。<2>发布计划 – 了解开发进度后，客户就知道需求的实现成本（包括人力、时间等资源）、商业价值、优先级别（预估可能不准确，随开发不断调整），然后就回对需求根据优先级进行替换。<3>迭代计划 – 一般迭代周期为1到2周，周期内需求的实现顺序根据技术来进行排序，可以串行也可以并行开发，开发中的需求不应被更改，未开发的需求可以看情况调整。<4>任务计划 – 每次迭代更新，开发人员对要开发的需求任务进行拆解，客户进行优先级调整， 计划的方式可以采用任务列表、便笺、白板标示等方式，每完成一项，则应对其进行标注，对任务进度随时更新；

• 小型发布：更多的发布测试版本，中间版本，让客户或者PM审核，确认功能开发没有错误，需要引入代码管理工具，版本控制工具 ；

• 隐喻：创造心照不宣的词汇和列子，更形象有趣的沟通。比喻有时候更能让人更快更好的理解你的意思，而不是一堆晦涩专业术语；

• 简单设计：没有重复代码，尽量少的类和方法，使用迪米特法则等 ，尽可能考虑当下需求，不要为了扩展性过度设计，多考虑不同的方案，然后选择一种最实际、简单的解决方案，只有在确定真的需要引入某些基础结构（比如数据库、通信服务框架）性价比更高时，再去引入它们；

• 测试先行／测试驱动开发：编写单元测试是一种验证行为，更是一种设计行为。测试驱动开发（TDD），需要借助一些自动化测试工具，可以帮助开发人员做到有目的的开发。验收测试（ UAT ）可以用来验证系统功能是否完善；

• 重构：在Martin Fowler大神的名著《重构》一书中，他把重构定义为：在不改变代码外在行为的前提下对代码进行修改，以改进代码内部结构的过程。重构的目的是降低变化引发的风险，使得代码优化更加容易。重构有时并不是需要做很大的修改，XP倡导开发人员经常进行重构；

• 结对编程：鼓励团队进行结对编程，而且认为结对编程的组合应该动态地搭配，根据任务的不同、专业技能的不同进行最优组合。在XP中，结对编程指的是由2个开发人员公用一台电脑，一个人进行编码，另一个进行观察并寻找代码中的错误和可以改进的地方，两个人进行频繁的角色互换。结对关系每天至少进行一次，且团队中每个成员都应和其他成员一起工作参与。研究表明这样不但不会降低开发效率，还会大大减少缺陷率。简单理解就是一个人身兼开发和测试开发2个岗位职责，这种方式已经很少看到 ；

• 集体代码所有制：团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。同时，XP强调代码是谁破坏的（也就是修改后发生问题），就应该由谁来修复；

• 持续集成：团队每天尽可能多次的进行代码集成（多次的check in和check out并进行merge，使用非阻塞的源代码控制工具；每天进行多次系统构建），保证团队获取的代码都是近期统一过的代码，避免太多不一致造成冲突 ；

• 每周工作40小时／可持续的速度：简单来说，就是反对加班，将进度控制在合理的范围，让开发人员保持一个健康高效的状态。做到让开发人员享受开发，而不是让他们感受到了煎熬；

• 现场客户：XP方法论认为最重要的需要将客户（不仅仅指为我们产品付费或使用产品的外部客户，它还包括公司内部的业务部门，有合作关系的甲方、第三方等，一般在公司中你面对的是产品、业务分析师、项目经理等）请到开发现场，要面对面沟通 ；

• 编码标准：除了这种文字规范以外，还可以采用一些如自动格式化代码工具之类的方法进行代码规范，大公司一般对各种语言都有相应的编码规范 ；

极限编程要想完全发挥其效果，需要完整的使用这12个实践内容，相应的XP实践可以参考文章《敏捷开发与XP实践》、《实验三 敏捷开发与XP实践》、《开始极限编程之旅》。

Scrum

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作，Scrum就是这样的一个激励大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成任务的开发流程，运用该流程，你就能看到你团队高效的工作。Scrum本质上是一组实践和为其过程参与者制定角色框架，其实它和其他敏捷方法是殊途同归，Scrum鼓励小型的、自我管理的团队在短的开发周期完成一系列定义良好的开发任务。

在了解Scrum之前我们先简单认识一下Scrum中的关键元素，分别是三种角色、三种文档和三种会议。

Scrum中的三种角色

产品负责人（Product Owner）

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

流程管理员（Scrum Master）

主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team）

由开发人员、测试人员、文案和其他帮助研发的成员组成，主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力，团队成员常常扮演多种角色；成员可以采用任何工作方式，只要能达到Sprint（指在Scrum项目管理方法中的一个常规、可重复的较短工作周期）的目标。

Scrum中的三种常用可视化文档

产品需求列表（Product Backlog）

这里的Backlog是指待开发项，积压的任务。产品 Backlog 包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的，需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护。产品经理会从众多用户故事中筛选出优先级，并把他们列入产品开发列表中，需求列表会随着每次的Sprint迭代和更改。

Sprint代办列表（Sprint Backlog）

Sprint 本意为“冲刺”，指迭代周期，长度通常是一至六周。每次Sprint迭代前，团队要进行讨论，最优项的用户故事将进入Sprint代办列表，剩下的继续评估优先级，交到下次Sprint中。

燃尽图（Burndown Chart）

燃尽图是用来展示整个Sprint代办列表的进度，横轴表示整个Sprint的总时间，单位可以是小时或天等，纵轴表示Sprint中的所有任务，当燃尽图曲线接近于0时，也就意味着这次Sprint即将完工。燃尽图的跟踪进度应该由团队整体每天更新，如果曲线下降太快，说明本次Sprint中的任务太少，可以添加一些任务进来，反之则去除一些任务，这个跟团队开发评估经验有关。燃尽图要便于更新，不用追求酷炫的效果，也不要太过复杂，难以维护。

公司中燃尽图常常搭配看板使用，参考下图：

Scrum中三种形式的会议

Sprint计划会议（Sprint Planning）

Sprint计划会议是产品经理、Scrum Master和开发团队碰头的会议，用于讨论用户故事并估算任务量。

每日例会（Daily Scrum）

每日例会，即你学习Scrum必定会遇到、大公司平时也常见到的站立会，整个团队会简述工作进度，并讨论是否有任务需要搁置或加派人手。

Sprint回顾会议（Sprint review）

在Sprint临近尾声时，团队会进行Sprint回顾会议，这时研发团队会向产品经理展示开发好的功能，然后整个团队讨论是否有需要改进的地方。

Scrum整体流程

了解完了Scrum中的重要组成部分，我们可以来谈一下Scrum的整体流程了。

• 产品经理把需要上线的产品特性做成产品需求列表（Backlog），然后由产品经理甄选出最优项，准备交给整个团队讨论。

• 召开Sprint规划会议，研发团队、产品经理和Scrum Master讨论用户故事优先项，并且决定下次Sprint要研发的需求项。

• 根据Sprint规划会议制定Sprint需求列表，这个列表就是经过团队讨论后的用户故事，用于下次的Sprint，会议结束后，整个研发团队和产品经理必须要对每个用户故事有深刻的理解。

• 研发团队要在一到三周的时间里开发完成Sprint列表中的需求。在Sprint期间，每日站会用于团队来交流他们做完了什么、正在做什么以及遇到的问题。Sprint的产出是一个可以发布的产品版本，是否可发布由产品经理来决定，也可以在发布前增加新功能。

• 在Sprint结束时会举行Sprint回顾会议，由研发团队向产品经理做案例演示，同时团队一起反思工作中可以改进的地方，每次的Sprint结束后都要进行这种回顾。

敏捷开发在互联网公司的落地应用

敏捷开发因为其短平快的特点非常适合互联网的快速发布、逐步迭代的发展策略，目前已经深入到互联网的各个角落。常见的敏捷开发项目总流程如下：

• 需求规划和分期；

• 需求评审；

• 需求讲解；

• 方案评审；

• 每日晨会；

• 性能测试；

• CodeReview；

• Demo；

• 测试阶段；

• 线上Bug修改流程 ；

个人认为互联网公司落地敏捷开发的过程中是爬过很多坑的，甚至现在很多坑还没能爬出来。。。接下来我们就来分析一下敏捷开发强调的内容在国内落地的差距。

敏捷开发之“ 理想和现实的差距 ”

敏捷的发源于美国，也因为一些硅谷公司在中国的大力推动而生根发芽。但是中美文化有巨大的差异，导致我们在理解和执行敏捷开发方法的时候，会觉得无法执行下去。这就造成了书本上和“别人家”的敏捷方法，与中国公司实际可落地的敏捷方法有很大的不同。

• 结对开发：

  开发人员水平太差，典型的“哟写bug呢？

  ”，结对开发成了开发人员直接搭配测试妹子一对一联调，

• 代码评审：

  人和人之间的善意往往低的可怜，代码谁写的谁负责，除了问题锅是跑不了；

• 弹性工作：

  国内加班文化不说了，符合当下国情，毕竟你的bug这么多还好意思下班？

• Scrum会议：

  没想到吧，人和人的沟通成本是很高很高的，还有早上的立会就安排9点，你不可以迟到；

• 去文档、去流程：

  相对的对团队的耦合度要求更高了，人员变动频繁、团队规模较大的情况下，非常不现实，所以重要的文档如产品文档、概要设计、接口文档还是要有的，从长久来看，文档依然是提升效率的一大利器，所以敏捷落地的过程中往往会搭配文档管理工具，如confluence；

• Sprint周期推进：

  很多开发尤其是大型软件的开发，并不是每个Sprint都能有demo的进展，所以release总是要推迟；

• 用户故事：

  很多需求是无法通过口头沟通建立起晚上的需求文档和需求模型；

• 现场客户：

  如果是面向外部客户，很难让甲方全程参与开发过程；

• 敏捷开发：

  老板尝尝以为是使用了可以降低开发时间。

当下互联网公司的敏捷开发

如今商业社会快速发展的节奏要求产品可以更灵活、更快速的适应需求的变化，所以敏捷开发也越来越受到大家的重视和应用。敏捷开发在国内发展属于“取其精华、去其糟粕”的本土化过程，当下互联网公司很多做事风格都是吸取了敏捷开发的思想，“小步快跑、不断试错”。

敏捷开发本身就是一种价值观和方法论，就像是兵书，可以借鉴学习，但战场上不能只有纸上谈兵， 敏捷开发不是银弹！提高研发人员开发水平和管理者的管理水平才是重点，从一些部门的实践，他们得出了一个心得，Be Agile，Don’t do。即Agile是一种状态，关键是这个团队有一样的一种共识，价值观，然后一起去实践Agile。而不是强行推进一些Agile的工具，开发流程。

具体到形式细节，互联网公司当下都有站会、看板、演示&计划&反思会、用户故事和持续集成等过程和环节 ，管理上也多使用敏捷管理软件（国外jira、redmine，Axosoft ，国内的leangoo 、禅道，BAT都有自研的工具，百度的icafe，阿里的aone，腾讯的tapd）搭配wiki系统（confluence等），常见的是用jira做项目跟踪、任务跟踪、敏捷管理、需求收集等，搭配confluence做知识库管理，也可以参考CODING、TOWER等工具。

最后，敏捷开发是组织文化、流程和工具的结合体，千万不要用来作为管理的手段，敏捷开发中“人是第一位的”，用Sprint来推动研发输出，往往事与愿违。实施敏捷开发要因地制宜，把握敏捷的思想，不要追求形式。

参考文献

• 软件的几种开发模式；

• 敏捷开发指导思想；

• 实施敏捷开发，看这一篇就够了；

• 瀑布式开发、迭代开发、敏捷开发、XP与SCRUM的区别；

• 敏捷开发，英文是Agile，我所理解的敏捷；

• 【敏捷】什么是极限编程；

• 极简XP极限编程图解；

• [读书笔记]Scrum 总结；

• 图解常用的8款Scrum敏捷开发工具；

• 如何实现敏捷开发；

• 敏捷开发，在互联网公司项目中的各个环节；

• 你大概走了假敏捷：认真说说敏捷的实现和问题；

• 基于JIRA的敏捷开发管理过程；

• 敏捷开发培训(Agile_Development)；

• SCRUM敏捷开发教程；

欢迎转载，转载请注明出处。

点击“阅读原文”，查看更多精彩！

北凉柿子的博客：http://www.beiliangshizi.com/