（一）什么是敏捷（Agile）？

Agile

从今天开始，通过21天打卡ACP的学习，带领同学们一起进入ACP的学习之路。首先进入我们的第一课：什么是敏捷？

从本质来讲，敏捷（Agile）不是开发方法，而是一种理念。对于项目管理而言，敏捷是一个全新的术语，敏捷强调在软件研发过程中持续性的根据用户反馈和需求优先级来发布新版本，不断进行迭代从而让产品逐渐完善。

几十年前，瀑布流的项目管理是软件开发的主流方法，在研发过程中，团队成员花大量时间和精力在项目的前期去手机资源和信息，然后基于收集的内容去做产品设计和研发规划。到了70年代的时候，有先觉的研发人员发现瀑布式研发不仅在执行中各处受限，研发速度也很慢，显然很落伍了，尤其到了90年代末期，开始出现黑客捣乱，这就意味着前功尽弃，全部推倒重来，对于研发来说，就是噩梦般的存在。

相比较瀑布式基于线性，可预测性进行开发产品，研发人员更想要得是能够灵活管理用户反馈、bug和需求的方法。这既是敏捷方法产生后大受欢迎的原因。

2001年2月11日到13日，在美国犹他州瓦萨奇山雪鸟滑雪胜地，17个人聚会交谈、滑雪、休闲，聚餐。参会者包括来自极限编程、Scrum DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。他们试图找到共识，最终的成果就是《敏捷软件开发宣言》（Manifesto for Agile Software Development）

敏捷软件开发宣言

可以总结为：

01.以人为本：重视个体间的合作互动；

02.目标导向：我们最终交付的是“可使用的软件”，而不是一堆繁重的文档；

03.客户为先：理解客户需求，与客户合作；

04.拥抱变化：客户会在不断变化需求的过程中明晰真正需要的东西，因此敏捷需要拥抱变化。

虽如此，这四个价值观并不意味着我们要放弃工具、文档和计划。因为他们对研发结果依然有非常重要的价值，只是相比之下，我们应该关注核心的事物：人、产品模型、协作和迭代。

为了让这四个原则变得简单易懂好执行，他们又写了敏捷开发12项原则作为指导：

敏捷宣言遵循的原则

1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来让客户满意。

规划故事时，必须按优先级安排，为客户先提供最有价值的功能，通过频繁迭代能与客户形成早期的良好合作，及时反馈提高产品质量。敏捷小组关注完成和交付具有用户价值的功能，而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写详细需求，敏捷使用用户故事来罗列需求。用户故事是一种需求的轻量级技术，它没有固定的形式和强制性的语法。但是有一些固定的格式可用来参考，颇为有益。敏捷估算中使用了这么一个模板：“作为【用户的类型】，我希望可以【能力】以便【业务价值】“。使用基于用户故事的需求分析方法时，仍可能需要原型和编写文档，只是工作重点更多转移到口头交流。

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

敏捷过程参与者不怕变化，他们认为改变需求是好事情，因为这些改变意味着我们更了解市场需求。

3.经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付时间间隔越短越nice。

迭代受到实践框架限制，意味着即使放弃一些功能也必须按时结束迭代。只要我们可以保证交付的软件可以很好的工作，那么交付时间越短，我们和客户的写作就越紧密，对产品的质量就更有益。虽然我们多次迭代，但并不是每次迭代的结果都需要交付给用户。敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功能，增加的每个功能都是经过编码测试达到可发布质量标准的。

另外敏捷开发项目中对开发阶段没有没有重要的分割，没有先期的需求阶段，然后是分析阶段，架构设计阶段，编码测试阶段等，在项目真正开始后，每次迭代中都会同时进行所有的上述阶段工作。

4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

软件项目不会依照之前设定的计划原路执行，中间对业务的理解，软件的解决方案肯定会存在偏差，所以客户、需求人员、开发人员以及涉及到的人之间必须进行有意义的、频繁的交互，这样就可以在早期发现并解决问题。

5.围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。

业务和技术是引起不确定的两个主要方面，人是第三个方面，而业务和技术又必须由人来执行，所以能够激励人来解决这些问题是解决不确定性的关键，只要个人的目标和团队的目标一致，我们需要鼓舞起每个人的积极性，以个人为中心构建项目，提供所需要的环境、支持和信任。

6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

在10-20人组成的大团队中，文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人（大团队实施敏捷时也会分成多个小的敏捷团队），所以大量的文档交流其实并不是很经济的做法。此事面对面的交谈反而更快速有效。

7.工作的软件是首要进度度量的标准。

一般的工作都比较容易衡量任务的进展，比如搬1吨的石头，只要称一下已搬运的石头重量，就知道你完成了多少。但是对于软件而言，在软件没有编码测试完成之前，我们都无法通过代码写了多少行，测试用例执行了多少个来衡量功能是否完成了。衡量此工作的首要标准就是这个功能可以工作了，对用户来说已经可以使用了。

8.敏捷的过程提倡可持续的开发速度、责任人、开发者和用户应该能够保持一个长期的恒定的开发速度。

很多人觉得软件开发中的加班是非常正常的，不加班反而不正常，然后我想说，在国内这样的国情下，都在用深圳速度来比喻发展进程，这样的社会氛围导致这一现象和认识。敏捷过程希望能够可持续的进行开发，开发的速度不会随着迭代任务的不同而不同，并不欣赏所谓的拼一拼就能完成的态度，开发工作不该是突击行为。我们不能指望说突击这个项目后可以轻松了，因为完成一个项目，后面接踵而至会有更多项目，如果是拼一拼的态度，下个项目依然会让团队成员再次突击。这时不知道有没有人会说，那我们一直加班，也是”持续的开发速度“，这时可要注意注意了，持续加班只会导致人疲劳，厌倦，保持长期恒定的速度只能成为一种理想而已。

9.不断关注优秀的技能和好的设计会增强敏捷能力。

敏捷过程有很多好的技术实践可以加强产品敏捷的能力，很多原则、模式和实践也可以增强敏捷开发能力。

10.简单---使未完成的工作最大化的艺术---是根本的。

我们不可能预期后面需求会如何变化，所以不可能一开始就构建一个完美的架构来适应以后的所有变化。敏捷团队不回去构建明天的软件，而把注意力放在如何通过最简单的方法完成现在需要理解的问题。这时可能有人会说，我已经预计到了肯定存在哪些需求扩展点，我们是否一开始就应该要考虑呢？这时团队需要根据自己的理解去决定是否考虑，如果深信明天发生了这个问题也可以轻易处理的话，那么就最好先不考虑。

11.最好的架构、需求、设计都出自于自组织的团队。

敏捷中有很多实践，大家都知道，迭代是开发是主要的实践方法，而自组织团队也是主要的实践之一。在自组织团队中，管理者不再发号施令，而是让团队自己寻找最佳工作方式来完成工作。要形成一个自组织团队其实比较困难。自组织团队的第一个要素就是必须要有一个团队，而不仅仅是一群人。

一群人是一帮在一起工作的人，他们彼此之间并没有太多的沟通，他们也不视彼此为一体。项目一开始，我们就会组建团队，但很多时候由架构师、需求人员、开发人员和测试人员组成的是一群人而已。他还认为，团队的形成必须经历几个时期。在经历了初期的磨合期后，成员才会开始对团队共同工作的理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩，而且这些规矩是不言而喻的。比如，每个人都知道上午九点来上班，都会主动询问别人是否需要帮助，也都会主动和别人探讨问题。如果团队成员之间能够达成这样的默契，那么这个团队将成为一个真正高效的工作团队。在这样的团队中，成员之间项目理解，工作效率非常高。在自组织团队中，团队成员不需要遵从别人的详细指令。他们需要更高层次的指导，这种指导更像是一个目标，一个致力于开发出更好软件的目标。总之，自组织团队是一个自动自发、有着共同目标和工作文化的团队，这样的团队总是在向他的组织作出承诺。但是，实现这些承诺对于自组织团队来说非常重要。否则，一旦出现问题，团队成员之间就会出现信任危机。

虽然敏捷开发小组是以小组为整体来工作的，但是还是有必要指明一些承担一定任务的角色。第一个角色是产品负责人，产品负责人的主要职责包括：确认小组所有成员都在追求一个共同的项目前景，确定功能的优先级以便总是在处理最具有价值的功能，以及做出决定使得对项目的投入可以产生良好的回报。可以对应为以前开发中的”产品经理“。另一个角色是跨职能团队成员，这里包括了架构师、设计师、程序员、需求人员、测试人员、文档编写者等。还有一个重要角色就是团队促进者，也被称为项目经理、SCRUM主管，项目团队领导或者团队教练。敏捷开发的团队促进者会更多的关注仆人式领导而不是管理。

12.每隔一定的时间，团队会在如何更有效工作方面进行反省，然后对自己相应的行为进行调整。

由于很多不确定性因素会导致计划失效，比如项目成员增减、技术应用效果、用户需求的改变、竞争者对我们的影响等等都会让我们做出不同的反应。敏捷不是基于预定义的工作方式，而是基于经验性的方式，对以上这些变化，小组通过不断的反省调整来保持团队的敏捷性。

如果我们把这些原则和遇到的问题对号入座，很快我们会发现，这12项原则正是对应了客户期望，比如：客户不会关心开发文档写成啥样，他们更感兴趣交付的产品能干什么；他们不在意你的开发计划，他么你希望你能立马交付；他们想要修复个bug，而不是等下次版本更新。

我们总会遇到需求多样化的客户，而这时敏捷能够确保你在研发过程中始终将用户需求作为核心。

综上述，敏捷究竟该如何定义？

PMI于2018年首次出版《敏捷实践指南》，本书是美国项目管理协会新发布的敏捷实践标准，当中对敏捷的描述是：敏捷是一种思维模式，由《敏捷宣言》的四条价值观所界定，以《敏捷宣言》十二原则指导，并通过各种实践实现，敏捷实践者根据自身需求选择不同的实践。

《敏捷宣言》价值观、原则和通用实践之间的关系

常用的敏捷实践有：

Scrum、XP极限编程、水晶、DSDM动态系统开发、FDD功能驱动开发、AUP敏捷统一过程、精益、看板、OpenUP，相关内容后续文章继续介绍。