在我很小的时候，家里人给我起了一个绰号：“Bu’why”，这是因为我总是向周围的人问为什么。大多数时候，他们会尝试解答我的问题，但是后来他们给我的这个绰号中也流露出了他们的挫败感。 直到现在，我依旧执迷于事物背后的真正原因。因为我想知道交通拥堵背后的真正原因，于是我读完了一整本关于交通模式的书籍。因为我想尝试得到更好的休息，我读完了一本关于睡眠的书籍。我坚信，‘为什么’是至关重要的。 最佳实践
不幸的是，大多数人想要的是“什么”而不是“为什么”。他们需要处理的事情太多了，他们需要的是能解决他们手上的问题的现成的解决方案：节流、软件模型、制定计划、软件开发方法论、只要你坚持下来，你就能得到承诺于你的一切。 “我们上一次尝试的系统因为其自身的先天缺陷被视为一个失败品，而这个新系统比上一个更好，这一次一定非常棒。”， Holy Grail 说。可能借助新系统事物的发展不至于太糟糕，但是对其抱有的期望高的有点不切实际了。没有人变得更开心，因为实际上并没有显著的提升。这到底是为什么？ 软件开发很复杂2012年，当我在Nordstorm创新实验室工作时，我第一次知道了Cynefin框架。它着眼于给定系统的复杂度，然后来决定什么样的方法可以用在这个系统上。它把系统拆成了四个类别，通常用四个象限表示：
你会注意到，越复杂难预测的系统随着时间的推移，创建的那些尝试预测这个系统的规则需要做的适应修改的地方越多。道理都是类似的。就拿股票市场这个复杂的系统来说吧，他的波动规律就经常性地打脸那些尝试预测他的上涨下跌周期的股票理论的脸，作何理论在他面前都变得无用，要在这种领域有所作为，不能一劳永逸，需要不断学习和适应。 问题是:软件开发在这个连续过程中处在什么位置?有人可能会说这只不过是个工程问题，所以这就像设计建造摩天大楼那样按部就班做即可。另一些开发软件的过程中受到挫折的人，可能会说这就像历史中记载的自然灾害那样完全不可预测。 有时这很复杂，有时这很混乱无序。大多数时候，这是复杂的。 处理复杂情况Cynefin告诉我们，没有一套最佳实践可以告诉我们如何在给定的复杂系统中采取行动。它也确实指出一些初始的启发式类的方法是有用的，而我们的重点应该是探索问题领域，并随着时间的推移调整我们的方法。 这听起来很熟悉，不是吗?每当开发团队为给定的项目采用一种新类型的功能时，不确定性就会上升。要知道一个给定的解决方案是否有效，唯一的方法是多探索一下。这就是正在开发的软件系统。还有五个复杂的系统在起作用:
上述系统中的任意一个都能轻易地导致一个排期紧密的开发项目出现问题：一堆意料之外的影响了正常业务的线上bug，开发团队成员突然的身体不适，业务方提出的关于发展方向上的改变。 这就是为什么要实施敏捷。敏捷帮助开发团队来应对前面提到的所有问题，同时建立一个随时间变化而适应当前形势的框架。敏捷向开发团队提供了一套使之变得最棒、最具有生产力的工具。 关于为什么要实施敏捷的实践接下来会讨论一些特定的“礼仪”以及它们存在的理由。我们需要摆脱“必须”和“应该”的思维模式，我们不这么做是因为它们是必要的，我们这么做是因为我们想从中得到一些我们想要的东西。如果我们没有办法再得到我们想要的，那么我们需要作出一些改变。
现在，那些敏捷教练说的诸如“在你接受采用敏捷的早期，你的估算会被停止”的言论是有道理的。这一切都是因为你处在一个逐步适应和提高的过程中。你的估算会更精确，困难阻碍会被解决，团队也会逐步减少历史遗留下来的技术债务问题。 反馈循环
敏捷可以创建一个引导你走向你的最终目标的反馈循环。每一步都是一个小的胜利，让你感觉良好，给你带来更多的胜利。它就像一个恒温器，只不过你暂时还不知道目标温度是多少。事实证明，反馈循环也是测试驱动开发（TTD）和精益创业背后的本质。 这里留给读者一个问题：如何调整你的软件开发反馈循环来使你的团队成为最棒的那个？在我的第二篇敏捷文章：可定制的敏捷中，我会为各位读者提供一些思路和想法。 |
