敏捷开发发展和优缺点 2

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 优点

更快交付价值

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

更低的风险

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

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

拥抱变化

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

更好的质量

敏捷提倡高频率的交付有价值的产品

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

持续改进

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

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

更高的客户满意度

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

更高的团队满意度

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

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

更大的灵活性

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

2.3.3 缺点

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

很难进行准确的资源规划

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

很难准确的定义“轻量的“或必要的文档

敏捷倡导的是用工作的软件即文档**（核心是代码即文档）**。

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

很难把握整体产品的一致性

增量交付可能有助于更快地将产品推向市场，但这也是敏捷方法论的一大缺点

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

很难预测有限的终点

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

很难有效地进行度量

由于敏捷是以增量的方式交付的，所以跟踪进度需要你跨周期地看，而 "边走边看 "的特性意味着你不能在项目开始时设置很多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。”

这就尴尬了，在国内很多程序员眼里，技术的地位已经被无限拔高，甚至成了一种社会地位的衡量标准：你懂的技术多=你是牛人=你讲的话就是对的；这个技术你都不懂=你不如我=你讲的话我为什么要听？又或者成了一种解决问题的万能钥匙：这个版本的产品质量不好，是因为现在这个技术已经过时了，下个版本我们换种新技术。 遇到什么问题都归因于技术，总是寻求换新技术以期望能解决问题，而不是真真正正踏踏实实去解决眼前的工作方法问题，已经成为国内程序员群体中一个普遍存在的现象

2.5.3 急功近利，肆意浪费

我们都知道无论是敏捷开发还是精益创业里面都强调的一个原则是：通过不断地快速试错来做正确的事情。精益创业里提出的最小化可行产品（MVP，minimum viable product）就是这一点的充分体现——通过开发最小化可行产品，以最低的成本来达到快速试错的目的，找到一条正确的道路，最终做出符合用户期望的产品。

然而在国内这几年的创业浪潮中，一批批的创业公司出现，又一批批地死掉。仔细分析这些“昙花一现”的公司就会发现，它们的模式都很相似：一个点子加PPT就能拉来投资，然后招几个培训班速成的开发人员，按照需求说明书做出产品，然后继续拉风投，继续招人……直到哪天融不到钱了，资金链断裂，就作鸟兽散。CEO拍拍屁股走人，也没有任何损失，继续去开下一家公司。对他们来说，做一款产品几乎没有任何成本，失败也就失败了，根本不需要什么MVP试错，直接用产品试错好了。

在这种环境下，不会有人关注什么产品质量和效率，反正做出的东西能够继续忽悠投资人就行。换言之，融到钱才是最重要的，至于我这个产品质量如何？是不是可行的？如果不行会浪费多少资源？都不是问题。甚至有人曾经问我：“连生存都不能保证了谁还去管什么质量和效率？”我到现在都觉得他问得好有道理，竟无言以对，似乎我反而成了那个问他们“何不食肉糜”的人。

2.6 敏捷开发方法

现在很多的企业都在选择一种敏捷开发应用程序的方式，提高企业数字化转型的效率，敏捷开发是一种方法的集合，那么主流的敏捷开发方式有哪些呢，其中最主流的敏捷开发方法有SCRUM以及XP

2.6.1 SCRUM

SCRUM是一种迭代的增量化过程，用于产品开发或工作管理，是团队合作开发产品的一种方式，而需求在开发过程中会快速变化。

使用Scrum进行产品开发时，会分成几小块，每块都基于先前创建的块，一次只制造一小块产品就可以鼓励创造力，并使团队能够响应反馈和变更，从而准确而准确地构建所需的产品，与XP不同，Scrum方法包括管理和开发过程。

2.6.2 XP（极限编程）

XP（极限编程）的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。

它提倡在较短的开发周期中频繁地“发布”，每个发布都伴随着几次迭代， 当产品发布具有足够的功能以满足用户需求时，团队将终止迭代周期并发布软件。

极限编程的其他元素包括：结对编程，持续集成，仅添加特定版本所需的功能。

用户编写故事，可以帮助团队估计构建发布和定义验收测试的时间， XP团队的一部分用户在构建软件时增加了详细要求。 这使需求随着用户和开发人员定义产品的外观而发展

2.6.3 区别