”假敏捷“和”真敏捷“--大家都在走向敏捷的路上！

最新推荐文章于 2020-08-01 21:15:18 发布

转载最新推荐文章于 2020-08-01 21:15:18 发布 · 413 阅读

2 ·

CC 4.0 BY-SA版权

原文链接：https://github.com/swtbokcn/AgileTest

本文探讨了敏捷开发转型中的常见困惑，即项目是否真正实现了敏捷。通过分析敏捷宣言及其原则，指出所有项目既是‘真敏捷’也是‘假敏捷’的本质，并强调持续改进的重要性。

很多团队在从传统开发模式向敏捷开发转型的过程中，都会遇到困惑：那就是现在我们做的算是“真”敏捷吗？

当团队准备向敏捷转型的时候，大家都会先热情高涨的去学习各种敏捷知识，包括前面章节提到的原则、实践和工具等。兴奋的感觉找到了圣杯。但是一旦开始真的实施敏捷后，很快就要面对各种残酷的现实：

哪里找到那么好的客户能够经常来互动？
说好的持续构建和集成保证质量，怎么一跑测试程序就飞了？
每个迭代都回顾，但是技术债务却是越来越多？
不是over文档嘛，怎么还要写这么多文档？
说好的自组织团队呢，还不是领导说了算！

当在敏捷转型过程中出现各种问题的时候，大家可能会感觉自己参与一个“假敏捷“的项目。

所有敏捷项目都是“假敏捷“

首先来看一个经常出现的敏捷的伞图。

敏捷其实是个大杂烩，而且在不断的变化。从敏捷的历史和敏捷宣言的发表就能够看出来。其实是先有的各种实践和流程，后来才汇总成为一个统一的说法”敏捷“。所以敏捷包括的内容很杂，有流程相关的Scrum，有包括各种实践的XP，还有其他各种方法。

之所以说所有敏捷项目都是”假敏捷“，那是因为完美的敏捷本来就是不存在的。看着上面的这个敏捷的伞图，包含了这么多的内容。从来就没有一个项目会把所有的敏捷内容都用上。当然敏捷从来也没有要求尽可能多的去实施所有内容，反而是鼓励循序渐进，持续改进。即使只实施了一部分敏捷实践，也没有哪个项目敢说自己实施的实践都已经做到完美，不需要改进了。

以看板为例。看板是很多敏捷团队都在使用的。但是很多团队只是利用看板的可视化这个特定。看板其实还涉及到并行任务的限制、工作流的优化等，很多敏捷团队可能都用到。但是这并不妨碍看板给很多敏捷团队带来的好处。

所以说在向敏捷转型的过程中，不用纠结于某些原则或实践是否符合理想的敏捷的定义。更关键的是，要不断的持续改进，不断的更加敏捷。

所有敏捷项目也都是”真敏捷”

上面刚说了所有敏捷项目都是“假敏捷”，这里怎么又说都是”真敏捷呢“？

很多在实施项目转型的团队最喜欢问的一个问题就是：你觉得我们这样算敏捷吗？

到底什么项目算敏捷呢？这个问题其实也很简单。上面我们看到，从来没有任何一个项目能实现所有敏捷包括的内容的。所以，你所在的项目只要**”部分“**符合敏捷宣言的要求，其实就可以算是敏捷了。

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

如果觉得，这个太抽象了。就换成敏捷的12个原则。仍然是只要部分，就可以算是敏捷了。

1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2.欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7.可工作的软件是进度的首要度量标准。
8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10.以简洁为本，它是极力减少不必要工作量的艺术。
11.最好的架构、需求和设计出自自组织团队。
12.团队定期地反思如何能提高成效，并依此调整自身的举止表现。