※本ブログは中国語となっています。

前言

大家好，我是SHIFT公司DevOps推广部门的Syu。今天想跟大家说说关于敏捷开发的话题。

在过去在软件行业里，很长一段时间是普遍采用传统瀑布模型进行项目开发的。即严格按照计划的时间顺序依次进行全面的需求分析，设计，编程，测试，所有步骤通过后将产品发布，之后进行系统维护的一种模式。

虽然现在仍有一些项目采用这种模型进行开发，但它并不适用于当下普遍需要对快速变化的市场需求做出及时反应才能取得成功的软件行业。因此相对于这种套用字传统工业生产的瀑布式，近十几年来有一种更受行业青睐并且逐渐成为主流的开发方法，它就是敏捷开发。

接下来，本文将从一下几点对敏捷开发进行叙述。

1.什么是敏捷开发
2.敏捷开发的实践
3.Scrum框架的应用

1.什么是敏捷开发

90年代初，电脑在人们生活中渐渐普及，并且随着经济的腾飞，各行各业也进入快速发展的阶段。市场对于各种定制型软件的需求增大，并且对软件功能需求的变化也变得迅速起来。所以，如何能更快更好地应对这种变更成为了软件项目管理的一大课题。

即便人们对于敏捷类型的软件开发方法的关注和讨论就已经开始，但第一次正式对敏捷开发制定宣言并向世人提出“敏捷开发”的，是2001年。在美国犹他州，17位相关的软件专家在一次会议上签署了《敏捷软件开发宣言》（引用自中文版https://agilemanifesto.org/iso/zhchs/manifesto.html），其中，对于进行敏捷开发的价值观，其内容如下：

“个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划” 

并且他们也声明，敏捷开发是在认同右边的价值基础上，更加重视左边的价值，而不是非此即彼。同时，对于敏捷开发，他们提出了十二项原则（引用自中文版https://agilemanifesto.org/iso/zhchs/principles.html），即：

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

 也就是说，敏捷开发相对传统瀑布模式开发更具灵活性和应变能力，更在意的是快速实现的产品交付以及可持续的反馈应对。它以用户的需求变化为核心，是一种采用迭代，循序渐进的开发方法。其特点是要充分发挥人在项目中的作用和意义。

敏捷开发的流程图如下：

首先整理客户的需求和仕样，在敏捷开发中被称为发布计划阶段，依据制定的发布计划进行各个迭代的开发。然后对开发的成果进行测试。要注意的是发布计划只是大致决定开发的方向，并不是绝对不可更改的，在开发过程中，计划内没有的一些需求和仕样在必要的时候可以增减。测试结束后进行产品发布，完成迭代。然后根据反馈再次整理需求和仕样，循环重复进行。

2.敏捷开发的实践

尽管敏捷开发模型已经成为软件行业的主流，甚至如今在其他各行业，也有很多把敏捷开发看作一种思维模式运用在企业经营管理上。然而，敏捷开发并不是使用于所有项目的管理，作为一种方法论，它自然也有自己的优点和缺点。

首先，敏捷开发最主要的优点，就是能更顺利的应对仕样的变更，提高开发的效率，以及满足客人的要求。

瀑布模型的话，因为在一开始就要把所有仕样都具体地明确下来才能进入下一阶段，所以当仕样发生改变的时候，若是已经进入到了后面的阶段，就需要推到重来，并产生巨大的时间成本和人力成本。而在敏捷开发模型下，因为预设了会有仕样的变更和增减的发生，所以一开始就只是大概确定方向而不会明确到细节。所以即使发生了仕样的变更或者顾客提出了其他要求，也很容易在影响较小的范围内应对，减少成本的损失，还能提高顾客满意度。

但是，有些时候也正因为敏捷开发模型的过于灵活，导致开发的方向性和目的性不明确，对项目进度的把握难度也会增大，甚至有滞后的风险。

所以，像行业技术更新快的手机行业，或者需要重视顾客体验的产品开发这类，会随时产生新的需求和仕样的项目会更适合敏捷开发模型。

3.Scrum框架的应用

在多年的实践中，人们也总结出了多种框架去实现敏捷开发，主要有以下7种：

・Scrum
・极限编程（XP）
・特性驱动开发（FDD）
・水晶方法族（Crystal Methods）
・动态系统开发方法（DSDM）
・自适应软件开发（ASD）
・轻量型RUD

其中，最主流的要数Scrum框架。

敏捷开发灵活自由，但不能理解成随心所欲，无规矩不成方圆。Scrum也有自己的一套体系去具体地体现敏捷开发，其流程如下图：

在Scrum框架里，主要角色有3个，一个是产品负责人，即Product Owner，最好是客户，或者是可以协调沟通客户和开发团队的人。一个是开发经理，即Scrum Master，他负责推进Scrum在团队中的进行以及为团队解决问题。还有一个就是具体负责程序开发的开发人员。产品负责人根据用户和市场调研结果制定产品功能列表，然后在Sprint 开始的时候跟Scrum成员一起举行计划会议，即Sprint Planning，把列表里的功能按照优先顺序拆分成各个Sprint周期任务，达成目标共识，开发经理整理好Sprint开发列表之后，在规定地周期内进行产品地迭代更新。

真正的Scrum是在各个Sprint周期内完成的，一般来说，Sprint周期在4周以内。一个周期的目标是明确的，为了完成Sprint周期的目标，对于Scrum框架下的成员来说，要进行每日例会（Daily Scrum），基本上，每次的时间都规定在15分钟以内，主要由成员讲述以下三点：

・昨天做了什么
・今天准备做什么
・有没有遇到什么难题

然后各自有序地开始工作。如果在例会上出现了需要讨论的话题，则需另选时间进行讨论。一般由Scrum Master负责例会地进行。

然后一个Sprint周期结束时，会对这个周期的成果进行评审，即Sprint Review。看是否符合完成标准以及是否实现了产品价值需求，有无增减的必要。因为敏捷开发其中一个原则是要向客户交付有价值的产品。评审会议的时长根据周期的长短也有不同，一般来说，Sprint周期为1周，则评审会议时长在1小时以内，Sprint周期为4周时，评审会议原则上不超过4小时。

最后，当所有都完成之后，为了能更加完善开发流程，需要对整个周期进行复盘，即Sprint Retrospective。复盘的形式可以有多种，通常会对以下几个问题进行讨论：

・在Sprint周期内做了些什么
・做得好的地方
・做得不好的地方

然后对如何持续保持好的一面，以及对于不好的地方，在接下来的周期里如何调整改善的问题进行总结。

总结

敏捷开发虽然在如今已经不是一个陌生的词语，但要在项目中推进敏捷开发的模式还是会经常遇到一些困难，所以需要掌握一定的方法。当然市场不断变化，也会不断涌现新的需求，敏捷开发也在不断发展进化中。在我看来，【敏捷】不只是一种软件行业的项目管理方式，它更像是一种思维方式，是鼓励人们去拥抱变化，不断学习以完善自身的一种能力，适用于善于变化的各行各业，值得让大家更加深入去了解和运用。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/