适用敏捷的项目、团队

一些研究数据表明，不是所有敏捷开发项目都能取得成功，也并非所有瀑布模式的项目一定会失败。理智的软件开发团队应在对产品、项目和团队特性分析的基础上，选取更合适的开发模式。

任何项目都会受到三类条件的约束：

• 范围：即项目的目标、任务以及相关方的期望是什么；
• 时间：即规定项目需要在多长时间内完成；
• 资源：包括项目的经济成本和人力资源。

项目管理就是在三者之间寻找一个相对平衡的点，以便让项目尽可能实现预期的进展和结果。在判断采取哪种开发模式时，我们可以自问：是用更长的时间，甚至冒着延迟的风险，交付一个足够好的产品？还是尽早推出一个可用的产品，通过市场反馈和高频迭代让它持续变好？

瀑布模式的逻辑是将项目范围，也就是客户提出的产品需求作为固定条件，基于此预估软件开发项目所需要的时间和资源，形成项目计划。假如某开发团队在日程表走过一半的时候，发现几乎无法在计划的发布日期前完成剩下的工作内容，要么他们不得不将发布日期推迟，要么向项目增派更多人力 —— 显然这样将会增加项目成本，还不一定确保项目能按新调整的计划完成。为了避免这种窘境，采用瀑布模式的软件开发项目往往没具备以下特征：

• 在开发启动前，项目的所有需求都非常明确、清晰，不会在开发过程中变更，并以此作为里程碑或最终交付的验收标准；
• 开发团队做过类似的产品，对于需求足够熟悉和有把握。

对敏捷开发而言，“大而全”的产品被拆分成若干个小迭代，如果将每次迭代看作一个项目，那么项目范围中最为关键的是以交付一个可面向市场的、可工作的产品作为目标基调，先将迭代周期长度或产品发布的时间节点（时间条件）、开发团队产能（资源条件）确定下来，再反过来考虑在这些条件下，按最需要实现的需求或功能的优先级排序，尽力能将产品做到什么程度。相比瀑布模式，敏捷开发更适合这样的项目：

• 对于开发团队来说是一个新的挑战；
• 产品需求复杂或不确定；
• 相关方对上市时间的要求大于对产品完善程度的要求。

那么，敏捷开发适合什么样的团队呢？如何确定敏捷是否适合你的团队？

在心态层面，尽管敏捷原则性的内容易于理解，但由于缺少特别标准、普适的实践方法，刚开始接受敏捷的团队需要有足够的勇气和耐心试错、磨合，从实践中总结经验以适应敏捷的开发风格。在技能层面，敏捷团队希望它的成员都是多面手，这样在开发过程中的任何时刻，每个人都可在不同的任务上以不同角色贡献自己的力量，从而确保团队能够高效释放产能，在有限的迭代周期内完成更多任务。在协作层面，敏捷团队推崇开放和相互信任的关系，乐于保持高频、双向、充分的沟通互动，让产品用户及其他相关方参与完整的开发旅程。

除了团队本身以外，当我们谈论敏捷时，也需要关注敏捷开发团队所在的组织能否为他们的敏捷实践提供一个有力的支持环境，这就需要组织高层对于敏捷价值观有高度认同、对于敏捷基本理念和概念有正确理解，并给予敏捷开发团队足够的信任、自主权和精进空间。