在我很小的时候，家里人给我起了一个绰号：“Bu’why”，这是因为我总是向周围的人问为什么。大多数时候，他们会尝试解答我的问题，但是后来他们给我的这个绰号中也流露出了他们的挫败感。
直到现在，我依旧执迷于事物背后的真正原因。因为我想知道交通拥堵背后的真正原因，于是我读完了一整本关于交通模式的书籍。因为我想尝试得到更好的休息，我读完了一本关于睡眠的书籍。我坚信，‘为什么’是至关重要的。
最佳实践
已经被公认或确定的是正确且最高效的商业、专业流程。（维基百科）
不幸的是，大多数人想要的是“什么”而不是“为什么”。他们需要处理的事情太多了，他们需要的是能解决他们手上的问题的现成的解决方案：节流、软件模型、制定计划、软件开发方法论、只要你坚持下来，你就能得到承诺于你的一切。
“我们上一次尝试的系统因为其自身的先天缺陷被视为一个失败品，而这个新系统比上一个更好，这一次一定非常棒。”， Holy Grail 说。可能借助新系统事物的发展不至于太糟糕，但是对其抱有的期望高的有点不切实际了。没有人变得更开心，因为实际上并没有显著的提升。这到底是为什么？
软件开发很复杂
2012年，当我在Nordstorm创新实验室工作时，我第一次知道了Cynefin框架。它着眼于给定系统的复杂度，然后来决定什么样的方法可以用在这个系统上。它把系统拆成了四个类别，通常用四个象限表示：
浅显的
- 系统中拥有的关系通俗易懂的而且简单
- 例子：堆放货架、修剪草坪
- 方法：确定类别，采用合适的规则集合
难懂的
- 需要足够的分析，可以预测到因果关系
- 例子：摩天大楼，X光机
- 方法：预先分析场景，确定采用的技术
复杂的
- 因果关系仅可以在回顾时得到，但是每次都不会重复
- 例子：股票市场，天气
- 方法：调查问题范围，以适应技术
混乱的
- 因果关系是无法去感知的
- 例子：自然灾害和其他紧急事件
- 方法：应对和适应
你会注意到，越复杂难预测的系统随着时间的推移，创建的那些尝试预测这个系统的规则需要做的适应修改的地方越多。道理都是类似的。就拿股票市场这个复杂的系统来说吧，他的波动规律就经常性地打脸那些尝试预测他的上涨下跌周期的股票理论的脸，作何理论在他面前都变得无用，要在这种领域有所作为，不能一劳永逸，需要不断学习和适应。
问题是:软件开发在这个连续过程中处在什么位置?有人可能会说这只不过是个工程问题，所以这就像设计建造摩天大楼那样按部就班做即可。另一些开发软件的过程中受到挫折的人，可能会说这就像历史中记载的自然灾害那样完全不可预测。
有时这很复杂，有时这很混乱无序。大多数时候，这是复杂的。
处理复杂情况
Cynefin告诉我们，没有一套最佳实践可以告诉我们如何在给定的复杂系统中采取行动。它也确实指出一些初始的启发式类的方法是有用的，而我们的重点应该是探索问题领域，并随着时间的推移调整我们的方法。
这听起来很熟悉，不是吗?每当开发团队为给定的项目采用一种新类型的功能时，不确定性就会上升。要知道一个给定的解决方案是否有效，唯一的方法是多探索一下。这就是正在开发的软件系统。还有五个复杂的系统在起作用:
- 开发团队
- 较大的组织
- 当前生产环境下的应用
- 生产环境下应用的用户
- 商务环境
上述系统中的任意一个都能轻易地导致一个排期紧密的开发项目出现问题：一堆意料之外的影响了正常业务的线上bug，开发团队成员突然的身体不适，业务方提出的关于发展方向上的改变。
这就是为什么要实施敏捷。敏捷帮助开发团队来应对前面提到的所有问题，同时建立一个随时间变化而适应当前形势的框架。敏捷向开发团队提供了一套使之变得最棒、最具有生产力的工具。
关于为什么要实施敏捷的实践
接下来会讨论一些特定的“礼仪”以及它们存在的理由。我们需要摆脱“必须”和“应该”的思维模式，我们不这么做是因为它们是必要的，我们这么做是因为我们想从中得到一些我们想要的东西。如果我们没有办法再得到我们想要的，那么我们需要作出一些改变。
- Sprints - 人类的规划能力还不是特别的强大。通过任务拆分，如果事情走向出现了问题，他们需要应对的问题就不会特别大。同时，在最开始的时候通过明确任务范围也缩小了外力因素带来的影响。
- 关于执行完成的严格定义 - 当一个任务已经完成时，确保不会留下任何需要处理的工作来避免“技术债务”。
- 故事点而不是小时数 - 确保估算是一种仅用于团队在一段时间内实现计划和执行一致性的工具。 防止管理层认为“开发团队能力不足”，或试图钻制度的空子。
- Spikes - 实际上是从Cynefin复杂域中“调查问题域”来提高确定性并且启动规划。
- Sprint 阶段成果 - 开发人员应通过实际完成的产品原型来展示他们的工作成果。庆祝本次Sprint的完成并期待下一个Sprint即将要做的工作。
- 回顾总结 - 这是敏捷关于适应机制的核心。如果你仅仅做一件事情，那就去做，但是你必须解决在回顾总结过程中暴露出的困难和其他问题。
- 待办事项列表 - 一旦Sprint启动，在业务方和开发人员之间不应该有频繁的需求变动。在准备开始一个新的sprint会议中，主要由业务方决定本次Sprint中需要完成的事项和任务，当然，有时也需要开发人员的参与。
- Sprint计划 - 这个会议的主要目的是开发人员评估任务，同时规划本次Sprint的目标。业务方应该出席会议并对关于本次Sprint中涉及的任务需要最终确认的问题负责解答确认。
现在，那些敏捷教练说的诸如“在你接受采用敏捷的早期，你的估算会被停止”的言论是有道理的。这一切都是因为你处在一个逐步适应和提高的过程中。你的估算会更精确，困难阻碍会被解决，团队也会逐步减少历史遗留下来的技术债务问题。
反馈循环
控制系统的一部分，允许其进行反馈和自我修正，以及可以根据实际输出结果和期望的理想输出结果之间的差异调整其接下来的操作。 (American Heritage® Dictionary)
敏捷可以创建一个引导你走向你的最终目标的反馈循环。每一步都是一个小的胜利，让你感觉良好，给你带来更多的胜利。它就像一个恒温器，只不过你暂时还不知道目标温度是多少。事实证明，反馈循环也是测试驱动开发（TTD）和精益创业背后的本质。
这里留给读者一个问题：如何调整你的软件开发反馈循环来使你的团队成为最棒的那个？在我的第二篇敏捷文章：可定制的敏捷中，我会为各位读者提供一些思路和想法。
致谢
本文由ZICK_ZEON和作者共同完成，在这里向ZICK_ZEON表示感谢。
参考文献
- 原文链接：10 years of Speed in Chrome
- 译文链接：为什么要实施敏捷