你真的理解敏捷吗？

看了一篇文章，是scrum的几位资深敏捷专家曾共同发表的一篇文章，提出了Scrum在亚洲难以实行，指出了几个原因，总结如下：

1. 敏捷开发需要大家当面直言问题，有悖于对别人表示尊重、留面子的文化

2. 更习惯可预见性的工作，希望预见未来，这样好去做资源规划，但是面对创造性的工作，可预见性难度极大

3. 考高分、定级别等教育方式也限制了工作中的思考方式和行为，而鼓励尝试、试错是敏捷实践的核心所在。

4. 人们习惯于遵循体制，被管理和指引驱动做事，而非自我驱动，与敏捷中的自我组织、自我管理背道而驰。

以上几点不做评论，更多的是反思。那么敏捷真的难以落地吗？问题的关键是先搞懂什么是敏捷？

什么是敏捷，敏捷开发，与瀑布开发的区别

敏捷组织、敏捷开发、敏捷测试、敏捷工具……，似乎所有的名词之前冠以敏捷都会变得高大上，敏捷的中文释义是反应迅速，当被应用到组织的时候，说的是在商业环境中组织基于流程/原则/甚至文化，可以很好的应对外部需求的快速变化；当被应用到开发时，说的是一种开发方法，实践了敏捷软件开发宣言所定义的价值观，这种开发方法最主要的特点是拥抱变化。Jim Highsmith 在《敏捷项目管理》中提到，敏捷是指在动荡的业务环境中，适应变化并创造变化，从而获得价值的一种能力。同时敏捷是平衡灵活性和稳定性的一种能力。

敏捷软件开发宣言

1. 个体和互动 高于 流程和工具：以人为本，注重合作互动。

2. 工作的软件 高于 详尽的文档：目标导向，搞清楚交付的是什么

3. 客户合作 高于 合同谈判：客户为先，理解客户需求

4. 响应变化 高于 遵循计划：允许在不断变化需求过程中确认想要的东西，敏捷拥抱变化。

敏捷开发方法：基于敏捷理念、敏捷宣言定义的价值观的实践方法都可以统称为敏捷开发方法，常见的敏捷开发方法包括Scrum、FDD、Kanban、极限编程、水晶方法，其中应用范围最广的是Scrum。

敏捷开发与瀑布开发的区别：

瀑布开发方法：基于线性的、可预见性的的开发产品，严格的流程使可调整的自由度降低，尤其在项目周期长、外部环境快速变化、初期需求不明确的情况下很容易失败。瀑布的优点是阶段清晰、环环相扣、每个环节有明确的职责分工。缺点是文档负担重、变更的成本高、周期漫长。

显然，瀑布模式无法在研发过程中直观感知并灵活应对用户的需求、产品的bug和优化项。基于敏捷理念的敏捷开发方法更强调过程中的增量高价值交付，即交付产生80%价值的20%功能，并通过合理的迭代规划，解决高优需求和问题，在过程中持续改进且拥抱变化。敏捷开发方法并非银弹，缺点包括允许需求变化会导致难以对资源进行准确的规划；资产的沉淀完备度如何把握，主要是轻量化的文档如何定义等等问题

瀑布和敏捷都有各自很强的适用范围，并非说谁优于谁。

敏捷开发不是什么

误区1：敏捷就是快

这应该是对敏捷最大的误解，从中文释义上，敏捷是反应迅速，而非单纯的快。对敏捷的理解不够深入，就会导致，组织应用了敏捷开发模式，就需要不断的加速、再加速，原来3天的工作量，必须1天干完。相反，敏捷开发保障的是研发组织的稳定性产出，而非一味的快。

误区2：敏捷不需要提前规划

产品以敏捷的开发模式迭代，由于敏捷提到了不可预见性， 所以就会被曲解为我不需要做规划，而敏捷并非没有规划，而是强调在项目中持续规划，而不仅仅是提前规划，持续规划可以保证团队在过程中有稳定的产出，并在过程中吸取教训。

误区3：敏捷不需要文档

敏捷开发中提到了“轻量化”的文档，这个度就很难精准把握，那干脆就是不需要文档。我曾经也一味的感觉以软件为导向的交付，文档是为了沟通，而直面沟通是敏捷中重要的价值观，看似逻辑自洽，实则不然。文档的目的是为了延续，为了使过程透明，为了使软件发展更平衡有序，所以这类的文档是必须的，诸如产品PRD、架构设计文档、部署文档等等。

误区4：敏捷不需要有标准流程，这样会受到制约

敏捷开发中鼓励创新和试错，并且为了凸显效率，不需要条条框框来制约，但实则不然，只有通过标准动作的约束、流程自动化，才能让整个过程更有效率。无纪律的敏捷、无指导原则指引，只会更混乱。

误区5：敏捷是一种文化，很难落地

从敏捷开发到敏捷组织，虽然最终敏捷如同创新一样， 会被视为一种文化，但往往在初期，敏捷会具象到一个个具体的动作、流程和方法上，来指导执行。

总结，研发管理、架构治理 ，以及如上提到的敏捷开发方法，其实有一个最根本的底层逻辑，那就是过程追求平衡有序，而非一味的熵增。在不破坏基本纪律和原则下稳定的发展和创新。

FB大佬对敏捷开发的看法

前同事老白先后就职于Facebook和两家创业公司，最近在沟通过程中也提到了一些对敏捷开发的看法，观点基本一致，敏捷一定有流程和纪律支撑；敏捷不是灵丹妙药可以解决所有问题；而实践敏捷所面临的常见冲突是，总有打破标准流程的事情加进来，扩大了本次冲刺的范围、打乱了研发的节奏，针对这种情况，老白认为需要从两个方面总结，第一个是团队自省，看本次冲刺规划的事项是否是紧急重要的；看是否是需求管理出现了问题，需求频繁变更；冲刺时间过长，和用户体验反馈的预期周期不匹配；第二个是组织自省，是否所有人足够尊重流程、是否所有人足够尊重PO以及研发团队。