谈敏捷之“伪敏捷”

我们发现很多团队在做敏捷转型的时候热情高涨，学习了各种敏捷方法，工具，可是执行一段时间的敏捷以后会发现不是每个sprint都有可以demo 的进度，产品设计者并不会根据sprint的反馈澄清不清晰的需求，每个team的燃尽图都很漂亮，可是最后release却总是delay。

之所以会造成这些问题的原因在于，你只是学习了敏捷的形而不是敏捷的神。以学武为例，只学了招式，却没有去学内功，到头来发现招式全会，可是真正要用的时候却发现一招也用不上，这时候你就会认为“武术不过是花架子，中看不中用“。

推动敏捷常见的误区有：

• 应付式敏捷，不打算通过敏捷真正改变组织结构，开发方式，而是把敏捷当作是一场应付上级的短暂的运动。
• 生搬硬套式敏捷，把敏捷的中的某一个具体的实践，比如scrum的流程生搬硬套，完全不考虑本身的情况。
• 工具式敏捷，使用各种敏捷工具来管理，却没有配套的流程和价值观。
• 极端式敏捷，敏捷宣言中提到的“工作的软件 高于 详尽的文档”， 于是提倡零文档，导致工作上过多的不必要的时间用于交流和沟通。

为了避免出现“伪敏捷”我们需要弄清楚什么是敏捷，接下来我会给大家介绍以下内容：

• 什么是敏捷
  敏捷的价值观和原则
  敏捷的具体实践
• 如何识别出伪敏捷
  什么是“伪敏捷”
  如何区别“伪敏捷” 和 “真敏捷”
• 如何正确使用敏捷

1 什么是敏捷

在Ahmed Sidky启发下提出的模式将敏捷明确表述为一种思维模式，它由“敏捷宣言”的价值观所界定，受“敏捷12条原则”指导，并通过各种实践实现。

1.1 敏捷的价值观和原则

敏捷宣言（价值观)：

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

敏捷12条原则：

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

1.2 敏捷的具体实践

敏捷是是一种思维，是一套价值观和原则，而在这套思维下会有各种不同的具体实践，比如 Scrum，Kanban，LeSS等。 如果把敏捷看作膳食指南的话，那 Scrum，Kanban， LeSS则是具体的某一道菜。

根据团队的大小，敏捷实践有如下几种：

2 如何识别出伪敏捷

首先需要明确的一点是，敏捷是一种思维，我们并没有一个标准的方法用来衡量什么是敏捷。我们这里说的“伪敏捷”是指敏捷的实施上的“伪敏捷”。

2.1 什么是“伪敏捷”

下图来自于美国国防部 （ US Department of Defence DoD），我们可以用它用来区别什么是一个成功的敏捷框架，什么是一个“伪敏捷”。

某种程度上说，“伪敏捷“是一种浪费。

虽然敏捷拥抱变化，不过一般一个迭代中确认的需求是尽量不变的。如果PO经常乱插入需求，毫不考虑已经排入迭代的计划，团队则需要花费大量的时间处理这些插入的需求，导致大量的工作无法如期进行。

比如很紧的上线计划，导致计划会议的估点形同虚设，团队超负荷工作上线产品，导致产品质量很难保证，出现技术债，和返工。

更典型的是，披着敏捷外衣的传统瀑布开发，比如print 0 用来设计，sprint 1 -3 用来开发， sprint 4 用来测试，这是违背敏捷第3条“经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。”

2.2 如何区别“伪敏捷” 和 “真敏捷”

我将从以下5个方面分析“伪敏捷” 和 “真敏捷” 的区别。

a. 和客户的交流

• 真敏捷：开发团队深刻认识到和客户交流，以及让客户参与到团队的开发工作中的重要性。 团队会主动让客户知道团队的开发进度，以及主动从客户那获取反馈。
• 假敏捷：开发团队并不喜欢和客户交流，也不会主动持续的从客户那获取反馈。

b. 尽早交付有价值的内容

• 真敏捷：快速迭代，每个迭代都有可以交付价值的东西
• 假敏捷：每个迭代很少甚至没有可以交付的东西

c. 责任感

• 真敏捷：团队成员很积极主动，主动承担责任
• 假敏捷：团队成员不愿意承担责任

d. 自动化流程

• 真敏捷：流程尽可能自动化，减少无谓的手动操作
• 假敏捷：流程中很多是靠手动进行

e.对于产品功能的重视程度

• 真敏捷：关于工作软件的迭代增量开发，对于用户的反馈在每一步中都非常重视
• 假敏捷：只关于流程和需求文档，对于工作的软件和用户的需求完全不在意，总是形式化的说，放到下一个迭代。

3 如何正确使用敏捷

在正确使用敏捷中，我们可以借鉴日本剑道中的思想，那就是“守破离”，大概意思就和中国的武侠小说里面练剑的境界类似。

守，就是要遵循既有的招式，一丝不苟地练习，“心中无剑，手中有剑”；

破，就是要根据自己的情况，对招式中不合适的地方做局部的改善，做到“心中有剑，手中有剑”；

离，当然就是最高的境界，从更高层次得到新的认识并总结，自创新招数另辟出新的境界。

具体的落地方案将会在我后面的文章中提到。