产品所有者喜欢敏捷的灵活性和较短的交付时间。与此同时，管理层可能很难采用这种方法。如果对最终产品没有决定性的理解，就很难估计总成本和控制范围。你可以在sprint中将工作标记为已完成，但功能本身并没有完成，直到整个体验被业务接受。然后迭代会变成范围渐变，作为“特性”而不是进程，并增加项目成本。
因此，我看到一些项目将瀑布定价作为一种防御策略。但问题是，《瀑布》的缺点并没有消失。如果开始时只有几个或仍在开发需求，您该怎么办?还是几乎不可避免的范围蔓延?缓解这些常见缺陷的一个解决方案是在混合方法中利用敏捷实践。
敏捷方法
对于时间较短的项目，我通常使用看板方法。如果你在一开始没有足够的需求来完成整个sprint，我特别推荐看板。然后，一旦团队开始巩固对多个特性的需求，就要考虑切换到Scrum是否合理。在这两种情况下，与涉众一起将长瀑布式项目计划划分为关键里程碑或易于理解的可交付成果的冲刺阶段。工作应该在整个项目中相当均匀地分配，提前根据团队能力进行调整。虽然团队的效率会随着时间的推移而提高，但您会希望在项目时间线中为额外的特性迭代留下空间。产品负责人和关键涉众需要定期参与团队的工作以推动团队的进步。
项目前期工作
在此过程中，您的成功或失败通常取决于管理和项目干系人在项目前期计划阶段对过程的接受。从下面端到端详细介绍流程开始，并解释为什么它很重要。最终目标应该是达成一个有效的协议。同时，考虑邀请合适的董事和其他领导作为与会者，以增加股东的参与可能性。
- 确定项目计划中具有最大影响和优先级的特性，然后按提升工作进行排序。
- 目标:尽快展示价值并制定工作协议。
- 整合跨范围的单个特性。获得产品负责人和关键涉众的批准。
- 目标:效率和潜在的缩小范围。规范外观、感觉和行为。
- 开发团队评估每个交付周期的能力。
- 目标:确保可用的工作团队与交付期目标一致。
- 小贴士:考虑休假和其他承诺。计划回填人员。
- 业务分析人员和技术主管根据关键特性里程碑估计小时间周期，以覆盖项目的整个范围。
- 目标:创建检查点，以确保项目处于正轨，并将按照预期交付最终结果。
- 提示:记住，交付团队的效率应该随着项目的继续而提高。如果你下一段时间的工作量看起来很轻，那就在时间轴上把工作向前推。
项目开始
当项目开始时，您的步骤将以如下无缝流程继续执行:
- 激光聚焦固化对功能的要求。
- 目标:防止返工，确保团队在工作会议中有共同的理解。
- 提示:让参加会议的人尽量少——产品负责人、关键涉众、业务分析人员、技术领导和(可选的)开发人员，他们将负责这个特性。每次会议你参与的人越少，你的参与度就越高。提前工作到未来的时间段。一个固定的经验法则是，从现在到发布的最终需求变化小于10%。
- 对于sprint 0 / 1，分配一个或多个功能到比通常更小的时间段。
- 目标:保持业务参与，显示即时结果，并展示敏捷方式的好处。
- 提示:技术主管可以在团队其他成员参与项目设置工作时完成这项工作。使用这些快速特性作为示例，说明流程如何向前运行并建立信任。这将帮助您从产品所有者和涉众那里获得持续参加需求工作会议和演示的承诺。
- 业务分析师将特性需求复制到票据跟踪系统。
- 目标:需求位于单个位置，并且是最新的。
- 提示:包括用例、错误状态、验证、消息传递和其他常见注意事项。决定谁负责将会议或电子邮件的动作项复制到票据上。为了澄清或其他机票更改，您应该在评论中包括谁指导了更改和日期。
- 开发人员与业务分析人员一起工作，将其分解成子任务并使用该特性。
- 目标:允许开发人员与单独的可交付部分并行工作。
- 提示:通过构建组件化工作和特性切换，将交付与发布解耦。在演示中突出显示交付团队完成的所有工作，即使这些工作在视觉上无法演示。
- 与关键涉众一起安排“早期观察”功能演示，甚至在QA之前。
- 目标:确保团队朝着正确的方向前进在QA测试之前确定需求．
- 小贴士:保持简短和集中。相当多的人是视觉思考者，他们必须在确定需求之前了解特性在实践中是如何工作的。在此步骤中，您经常会发现更多的用例和错误状态!向涉众强调，这应该是该迭代需求的最终锁定。另一个好处是，开发人员将努力确保他们的工作已经为演示做好了准备，即使业务分析人员或技术主管是演示人员。
拟合在一起
每个步骤都有自己的好处，但是查看整个时间表会有所帮助。下面是一个示例时间轴，说明在项目中期该计划可能看起来如何。
正如您所看到的，时间周期容量和随后的速度通常会随着项目的进展而上升，包括休假和假期。当团队努力最小化需求中的缺陷和变更时，他们在项目的后期会有机会将工作向前推进，或者在另一个迭代中工作。这超出了最初的计划工作，但仍然符合相同的时间和预算!在第二部分中，我将介绍业务流程的交付方面和一些最后的想法。请继续关注!
