敏捷实践指南：建立敏捷思维模型

我相信你一定听过“敏捷不行”的声音，运行敏捷而失败的项目也确实非常多，但它也一直都在流行。

这里的问题，其实根本就是原因就是：你的项目环境不适合敏捷，或者你的项目根本不需要敏捷，尽管它也是软件开发项目。

敏捷是基于“不确定性”而诞生的，它想要解决的是，如何在不确定性环境交付最可靠的商业价值。敏捷方法是为了在短时间内探讨可行性，根据评估和反馈实现快速调整，它与传统的基于确定性工作的瀑布模型就有着完全不同的实践思路。

简单来说，适应敏捷的项目，有4个显著的特征：

• 需求研究和开发

• 变更速度极快

• 具有不明确或未知的需求、不确定性或风险

• 最终目标难以描述

这些项目在项目需求，以及如何使用现有知识、技术满足需求的层面上，所具有的不确定性导致项目及其服务，往往带来大量的变更，返工、延期的风险非常高。在传统项目实践中，项目经理都必须针对变更列出单独的流程来进行控制，涉及到组织、采购、沟通等多维度的复杂管理，还经常因为不同利益相关的隐形需求而导致项目失控。

无用功、延期、返工深深的折磨着整个团队。在实践过程中，为了解决这些问题，项目团队就必须寻找可以减少浪费和返工的方法，这些方法包括：

• 频繁交付

• 频繁调整过程

• 非常短的反馈循环
  

• 重新进行优先级排序

• 定期更新计划

这种逻辑模式，就是敏捷管理的思想体现。敏捷的策略是构建小的增量，然后对其测试和评估，在短时间内以低成本探索不确定性，更准确的理解客户需求，降低风险，最大程度的实现商业价值的交付。

当然，我们也需要意识到，迭代和增量方法仍然有局限性，为了项目尽可能可靠，需求尽可能的遏制其中某一个不确定性变量（适应性和需求、技术可行性和性能、过程和人员）。

你可能已经意识到了，只有一部分项目适合于敏捷，有些项目更适合用传统瀑布流的方式进行交付。

项目管理的目标是在给定的当前环境下尽可能以最好的方式创造商业价值。项目采用敏捷方法抑或是传统的瀑布流方法都无关紧要，要提出的问题是“我们怎样做才能最成功？”

当团队创造价值，是否需要反馈？在探索新的想法，新的商业模式，是否需要管理风险？如果需要，那敏捷将会有所帮助。而有些项目，天然无法交付中间价值，那么就不要去尝试敏捷。