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

引言

计划驱动的项目通常以瀑布模型运行。这假设需求会预先完成。当一个项目是计划驱动的，并且对产品没有明确的愿景时，会发生什么？当截止日期临近而仍然没有需求时，会发生什么？

在项目发起人不知道所有需求的环境中，你如何取得成功？如果项目发起人，不信任开发团队按他们的理解来实施规则，你如何取得成功？

发起人说：“在你们开始之前，我想确切地知道我将得到什么。”

开发者说：“但是，你还不太清楚你想要什么。在你决定其余部分的时候，我可以给你你已经知道你想要的部分。”

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

什么能帮助我们？我们需要在计划的冲刺周期之前至少一个冲刺周期来获得需求。这给了团队充足的时间来检查它们是否完整。虽然听起来很明显，但必须指出，在开始实施这些功能之前，需求必须在某个时候是完整且正确的。

当新的需求改变了已经实现的需求时，这只需要在待办事项列表中与其他新需求一起进行优先排序。

待办事项列表中的每个项目都需要一个高级别估算（High Level Estimate - HLE）和一个客户或业务价值（Customer or Business Value - CBV）。待办事项列表中一项的优先级是 HLE 和 CBV 之间的判断。每个组织的 CBV 度量标准都不同，但它应该比凭感觉更科学——否则，由更有影响力的业务发起人提出的功能可能会优先于对客户更重要的功能。

虽然需求可以在开始实施之前随时有效地进入，但产品集从一开始就应该有一个清晰的愿景。开发团队不能简单地拒绝更改。也不需要严格的正式变更控制流程。当没有创建需求基线时，你如何确定什么是改变？一切都是改变，或者什么都不是！显然，这行不通。相反，应该努力推广一种折中策略。

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

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

应用敏捷

在每日站会中，所有团队成员都会总结他们工作状态的概况。这提高了对任何可能阻碍进展的瓶颈的可见性，但它也引发了对团队成员估算有效性的质疑。

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

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

敏捷开发确实给项目经理增加了一些工作量。她需要管理整体项目计划、前一个发布的成果以及下一个发布的工作进展。此外，她还需要确保在待办事项列表中的优先级达到最高时，需求已经准备好进行实施。为了做好这项工作，项目经理需要适应不确定性。她需要理解，在实施之前，我们可能对产品的某些部分一无所知。

在没有整个产品团队的支持下，采用敏捷项目管理风格是困难的。当一种激进的管理风格被强加给一个团队时，特别是对于那些固守陈规、对变革和模糊性感到不适的团队成员来说，将会产生阻力。此外，发起人和业务分析师在创建需求时需要理解这个过程。允许持续变化，但变化是有成本的，而且它必须像其他任何需求一样被优先排序。

缺少什么？

许多在整个组织中未能完全采纳敏捷方法的团队，常常缺乏其中一些

• 完整且可用的业务需求。这突出表明，提供给开发人员的需求状态不够完整。在将需求移交给开发团队进行实施之前，应该已经完成了对某个功能的需求。开发团队应该有权拒绝不完整的需求。
• 能够相互沟通，识别可能相互补充或矛盾的其他产品流的需求和功能的POs。
• 检查验收标准的开发测试。这些测试可以找出需求中的漏洞和矛盾的验收标准。
• 理解客户价值并能够根据该价值对需求进行优先排序的发起人。
• 理解高级别估算只是估算的发起人。开发者应该对他们的 HLE 负责，但发起人需要理解，这些估算基于不完整的信息、不完整的需求，并且没有进行详尽的工作分解。如果开发团队说一个功能需要大约两周，发起人就不应该立即想到：“太好了，我可以在 10 天内拿到！”
• 实际上是系统用户的 PO。
• 分配给每个功能的业务价值。
• 拥有对功能和需求做出决策的权力和权威的 PO。
• 迭代的发布计划，并能够进行多次快速发布。
• 具有未来发布和增量范围增加的产品路线图。
• 重视产出多于过程的项目经理。
• 开发团队提供准确、诚实的实际工作小时数。

经验教训

我学到了什么？

• 为所有需求变更分配风险、价值和优先级。
• 达成一致是关键。
• 资深团队成员应了解项目的方向。
• 不要接受不完整的需求。返工实际工作所需的时间远远长于返工需求所需的时间。
• 开发人员应在其 Scrum 更新中包含其实际工作小时数与估算工作小时数的对比。
• 先设计后测试不是敏捷。
• 敏捷架构——即时设计。遵循产品愿景。不要为没有的需求设计。不要做“万一”式架构。
• 设计一个易于更改的系统比设计一个能处理所有可能情况的系统更重要。
• 架构师决定何时设计或实现足够好，可以满足当前的需求。
• 一旦做出决定，团队中的所有成员都应该接受，无论他们是否同意该决定。
• 团队成员对领导者决定的分歧应在冲刺回顾会议中提出。

摘要

运行敏捷项目需要一位有能力的领导者，他能够快速做出最终决定。领导团队必须拥抱失败。其中一些决定可能被证明是错误的，但敏捷方法允许比瀑布环境中更容易纠正这些决定。每一次错误的决定都应该被视为一个学习机会，并在回顾会议中进行讨论。项目领导者必须能够应对模糊性和变化，并必须不断推动项目前进。项目领导者必须对产品及其未来及其方向有清晰的愿景，并能够将这种愿景和方向传达给团队。没有这种强大的领导力，团队中的任何人都无法相信他们能够交付遵循愿景的产品。简而言之，如果人们不知道他们是否在做正确的事情，就很难衡量他们是否在做正确的事情。