我为什么要了解敏捷？

我遇到的难题

不知道大家在工作中是否尝试过客户在项目最终交付的时候一直要求改改改？

是否在临近节点的时候，发觉团队遇到了各种各样的障碍并导致交付工作一直拖拖拖？

如果大家遇到过，那么一定也和我一样遭遇了不少考验。

这是个充满不确定性的世界，而我们如果要能稳定的给客户带来价值，那么必须用我们的工作方法的变革来应对不确定性，并把影响减到最小。

这是我的诉求，相信你也会有类似的感受吧，要是有一种方法让客户也能获得好处，我们也获得好处就好了。

现有方法出了什么问题？

我们原来是用的传统瀑布法来做项目的，要知道，完全可以使用预测型周期的项目，少的可怜，要么是特别小的一两个文档就能聊清楚，要么就是客户已经完全的搞清楚了自己要什么，甚至连原型都用excel认真的画好了（这是真事，真的有用excel画原型的客户）。

但是，在软件定制行业，大部分的客户，还是不知道自己要什么的，他们所拥有的，只是一个诉求，或者说“问题”。

客户：“我有一个问题，需要通过软件来解决，所以，你帮我做个能用的软件吧！”

然而瀑布法，普遍的问题是，原型确认的时候，客户心想“好像能用吧”然后确认签字，但是等到交付的时候才发现，“好像这里不对，好像那里不对”，于是就产生了返工的问题。而返工，一般是代价高昂的，一来徒增开发成本，二来项目节点延误，消耗了甲乙双方不少的时间。

下图是不确定性和复杂性模型示意图，可以看到，传统瀑布式的方法，仅在需求和技术的不确定性都很低的时候才能起到不错的效果。

我需要什么？

所以，如果有那么一个能够让客户不断的确认功能是否适用，不断得到有用的部分，最终解决所有原始问题的方法。那么我们既能在成本内解决问题，客户也能得到所需要的价值，那就皆大欢喜了。

而敏捷方法正好就是这样一个方法。敏捷方法旨在短时间内探讨可行性，并根据评估和反馈快速调整。简单来说，就是不断的小规模试错，让客户能不断反馈我们所努力的方向是否有作用，从而避免大量的返工损失。

我们可以看下敏捷生命周期和预测型生命周期的区别。

如果能不断的交付核心需求，那么项目甚至可能（因为已经满足了客户大部分需求而）提前结束。而这也正是我们追求的最理想的目标。

那么敏捷真的能做到这些看似不可能的事情吗？我们以后再聊。