和大多数项目经理（以及组织）一样，你或许正难以选出最优交付方法。我们多数人都意识到，传统方法无法确保成功交付，因此始终在寻找更优方法。
近年来，敏捷或迭代开发技术被视为一项重大改进，收了大量非常积极的评价，能够提升项目交付成功率。因此，和当今大多数组织一样，你的组织可能想了解应在哪些场景以及以何种方式合理运用这些敏捷或迭代开发技术来同时提升项目交付的时效性与成功率。
简而言之，迭代开发技术以小模块（或称迭代）的形式规划、开发并实现项目功能。成功迭代交付的关键在于，每个小区块在总项目下有效地作为较小的微型项目运行。因此，每次小型项目迭代都可以更好地规划交付两周迭代所需的工作量，而非制定为期两年的计划。此外，由于以两周为增量进行规划，因此可以轻松调整后续两周的计划，以纳入所确定的任何更改。
我想稍作停顿以介绍一个非技术情况：与传统计划相比，使用敏捷方法取得了更好的效果。
我们来用一个规划全天活动的例子 - 这就是一个项目。和大型项目一样，这件事充满不确定性与风险：我们不知道午餐后会发生什么事情可能影响计划。但传统思路要求制定一份全面的计划，以安排全天从早上 6 点起床到晚上 11 点就寝每个小时要完成的事项。
上午 9 点时，由于交通影响，我们无法按计划上班；上午 10 点，我们被临时召去参加紧急会议；到中午时，唯一完成的每日任务只有抵达办公室，并且即时这项任务也晚于计划时间。
现在，我们将此视为敏捷项目，即所有计划仅针对下一轮迭代：做好出门准备（因此对应的故事为：洗漱、吃早餐、送孩子上学）。上述全部事项均按时、按预算顺利完成。
于是，我们自信地规划下一轮迭代，即前往办公室（开车到公交场站，搭乘通勤列车到站，然后换乘城市公交车抵达办公室）。
此计划执行效果不佳：第一个故事（开车前往公交场站）遇到交通拥堵，于是我们将用户故事修改为开车去办公室，并同意可以从迭代计划中移除另外两条故事。到达后，我们将规划下一次迭代。但在规划周期内，新增了一个用户故事（紧急会议），该任务将占用这个下一轮迭代。
最后，情况在午餐后平稳下来，我们能够查看积压工作，并着手处理最高优先级任务；下午我们成功完成两轮迭代来处理最高优先级事项。
如果坚持传统计划，我们绝不会完成这些最高优先级工作，因为到达办公室的交通遇阻导致计划延期，这些工作将会重新安排到第二天。
这种可以适应不断变化的业务需求的灵活性正是敏捷或迭代方法的优势所在，也是许多组织采用该方法的原因。但是，你的组织是否确实已准备好“全面推行”敏捷模式？ 根据我的经验，全面采用敏捷方法往往存在许多阻碍，最典型的就是已经固化的组织策略，因为它们通常无法完全兼容敏捷方法。
项目获批前需要固定预算、收益实现说明与目标日期等策略虽然重要，但并非真正的敏捷模式。同样，为了确保不影响现有运营而需要遵循的组织实施策略至关重要（但绝对不是敏捷方法）。
因此，许多组织都面临在适应迭代方法的同时，如何保留部分关键“传统流程”的抉择。答案就是混合交付模型。项目部分工作可采用传统管理方法交付，其余部分则采用迭代方式。
我接触过的最常见混合模型支持传统的项目启动或规划，然后执行一系列迭代，其中穿插用于发布的传统实现活动，之后再继续执行另一系列的迭代和传统实现。
在此模型中，我开发了基于传统可交付结果的工作分解结构 (WBS)，以确定组织在项目审批时需要的核心可交付成果，例如项目章程、项目管理计划和项目预算。
这些前期可交付成果可通过传统方法进行开发与管理，以向管理层证明该项目可行，且值得投入资源。
项目获批后，即可进入迭代方法来维护积压故事，然后再下一次迭代中选择并充分开发优先级最高的故事。项目视图将从传统甘特图视觉对象更改为交互式拖放看板，从而将故事动态分配到迭代。
产品负责人能够随时（通常每日）添加、删除和更改积压中的故事，以响应不断变化的业务需求。
每次迭代结束时，我们将会暂停并对成败进行追溯性评估，然后进行更改以实施所需改进。接下来，也是最重要的，我们审核产品积压，并选择最重要的故事作为下次迭代的候选项。此方法可确保项目始终处理最恰当、价值最高的工作。
在每次迭代中，团队可运用敏捷原则（如每日站会），以及研讨当前迭代计划内故事状态。借助此方法，团队可以完全掌控迭代内完成的工作，同时仍可保证整体项目保持最新状态，并可用于针对资源容量、项目组合及计划状态生成企业报表。
敏捷原则的关键在于能够以小版本形式实施最终解决方案。此方法的优势在于能够使用初步功能来尽快实现部分预期业务优势。
此外，它具有提前验证解决方案的优点，因此可以轻松地将任何调整纳入到产品积压工作的剩余故事中。因此，只要在迭代中完成了足够的高优先级故事，项目就会移回传统周期，并执行组织所需的标准实施任务。
这些发布和实现活动将使用传统方法进行规划和控制，并确保遵循所定义的流程，以在实施新项目时减轻对现有运营的任何影响。
第一个版本完成后，项目将返回到敏捷方法，并开始执行另一系列迭代以继续开发剩余故事。
尽管这种融合敏捷与传统方法的“分阶段”方法最为常见，但你还可组合使用多种方法来支持特定的项目交付需求。例如，我曾管理一个在监管极为严苛的行业中实现新产品的项目，该项目对合规性和验证具有极高的要求。因此，该项目的大部分工作都是使用传统方法进行规划和控制的。
但是，项目包含一个商业智能模块，我所在公司需要挖掘系统产生的海量性能数据；这部分工作非常适合采用敏捷方法。对于与传统工作并行运行的项目 BI 部分，我们将选择最高优先级故事(可在为期三周的冲刺内完成)并完成迭代。
由于许多此类故事都带有探索性质，因此我们会经常创建新故事，以开展进一步探索或用于创建特定性能报表。这些内容将会添加到积压工作中，以供下一个冲刺考虑。
依托此方法，可以指定单个项目计划，以确保我完成所有必需的报告和监管步骤，同时仍支持使用极度灵活的方法来开发项目的非监管业务报告组件。
在单个计划中安排所有工作，可以统一查看此项目中发生的全部事件：
敏捷是一种功能极其强大的项目交付方法，它应为组织的整体项目交付工具包带来显著收益。敏捷可独立使用，可作为分阶段交付方法的组成部分，也可融入混合交付结构。
关键在于采用敏捷原则来帮助组织实现成功交付，同时遵循到目前为止已帮助组织取得成功的传统流程。
Steve Caseley 拥有超过 35 年的 Microsoft Project 使用经验，并且自首次发布起一直在使用 Microsoft Project。他担任多部 Microsoft Project 与项目管理最佳做法相关著作的编辑。他是 Sensei Project Solutions 的首席顾问，曾使用 Microsoft Project 项目组合管理 (PPM) 工具集帮助大型组织实现出色的项目交付。
业务见解和理念无法作为专业的税务或财务建议。请联系你自己的税务或财务专家来讨论你的情况。
关注 Microsoft 365