敏捷开发

1. 概述

	随着软件开发技术的不断发展，现在出现了很多种不同的开发模式，其实敏捷开发已经成为现在很多企业开发应用程序都想要选择的开发方案，那么什么是敏捷开发呢？

1.1 四种开发模式
1.1.1 瀑布式开发
瀑布式开发是一种老旧的，正在过时的计算机软件开发方法，最开始的软件行业普遍采用这种方法，但是这种方法套用自传统工业生产，不适应计算机软件开发的具体情况

	瀑布式开发是由 WW.Royce 在 1970 年提出的软件开发模型，是一种比较老的计算机软件开发模式， 也是典型的预见性的开发模式。

	在瀑布式开发中，开发严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤进行，步骤的成果作为衡量进度的方法，例如需求规格、设计文档、测试计划和代码审阅等， 瀑布式开发最早强调系统开发应有完整的周期，且 必须完整地经历每个周期内的每个开发阶段，井系统化地考量分析所涉及的技术、时间与资源投入等。

1.1.1.1 优点
有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率

1.1.1.2 缺点
开发过程一般不能逆转，否则代价太大；
实际的项目开发很难严格按该模型进行；
客户往往很难清楚地给出所有的需求，而该模型却要求如此。
软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。
1.1.1.3 使用场景
用户的需求非常清楚全面，且在开发过程中没有或很少变化
开发人员对软件的应用领域很熟悉
用户的使用环境非常稳定
开发工作对用户参与的要求很低
1.1.2 螺旋模型
螺旋模型由巴利·玻姆(Barry Boehm)于1988年提岀，该模型融合了瀑布模型、快速原型模型，它最大的特点是引入了其他模型所忽略的风险分析，如果项目不能排除重大风险，就停止项目从而减小损失，这种模型比较适合开发复杂的大型软件。

	螺旋模型将整个项目开发过程划分为几个不同的阶段，每个阶段按部就班地执行，这种划分方式采用了瀑布模型，每个阶段在开始之前都要进行风险评估，如果能消除重大风险则可以开始该阶段任务。

	在每个阶段，首先构建软件原型，根据快速原型模型完成这个迭代过程，产出最终完善的产品，然后进入下一个阶段，同样下一个阶段开始之前也要进行风险评估，这样循环往复直到完成所有阶段的任务，螺旋模型的若干个阶段是沿着螺线方式进行的。

在每个螺旋周期内按四个象限，分为四个工作步。

第一，制定计划：确定软件目标，选定实施方案，明确项目开发的限制条件；
第二，风险分析：分析所选方案，识别风险，通过原型消除风险；
第三，开发实施：实施软件开发；
第四，客户评估：评价开发工作，提出修正建议，建立下一个周期的计划。
1.1.2.1 优点
实质上相当于在瀑布模型的每个阶段开始前引入风险分析，并由客户对阶段性产品做出评审，这对保证软件产品质量十分有利；由于引入风险分析等活动，测试活动的确定性增强了；螺旋模型最外层代表维护，开发与维护采用同样方式，使维护得到与开发同样的重视

1.1.2.2 缺点
主要适合内部开发，否则风险分析必须在签订合同前完成，或者争取客户的最大理解；只适合大型软件项目的开发，否则，每个阶段的风险分析将占用很大一部分资源，增加成本；对开发人员的风险分析能力是极大的考验，否则，模型将退化到瀑布模型，甚至更糟

1.1.3 迭代式开发
迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率

在迭代开发中，整个开发工作被组织为一系列的短小的，固定的长度(如3周)的小项目，被称为一系列的迭代，每一次迭代都包括了定义、需求分析、设计、实现与测试。

	采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或者业务逻辑的开发工作，再通过客户的反馈来细化需求，并开始新一轮的迭代

1.1.3.1 优点
与传统的瀑布模型相比较，迭代过程具有以下优点

降低了在一个增量上的开发风险，如果某个迭代完成后的软件不符合客户要求，那么损失只是这一个开发有误的迭代的花费
降低了产品无法按照既定进度进入市场的风险，通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙
加快了整个开发工作的进度，因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的，因此，迭代过程这种模式使适应需求的变化会更容易些。
1.1.3.2 缺点
对产品人员的节奏把控能力（定每周目标，需求优先级剖析，以及临时需求的处理）有较高要求，不然容易陷入每周发版日加班加死的节奏

初期产品用户规模小，性能并不是主要瓶颈
团队里面没有优秀的架构师，优化力不从心。
后端架构优化是个慢活，它不像产品功能层面的迭代那样可以快速被感知，对于强产品驱动而非强技术驱动的公司来说，不够重视。
后端架构优化更是个细活，它也不像产品功能一样有很明显的“产出”，对于不懂技术的领导或者以KPI为导向的公司文化来说，员工去优化后端的意愿并不强烈。
产品交付进度压力比较大，没有时间去思考架构的优化，精力都在聚焦怎么实现功能上面
1.1.4 敏捷开发
敏捷开发（Agile）是一种以人为核心、迭代、循序渐进的开发方法，在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征

	简单地来说，敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本，然后在后续的生产周期内，按照新需求不断迭代升级，完善产品

1.1.4.1 优点
敏捷确实使得项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品，敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。

1.1.4.2 缺点
但敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。

2. 敏捷开发

敏捷是世界上使用最广泛，最受认可的软件开发框架之一，大多数组织已经以某种形式采用了它，但是在采用计划的成熟度方面还有很长的路要走

	敏捷软件开发是基于敏捷宣言定义的价值观《敏捷软件开发宣言》和原则《敏捷软件的十二条原则》的一系列方法和实践的总称。

	自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案，换句话说敏捷开发是一种应对快速变化的需求的一种软件开发能力，只要在符合价值观和原则的基础上能让开发团队拥有应对快速变化需求的能力，这就叫做敏捷开发。

2.1 敏捷宣言
在2001年，17位敏捷方法论的拥护者和倡议者聚集在犹他州的雪鸟滑雪场，起草了一份陈述敏捷组织原则的文件，这份文件基本上代表了不同敏捷方法论的共同点。

	当你读到这个宣言，你会发现它具有最高原则性，因为敏捷方法论在最高层面上是一致的，但到具体细节上每种方法都会不同。

	参与者们分享了互相竞争的几种方式：极限编程（XP）；透明化；自适应软件开发（ASD）；特征驱动开发（FDD）；动态系统开发方法（DSDM），所有这些方式都是“轻量版”的框架，因为这些方法使用更少，更简单的规则来适应快速变化的环境，不少与会者都觉得“轻量”这个术语非常适用。

	经过为期三天的讨论，他们在价值观和原则层面上达成共识，选择了 Agile 一词并为其赋予了特殊的意义，制定并发布了软件行业历史上最为重要的文件之一：敏捷宣言。

	参会者将自己命名为“敏捷联盟（ The Agile Alliance ）”，希望能够帮助软件行业中的其他人以新的、更敏捷的方式思考软件开发、方法和组织。而“敏捷宣言”则被展示在一个网站上（ https://agilemanifesto.org/ ） ，到目前已被翻译成了60多种语言，并作为一种信仰被推广至全球以及非软件行业。

2.1.1 敏捷宣言解读
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值观：

个体和互动 高于 流程和工具；（个体与交互：团队各个成员的能力与团队间的沟通）

工作的软件 高于 详尽的文档；(以结果为导向）

客户合作 高于 合同谈判；（注重客户参与）

响应变化 高于 遵循计划；( 敏捷 要求有开放的工作环境，确保团队及时高效地进行沟通）

也就是说，尽管右项有价值，我们更重视左项的价值。

2.1.2 敏捷宣言价值观
2.1.2.1 个体和互动高于流程和工具
项目是通过人来完成的，流程和工具可以帮助人，但绝不能自行完成工作。

	虽然，过程和工具都是好东西，但是它们有时也会成为障碍，面对面的直接沟通，比一些流程性的文件和工具沟通，效率要高出很多，当然最好的是，在沟通后就多方达成的共识形成一个简要性的文档备录。

2.1.2.2 工作的软件高于详尽的文档
可用软件的价值是很重要的，因为软件是为业务目标提供支持的，是可用软件(而不是文档)为客户传递了高价值

	一般来说，一个敏捷项目的进展情况是由开发了多少可用软件来跟踪和报告的，但不是说文档一无是处，适量的文档在绝大多数的项目中是有益的和必要的，敏捷通过寻求“刚好足够”的文档来避免这种情况，其中的原则是任何文件的创建都应与为客户创造的价值直接挂钩，且不论该价值体现在现状还是将来。

2.1.2.3 客户合作高于合同谈判
这对价值观的核心是越接近你的客户越好。

	客户最清楚他想要什么，即使在需求明确过程中也会包含一些试验和错误，在合同谈判期间，试图避免所有的尝试和错误不发生是不现实的，也是徒劳的，定位你与客户的关系很重要，你是选择对抗你的客户还是选择与你的客户一起为接近方案努力而使每个人都受益？敏捷团队更愿意和客户在同一方向一起使劲而不是把力气花在背离客户的方向。

2.1.2.4 响应变化高于遵循计划
任何一个曾在软件项目工作过的人都知道这些项目的本质就是变化。

	即使底层的技术也在快速变化，新的途径和可能性在不断的被打开，对变化响应的速度就决定你在市场上的灵活性，循规蹈矩的做事将被市场甩在后面，永远慢市场半拍，慢慢你的市场会被蚕食掉。

2.2 敏捷准则
除了敏捷宣言之外，还有12条准则的支持文件，为敏捷宣言提供了更多的扩充细节

2.2.1 目的：是客户满意
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户

	敏捷团队可以很快将可用软件交付到客户手中，并且是开放式地快速更新，给客户带来优先级最高地价值

2.2.2 态度：欢迎需求变更
欢迎对需求提出变更——即使是在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势

	传统项目管理中地一个原则是设法去影响和控制会导致变化地因素，敏捷项目管理预期到需求会发生变化，并在实际过程中欢迎拥抱这些变化，即使这些变化发生在项目后期，迅速应对和适应变化能给客户带来显著地竞争优势，从而应对新的机遇。

2.2.3 关注：客户需求的软件
要不断交付可用的软件，周期从几周到几个月不等，且越短越好

	不同的敏捷方法论采用不同的迭代周期，但都是相对较短的，关键是能快速把可用的软件交付到客户手上并能利用软件获得有意义的回报，较短的迭代周期为团队提供架构并强化团队持续关注客户的价值。

2.2.4 合作：打破隔阂
项目过程中，业务人员与开发人员必须在一起工作

	敏捷项目管理，让业务人员和开发人员彼此靠近，并时常让他们在同一个地方一起工作，通过这样的方式让业务人员和开发人员之间没有隔阂，是因为业务人员和开发人员的共同目标就是通过可用的软件向客户传递价值。

2.2.5 核心：团队成员
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务

	传统项目管理，常对员工进行微观管理，不仅告诉他们要做什么，还告诉他们如何做，无意间形成自上而下的管理方式，敏捷项目建立了一支强有力的团队并积极避免微观管理，要求一个自律的团队，自发告知开发人员做什么，提供相关资源，给予鼓励，相信团队能够完成任务。

2.2.6 沟通：面对面
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈

	非正式口头的沟通在敏捷项目管理中远比正式的书面沟通更普遍，其想法是两个人坐在一起为一个解决方案努力会比他们用邮件来来往往或交换文件更有效率，面对面沟通是敏捷项目管理的精髓，这种沟通是公开的，任何团队成员都可以自由参与对话。

2.2.7 标准：可工作的软件
可用的软件是衡量进度的主要指标

	计划和文档可能是有用的，但是当最根本的目标发生变化时，它们就可能失去应有的价值，传统项目往往极其纠结的是，项目的不断更新使得文档成为一种负担，真正的价值是通过结果来表达的，结果又是通过可用的软件来呈现的。

2.2.8 倡导：可持续开发
敏捷过程提倡可持续的开发，项目方、开发人员和用户应该能够保持恒久稳定的进展速度

	可持续开发的焦点是在团队身上，他们会努力保持一个稳定的可持续的进展速度，从而使得团队成员不会在迭代周期的尾端匆忙赶工，理想的目标是保持一种可持续的速度，使团队成员不会感到过度的压力和筋疲力尽，而是能够保持在一个理想的强度下工作。

2.2.9 追求：技术卓越和技术良好
对技术的精益求精以及对设计的不断完善将提升敏捷性

	设计的越完善，维护起来就越简单，即使遇到变化，稳定和优质的项目会比劣质的项目更加允许团队快速应对变化

2.2.10 根本：简洁
要做到简洁，即尽最大可能减少不必要的工作，这是一门艺术

	这个被所有的敏捷方法所拥护，尤其使精益方法，关键点对客户价值保持关注和毫无犹豫的削减不增加价值的活动，保持简单不只是一种愿望，它使最基本的原则。

2.2.11 团队：自组织
最佳的架构、需求和设计出自自我组织的团队

	自我组织是敏捷团队的核心元素之一，当一个团队是自我组织型的时候，说明该团队自己去决定工作如何分配及谁去做某个特定的工作，而不是人力资源部门或管理层来决定，不仅小团队是自我组织的，较大的跨职能团队也可以是自我组织的

2.2.12 调整：定期反思
团队要定期反省如何能够做到更有效，并相应的调整团队的行为

	敏捷项目中最可预见的事情就是变更，传统项目里当项目或阶段完成时开会总结是最常见的做法，而敏捷试着通过更频繁的回顾来完成这项工作，在一个回顾活动中，团队查看各迭代周期中已完成的工作或发布，并评估下一次如何改进他们的做法，每日站立会议即每天简单碰头15分钟是另一项协调团队努力方向、团队自我评定和自我调整的重要方式。

2.3 敏捷优缺点
敏捷是项目管理和软件开发的一种迭代方法，可帮助团队更快地向客户，交付价值，减少麻烦，敏捷团队不是把所有事情都押在“大爆炸”的发布上，而是以小的但可消耗的增量交付工作，需求、计划和结果会得到持续评估，因此团队拥有快速响应变化的机制。

2.3.1 优点
2.3.1.1 更快交付价值
敏捷是基于价值驱动交付，项目团队要频繁的且尽快的给客户交付可以使用的产品，并尽早的让让产品投入市场可以尽早的验证其商业模式和商业价值，这是敏捷提倡的核心价值之一。

2.3.2.2 更低的风险
敏捷提倡优先交付高价值、高风险的需求，然后交付高价值、低风险的需求、再交付低价值、高风险、最后低价值、低风险的需求。

	这样的好处是把最高风险的需求在项目的初期就开始做，可以最早发现该产品是否可行（通常只要1~4周）。如果因为市场、技术或者其它原因失败了，可以及时停止该项目，降低项目风险，即使这个项目失败了，这个失败的代价相对来说小一些。

2.3.2.3 拥抱变化
因为市场在变化，用户的期望和要求在变化，客户的需求也会随着这些因素的变化而变化，只有及时响应这些变化，并尽快予以实施，才能帮助客户在瞬息万变的市场中保证竞争力和吸引力，而敏捷能够帮助团队在小步快跑的过程中能够快速的响应变化。

2.3.2.4 更好的质量
敏捷提倡高频率的交付有价值的产品

	每天的例会、迭代计划会议、迭代评审会、迭代回顾会议都在对可交付成果质量上进行层层把关，因为在这几个会议中会频繁讨论遇到的问题/解决方案，验收标准等等，同时，也会邀请项目干系人参加迭代评审会并对可交付成果验收和反馈，这样团队可以及时予以调整，以确保质量。

2.3.2.5 持续改进
敏捷提倡不断调整和优化，并在每个迭代的迭代回顾会议进行分析、讨论、总结敏捷当前迭代开发过程中需要改进或者要提升的地方，进而在下个迭代中改进、调整和优化。

	这是整个团队成员不断学习，不断提升自己经验、技能的一个很好的机会，另外，因为敏捷强调客户参与的重要性，对于客户的反馈意见和建议，开发团队也会及时给与相应以及反馈，让双方可以更好的合作，建立更加信任的合作关系。

2.3.2.6 更高的客户满意度
敏捷提倡尽早和频繁的为客户交付有价值的产品，以确保更高的质量，更高的成功率，为客户尽早带来商业投资回报率的机会。

2.3.2.6 更高的团队满意度
敏捷提倡仆人式的领导，SM需要给团队工作上的指导、帮助和支持，扫除团队成员工作上遇到的问题和障碍，重视并尊重团队成员的想法和意见，授权团队并引导团队成员自组织和自管理，更重要的是，团队成员可以决定要做什么、怎么做、什么时候做，并自己监控和管理工作进展，对结果负责；

	团队成员可以一起讨论并确认工作协议，确保考虑并接纳每个人的意见；团队成员可以一起评估故事点；同时，SM要引导团队成员之间相互协作并促进合作，通过这些，团队成员可以更高效的工作，交付的质量也会提高，团队成员的满意度也会大大提高，"A happy employee is a productive employee"，不是吗？

2.3.2.7 更大的灵活性
敏捷基于价值驱动，它的项目范围是可以灵活调整的，这就给项目干系人很多的灵活性来根据市场不断调整需求范围、变更以及优先级等等，另外，敏捷提倡频率与团队和客户沟通交流，并不断根据反馈和意见调整管理方法、需求流程、开发流程以及运维流程等等，还有，验收标准，都可以根据实际情况进行调整。

2.3.3 缺点
尽管敏捷带来了很多改善，但是再次重申它并不是适合所有人和所有情况的，因此，了解敏捷的不足显得特别重要，知道这点后，你心理上是准备好的并且会根据具体情况来做裁剪和优化来规避或减少负面影响。

2.3.3.1 很难进行准确的资源规划
由于敏捷团队不是一开始就知道产品“最终的样子”，而是在过程中探索用户的需求逐渐知道产品真正的终局状态，这样一来就给前期的规划（成本，时间，资源）带来了很大的挑战（项目越大越复杂这一点变动更加明细）。

2.3.3.2 很难准确的定义“轻量的“或必要的文档
敏捷倡导的是用工作的软件即文档（核心是代码即文档）。

	整个项目用于产品开发的文档不是一开始准备好的（甚至都没有RP原型设计），而是在过程中”及时的“ just-in-time准备出来的，因此，我们看到的是非常简单的且常常被放在最后处理的文档（在项目中涉及到移交或问题分析时这一点显得尤其突出）

2.3.3.3 很难把握整体产品的一致性
增量交付可能有助于更快地将产品推向市场，但这也是敏捷方法论的一大缺点

	因为当团队在不同的周期内对各个组件进行开发时，整体的输出往往会变得非常零散，而不是一个内部紧密集合的整体

2.3.3.4 很难预测有限的终点
敏捷在一开始要求最低限度的规划，这使得交付新的、意想不到的功能时很容易偏离方向，此外，这意味着项目没有限定的终点，因为从来没有一个明确的 "最终的产品"样子。

2.3.3.5 很难有效地进行度量
由于敏捷是以增量的方式交付的，所以跟踪进度需要你跨周期地看，而 "边走边看 "的特性意味着你不能在项目开始时设置很多KPI，这种长期的游戏使得衡量进度变得相对困难。

2.4 为什么敏捷越来越流行
2.4.1 利益相关者
敏捷开发保证了项目中所有利益相关者的利益，不论是客户、项目管理、开发团队或测试小组。

	每个人对项目都有清晰的可见性，这是成功的关键点所在，敏捷开发原则上鼓励用户积极地参与，不论是产品开发，或是团体协同的方方面面。这对关键利益相关者提供了非常好的可见性，包括项目的进度或是产品本身，最终这有利于保证产品预期的效果。

2.4.2 高效的团队
Aglie团队是自发组织的，这意味着他们有权利和责任去审核生产所有者直接干预的工作。

	这与大多数non-agile项目不同，项目管理者有责任给团队分配任务，或者甚至是团队成员，这给予团队一种自主感，提高团队士气，最终增加生产率。

2.4.3 市场速度
由于传播速度快，我们能更快地响应市场，因此有更高收入

	这一切增加客户满意度的关键因素是敏捷应用开发。

2.4.4 质量
在项目中梦寐以求的代名词是质量。

	不像传统的瀑布模型，等到开发完成才开始测试，可是在敏捷开发中，我们随着需求的准备便开始进行测试。因此，测试集成贯穿整个开发周期，使得工作产品像开发一样去定期检查。这允许工作所有者有必要时做出适当调整，以及及早的给产品团队检查出任何质量问题。

2.4.5 有趣
实践敏捷最好的一点就是它很有趣

	整个团队都积极的参与，使得整个工作空间和氛围均因为这种积极参与和互相之间的协作配合而变得更有意思。有很多有趣的方式比如用计划扑克牌游戏和卡片来评估任务，采用生动新颖的任务面板来讨论工作的进展， 用全新的方式来管控例会以及许多敏捷项目中其他更有趣的东西。据我的经验，这是对每一个人都能受益的方法。

2.5 为什么国内敏捷很难实施
自然是因为很多公司尝试过，然后失败了，便觉得敏捷项目管理不行

	关于为什么会失败，国外资深敏捷教练在深入调查后在《Scrum在亚洲难以实行》一文中总结了四点原因

不一样的教育方式：人们习惯于遵循体制，与敏捷思想中的“自我组织”、“自我管理”相违背
性格普遍偏内向，很难像西方人一样在大众场合下发言
组织内犯错很大程度是不被允许的，与敏捷思想中“快速试错”理念背道而驰
外包泛滥，所有的行为都倾向于节约成本

	这四点刚好切中了要害，精确地概括了敏捷在亚洲难以落地的主要原因

2.5.1 勤于苦干，懒于思考
在国内，绝大部分公司都还没有认识到软件开发是一项知识性工作，普遍对软件开发的理解还很肤浅，以为可以通过加人、加班来加快软件开发的进度，更悲催的是，很多员工自己也没有认识到这一点，每当问到为什么项目进度落后的时候，他们的反应总是抱怨“人手不够”，而提出的解决方案就是“加班”，这种意图使用蛮力来达到目标的行为，恰恰体现出了国内不少软件开发人员的一大特点——“勤于苦干，懒于思考”

2.5.2 崇尚技术，轻视方法
在国内，如果要形容一个程序员很牛，必然是说他懂得多少尖端技术，会哪些语言，参与了哪些项目……如果你跟人讲你了解敏捷开发的理念，精通哪些方法论，知道什么流程应该如何改进，不出意外你得到的反馈就是：“那些都是虚的，你懂哪些实实在在的技术？”或者引用Linus Torvalds的名言：“Talk is cheap，show me the code。”