敏捷项目管理：在计划驱动环境中的挑战与应对

在敏捷项目管理中，当项目进度成为主要驱动力，而产品愿景不明确时，会出现一系列问题。例如，当截止日期临近，但需求仍不明确，项目如何成功？在项目发起人对需求了解不全面的情况下，如何实现项目成功？如果项目发起人不信任开发团队按照他们自己的理解来实施规则，又该如何是好？

“想在开始之前确切知道将得到什么。”发起人如是说。但开发者回应道：“还不太确定想要什么。可以在决定其他部分的同时，给那些已经知道想要的东西。”

尝试在计划驱动的组织中实现敏捷

为了应对这种不确定性，需要在至少一个冲刺周期之前就明确需求。这为团队提供了足够的时间来审查需求的完整性。虽然这听起来显而易见，但必须指出，在开始实现这些特性之前，需求必须在某个时刻是完整和正确的。

当新的需求改变了已经实现的需求时，这需要与其他新需求一起在待办事项列表中进行优先级排序。待办事项列表中的每个项目都需要一个高级估算和客户或商业价值。项目在待办事项列表中的优先级是高级估算和商业价值之间的判断。

每个组织的商业价值衡量标准都不同，但它应该比凭直觉更科学——否则，由更有影响力的业务发起人提出的功能可能会优先于对客户更重要的功能。

产品愿景与需求管理

虽然需求可以在开始实施之前有效地随时提出，但从一开始就应该有一个清晰的产品愿景。开发团队不能简单地拒绝变化。一个正式的变更控制过程并不是绝对必要的。如果没有创建基线需求，如何确定什么是变化？一切都是变化，或者什么都不是！显然，这行不通。相反，应该努力促进一种中间策略。

一个“变更控制”级别的需求变化与新需求或增强没有太大区别。它需要被优先排序和估算，然后在待办事项列表中进行管理，以便在发起人认为合适的时候重新优先排序。它就像待办事项列表中的其他任何项目一样，需要时间来实现。这意味着发起人，即待办事项列表的所有者，需要真正分析重新优先排序某个功能是否真的等同于让客户更满意。

交付日期与项目范围

当交付日期是产品开发周期中最重要的因素时，需要适当调整范围，以确保在到期日交付有价值的东西。理想情况下，到期日是由包含在发布范围中的特性的估算驱动的，但有时，而不是范围决定日期，到期日决定范围。这使得发起人的工作更加困难，因为高级估算在需求仍在形成时就有一定的不准确性，当出现挫折时，需要仔细管理待办事项列表，以便团队能够交付有价值的产品。

敏捷项目的工具与策略

在每日站立会议上，所有团队成员都会总结他们工作的状态。这为可能阻碍进展的任何阻碍提供了更大的可见性，但它也质疑团队成员的估算的有效性。

最初，团队成员可能会对他们的估算和实际工作受到质疑感到不满，但这确实鼓励了在估算和跟踪其他任务的工作方面更准确的准确性。除了标准的Scrum问题（昨天做了什么，今天将做什么，有什么阻碍了），在每个关于bug或开发任务的报告中，如果有估算，加上实际工作小时数与估算的对比。

项目成本与估算

总体成本是项目批准的重要因素。高级估算被纳入成本估算，但由于每个发布都是基于价值的，因此基于范围的成本估算应该是可以接受的。这意味着，虽然整体项目愿景将决定产品的范围和方向，但实际的项目本身将会小得多。整个项目不是“项目”。一个项目由实施功能和变化（以及修复缺陷！）的工作和计划组成，这将提高产品发布的价值。当项目是迭代的，而不是单一的，团队更容易跟踪进度并应对变化。

敏捷开发对项目经理的影响

敏捷开发确实给项目经理增加了一些工作。她必须管理整体项目计划、前一个发布的结果以及向下一个发布进展。此外，她需要确保需求在它们的待办事项列表优先级达到顶部时准备好实施。

为了很好地执行这项任务，项目经理需要对不确定性感到舒适。她需要理解，在实施之前，可能对产品的某些部分一无所知。

敏捷项目管理的采纳

如果没有整个产品团队的支持，采用敏捷项目管理风格是很困难的。当对团队强加管理风格的激进转变时，尤其是对于习惯于自己的方式并且对变化和模糊性感到不舒服的团队成员，将会有阻力。此外，发起人和业务分析师需要在创建他们的需求时理解这个过程。允许不断变化，但变化有成本，它必须像其他任何需求一样被优先排序。

缺失的要素

许多在整个组织中不完全采用敏捷方法论的团队通常缺乏以下一些要素：

• 完整且可用的业务需求。这强调了提供给开发人员的需求的状态不够完整。
• 相互沟通的产品负责人，以识别可能补充或与其他流相矛盾的需求和功能。
• 开发测试，以行使接受标准。这些识别了需求中的漏洞和矛盾的接受标准。
• 了解客户价值并能够根据该价值优先排序需求的发起人。
• 了解高级估算是估算的发起人。开发人员应该对他们的高级估算负责，但发起人需要理解这些估算是基于不完整信息、不完整需求，并且没有彻底的工作分解。
• 如果开发团队说一个功能大约需要两周，发起人不应该立即想到，“太好了，可以在10天后拥有它！”
• 实际上是系统消费者的产品负责人。
• 分配给每个功能的业务价值。
• 拥有对功能和需求做出决策的权力和权威的产品负责人。
• 具有未来发布和增量范围增加的迭代发布计划。
• 重视输出而不是过程的项目经理。
• 开发团队的准确、诚实的实际工作小时。

教训

从中学到了什么？

• 为所有需求变更分配风险、价值和优先级。
• 一致性是关键。
• 高级团队成员应该理解程序的方向。
• 不要接受不完整的需求。重新工作实际工作所需的时间远远超过重新工作需求所需的时间。
• 开发人员应该在他们的Scrum更新中包含他们实际工作小时数与估算小时数的对比。
• 先设计再测试不是敏捷的。
• 敏捷架构——及时设计。遵循产品的愿景。不要为没有的需求设计。不要做“如果？”架构。
• 设计一个易于变化的系统比设计一个能够处理每一种可能情况的系统要重要得多。
• 架构师决定一个设计或实现是否足够好以满足当前需求。
• 一旦做出决定，团队的每个成员都应该接受，不管他们是否同意这个决定。
• 团队成员对领导决定的分歧应该在冲刺回顾中提出。