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