Scrum敏捷项目管理

在敏捷中使用预算而不是估算

基于预算的项目管理是在敏捷社区中有一些关注者的经典估计的替代方法。在他们的书中“五十个改善用户故事的快速构想”Gojko Adzic和David Evans讨论了使用预算而不是预算如何帮助交付更好的项目。

详细估算与灵活范围的整个想法背道而驰,但是与我们合作的许多公司在坚持工作时间估算时陷入了一个共同的陷阱。 “我们对不确定性感到恐惧–我们宁可错又要不确定”,奥雷德夫(Oredev)的丹·诺思(Dan North)在2011年说。该过程的前提存在严重缺陷,因为所有估计都带有很少考虑的误差范围。有几种流行的减少错误的技术,例如以置信区间进行估计和基于统计平均值进行估计,但是在许多情况下,这实际上并不是解决的正确问题。

长期估计会给人错误的准确性印象,并会导致他们对范围的长期承诺,从而消除了企业从敏捷交付中获得的最大利益-自适应计划。

与其估算,不如从运营成本和时间方面着手进行更大的工作预算。然后,类似于可伸缩性或性能,此预算可能成为交付团队的设计约束。本质上,不是问“需要多长时间?”,而是问“您什么时候需要它?”和“您可以负担得起多少费用?”,然后,交付团队需要提出一个适合的解决方案。这些约束。当然,这需要交付软件的人与购买软件的人们之间的透明性和信任,因此,内部软件比第三方交付要容易得多。

设置预算而不是估算,因此无需累加更小的估算,因为最终数目是已知的。反过来,这消除了将较大的里程碑分解为许多小故事并预先进行分析的需要。这样可以避免在不必要的分析上浪费时间,避免在范围上做出承诺,而是建立了交付业务价值的承诺。

另一个重要的好处是,这种方法设置了附加的设计约束,这使交付团队可以提出适合业务案例的解决方案。预算清楚地表明了是否必须即兴创作或应该镀金。

资源: “五十个改善用户故事的快速构想”,Gojko Adzic和David Evans(精益出版)

在敏捷中使用预算而不是估算

在项目开始时提出的主要问题通常是”多少钱?”通常人们开始估算工作量,然后将结果转化为预算。有些人主张相反。如果我可以为这个项目花费X美元来改善我的供应链,结果将是什么。上面列出了采用这种方法的大多数优点。对我来说,采用预算优先的方法的主要好处是,它应该迫使人们优先考虑所有功能,并对要花费的每笔钱采用基于价值的选择过程。这自然要求高度信任,因为利益相关者认识到他们无法在项目开始之前定义项目的确切范围,并接受每个参与者将尽最大努力在初始预算的约束下产生更高价值的解决方案。

关于价值和预算的一些讨论随着“Beyond Budgeting”Statoil开发的方法。这种方法试图超越命令和控制,而朝着更加授权和自适应的管理模型发展。它基于重新定义管理模型的12条原则。

有关敏捷项目管理和预算的更多参考

您的敏捷项目需要预算,而不是预算

#NoEstimates–估计驱动软件开发的替代方法

超越预算 Institute

超越预算: An interview with Bjarte Bogsnes

您无法计划复杂的项目,因此可以控制它们