谈敏捷开发

[DamaoShao]

本文是从老博客移过来的，完成时间大约是19年3月，当时我初做公司一个Scrum Team的Master，一脸懵逼。如今跌跌撞撞一年了，我对敏捷开发又有了一些新的体会。这周争取写一篇博客，记录一下我一年的敏捷开发实践。

前言

1. 我们公司一直在实行敏捷开发，但是我身边的同事对敏捷开发的理解各不相同，有的甚至观点相悖。为了确认到底啥是敏捷开发，提升我们组的开发效率，这两天我看了一圈文章和其他公司的实践，写了这篇文章。
2. 本文中的敏捷开发有时特指Scrum，文中可能没有全部标明。
3. 本文的关于敏捷开发（Scrum）的描述部分（即【一、什么是敏捷开发】），除非特别注明，均来自The Home of Scrum中的The Scrum Guide（中文PDF版点击这里）。为了行文方便，文中就不一一标注了。

一、什么是敏捷开发

1.1 敏捷开发的定义

敏捷开发是一套软件开发中的观点（即《敏捷软件开发宣言》）和原则（即《敏捷宣言遵循的原则》）。符合该价值观的和原则的软件开发方法，都可以认为是敏捷开发。

敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动高于流程和工具，
工作的软件高于详尽的文档，
客户合作高于合同谈判，
响应变化高于遵循计划，
也就是说，尽管右项有其价值，我们更重视左项的价值。

敏捷宣言遵循的原则
我们遵循以下原则：
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何能提高成效，并依此调整自身的举止表现。

敏捷开发有5个主要的价值观和3个支柱，一般来说，敏捷开发也应该有这些特性。

敏捷开发的价值观

• 专注：由于我们在一段时间内只专注于少数几件事情，所以我们可以很好地合作并获得优质的产出。我们能够更快地交付有价值的事项。
• 公开：在团队合作中，大家都会表达我们做得如何，以及遇到的障碍。我们发现将担忧说出来是一件好事，因为只有这样才能让这些担忧及时得到解决。
• 尊重：因为我们在一起工作，分享和成功失败，这有助于培养并加深互相之间的尊重，并帮助彼此成为值得尊重的人。
• 承诺：由于对自己的命运有更大的掌握，我们会有更坚强的信念获得成功。
• 勇气：因为我们不得单打独斗，我们能够感受到支持，而且掌握更多的资源。这一切赋予我们勇气去迎接更大的挑战。

敏捷开发的支柱

• 透明：过程中的关键环节对于那些对产出负责的人必须是显而易见的。要拥有透明，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理解。
• 检视：Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint 目标的进展，以便发现不必要的差异。检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤勉地执行时，效果最佳。
• 适应：如果检视者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执行如此才能最小化进一步的偏离。

1.2 敏捷（Scrum）开发的流程

Scrum是敏捷开发的框架中的一种，也是最流行的一种。Sprint是Scrum的组成部分，可以直接理解其为一次迭代，一个开发周期。Scrum开发过程有4个正式事件组成。

• Sprint计划会议：Sprint 中要做的工作在 Sprint 计划会议中来做计划。这份工作计划是由整个 Scrum 团队共同协作完成的。该会议主要解决两个问题：在这个Sprint做什么（What），怎么做（How）。
• 每日Scrum站会：每日 Scrum 站会是开发团队的一个时间盒限定为 15 分钟的事件。每日 Scrum 站会Sprint 的每一天都举行。在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制定计划。通过检视上次每日Scrum 站会以来的工作和预测即将到来的 Sprint 工作来优化团队协作和效能。参与站会的每个人都要说为了打成这个Sprint的目标，昨天我做了什么，今天我做了什么和是否有障碍在阻塞我或者我的团队的进度这三个问题。
• Sprint评审会议：Sprint 评审会议在 Sprint 快结束时举行 ，用以检视所交付的产品增量并按需调整产品待办列表。在 Sprint 评审会议中，Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的工作。根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。Sprint 评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个 Sprint 的产品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。
• Sprint回顾会议：Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。Sprint 回顾会议的目的在于三点，1）检视前一个 Sprint 中关于人、关系、过程和工具的情况如何。2）找出并加以排序做得好的和潜在需要改进的主要方面。3）制定改进 Scrum 团队工作方式的计划。

一般的Scrum开发流程（不借助于任何工具）如下：

1. 产品负责人将整个产品设计成产品Backlog。产品Backlog本质就是需求列表。
2. 召开Sprint计划会议。
3. Sprint计划会议定下的任务写在纸条上贴在任务墙，让Scrum成员认领分配并细分。（任务墙就是把未完成、正在做、已完成 的工作状态贴到一个墙上，这样大家都可以看得到任务的状态 ）
4. 举行每日站立会议，让大家在每日会议上总结昨天做的事情、遇到什么困难，今天开展什么任务。
5. 绘制燃尽图，保证任务的概况能够清晰看到。（燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0 ，这个sprint就完成了）。
6. Sprint评审会议是在Sprint完成时举行，要向客户演示自己完成的软件产品 。
7. 最后是Sprint总结会议，以轮流发言方式进行，每个人都要发言，总结上一次Sprint中遇到的问题、改进和大家分享讨论。

二、如何理解敏捷开发

2.1 敏捷开发的优势

敏捷开发(Scrum)只是一套积极响应变化的开发框架。如果开发效率被定义为更短时间里开发出需要的功能（或者相同的时间里开发出更多的功能），那么敏捷开发肯定会降低效率。想一想效率最高的开发方式是啥：需求明确，文档详尽，码不停蹄。而敏捷开发与"效率最高"的开发方式正好相反。

• 敏捷开发讲究影响变化，因此需求特别不明确，甚至开发过程中，需求还有变更。
• 需求变化就意味着返工，返工不仅浪费时间，更会浪费开发人员的感情，导致Scrum成员士气低迷。
• 敏捷开发弱化了文档，很多时候，你有疑问，想找一下文档，会发现文档描述非常模糊，甚至根本就没有文档。
• 敏捷开发强调（依赖）大量沟通，沟通就难免会打断手头的工作。

既然敏捷开发会降低效率，那么为什么这么企业(包括咱们公司)还要使用敏捷开发呢？因为敏捷开发可以大幅提升投入产出比。高效率开发出来的功能，如果不是客户需要的，那就是纯浪费，效率再高，投入产出比也是零。具体来说，敏捷开发对投入产出比的提高来主要来自以下几个方面：

• Sprint周期短，Scrum人员少：毕竟"人月神话"，制定计划很难，制定靠谱的长期多人参与的计划更是难上青天。因此敏捷开发因为周期短人员少，制定出来的计划就有了天然的优势。
• 不断集成，不断提供一个可展现的成果：**没有人可能真的理解用户需要什么，哪怕用户自己也不行。**优秀的敏捷开发应该（这里是应该，仅仅应该）从第一天开始就持续集成，这样更加方便检查，让用户确认，一旦开发偏离用户需求，就可以及时更正。
• 集中资源，解决用户最迫切的需求：每次Sprint计划会议会对Backlog里面的每一项进优先级排序，在每个Sprint中，只开发用户最迫切的需求。这样就保证了本来就有限的资源不会浪费。

2.2 敏捷开发的劣势

敏捷开发的劣势也是明显的，就是太依赖人了。

• 没有文档，信息传递靠沟通。如果团队人员稳定还好，沟通有默契，很多基础信息也都了解，有些问题，提一句，听者立马懂了。如果团队人员流动大，这就太恐怖了，信息的高度不对等，沟通方式的不同步，这样沟通成本会成倍增加，新来的同事受挫感强，很难融入，老同事开发经常被打断，也烦。
• 敏捷开发中，需求是会变更的。这个就要求团队成员的技术实力比较高，不仅懂自己这摊，还要懂其他人开发的内容，在开发的过程中，代码就要考虑到各方面问题，留有扩展性，这样在每次需求变更中，大家才能更快的找到最佳解决方案从而适配新的需求。另外，并不是每个Sprint每个人的Task都会非常均匀，Scrum成员最好能提其他伙伴分担一点，比如Task开发完成后，开发人员自己也可以跑测试案例的。
• 敏捷开发的工作量很难有一个衡量标准。建立并执行的一个衡量标准的成本是极其高的，因此敏捷开发中的工作量认定更多是依靠Scrum成员的真诚。一旦失去真诚氛围，敏捷开发就只剩空壳，要知道没什么比每个人都要假装有事情干更恐怖的了。

我觉得可以这么说，优秀的敏捷开发团队一定是由一群自建设的人自组织起来的。敏捷开发可以有Scrum Master（Scrum Master本质就是敏捷开发教练，指导大家更好的进行敏捷开发）（当然最好可以没有Scrum Master，因为每个都是Scrum Master），但是Scrum Master只能深度参与，决不能Push，一旦Push就会毁了自建设，这等于毁了敏捷开发的基石。