Scrum 如何与受制于固定的价格和完工时间的项目相结合？Tim van Baarsen讲述了他的经历。通过在幕后持续地使用 Scrum 方法开展工作，他完成了一项凡事固定的投标。
在由最初的需求生成 Backlog 之后，Tim 的团队就开始在定期的冲刺中进行迭代发布。尽管有宏观层面的时间限制和规范，但通过故事点和燃尽图的可视化，他们能够提供可预见性和适用性。项目最终按时并且在预算范围内交付。
对于完全受约束的项目，如何调整其范围？为了帮助理解这个问题，Tim 写道“即使在‘凡事固定的项目’里，我们都知道，需求会适时地变更，需求总是会变更。”
他继续写道，
“需求变更真的不适合敏捷方法，不过，我们希望保持灵活性，因此，我们更喜欢交换需求。”
Tim 将“交换需求”描述为一种处理变更的机制。根据理解，如果用户认为有些故事是多余的或者重要性差一些，那么可以用新的需求替换它们，只要新旧需求所需工作量相同就可以。通过这些“交换需求”，可以保持总的工作量不变，从而降低了变更的风险。
在今年的早些时候，Peter Vaihansky论述了这样一个问题，大型项目是否可以完全受约束。他在引用了 Mckinsey 和牛津大学 BT Centre for Major Programme Management 的调查结果后指出，成功的凡事固定的项目是个神话。该调查涉及“超过 5400 个 IT 项目”，发现软件项目（尤其是大型项目）平均有 66% 超出预算以及 33% 超出时间表。
Peter 的文章指出，在大部分凡事固定的项目中，失败常常是因为缺少反馈循环。他写道，可以通过用固定预算取代固定价格来解决这一问题。这样，“虽然财政支出有上限，最后期限不可变，但基于项目实际的进展情况这一现实，项目团队可以改变范围和变更需求。”
敏捷项目的成功总是可以归结到人们的参与。项目刚一开始，Tim 就创建了跨职能的“老虎队”。他也意识到需要一位传统的产品经理，这样可以对完整的规范实现人性化的单“点负责制”管理；产品经理能够理解用户需求，并代表他们进行决策。
通过产品经理和交换需求过程，团队展示了一种响应变更而又不会超出时间表的方法。通过允许产品经理调整范围，可以在固定的时间表内交付一个最小可行产品。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论