如何为敏捷团队计算预算
我从敏捷新手获得了一个共同的问题是：
“如果我不做所有的前线规划，我如何计算我的敏捷项目的成本？“
实际上，事实证明，当我利用Agile00方法来简化我的项目会计时，预算率变得更加容易。我将向您展示两种方法，从而利用两个强大的属性敏捷帮助敏捷团队计算预算。
敏捷项目的强大属性
稳定的团队名单
世界各地的项目经理同意任何项目的主要风险都让您的人们猛拉在团队中，或者在最后一分钟只扔到一个团队上的新人。这是“资源调平”的邪恶版本，它可以防止任何可靠的项目烧伤率预测。所以，让我们看看我们请求，Nay需求，稳定的团队名单时会发生什么。
定时迭代
而不是尝试计算预算敏捷团队在这12个月里，我想简化我的问题。如果我们的迭代周期是1个月，我只需要计算给定迭代的预算。下面让我们看看它是如何工作的。
计算敏捷团队预算的方法
使用混合率
当我在华盛顿特区以外的国际总部举办的国际总部工作时，项目经理没有能力的可见性。相反，我们使用了125美元/小时的共同“混合率”。人力资源估计组织的总加载成本下降到一个数字。让我们假设我有一个12人的团队名单，但其中4人是半次，总共有10个全职等同物（FTES）。
每天每天每天收费=每天125 x 8美元，每天$ 1,000固定烧伤率。
我的团队上的1,000 x 10辆十字架=每天= $ 10,000固定烧伤率。
=> $10,000 X 10个2周迭代的收费天数=10万美元的固定迭代消耗率。
使用特定的劳工类别
在其他组织中，项目经理必须根据具体类别利用劳动力成本。为此，我们无法通过混合率过度简化问题。
=每年成员的年加载成本/一年中的理论迭代数量=该团队成员的迭代的固定烧伤率
=> Sum(每个团队成员每次迭代的特定固定消耗率)=固定迭代消耗率
在下面的例子中，我运行这些计算得出每个迭代19,350美元的固定消耗率。
样本团队成本
所以呢？
具有固定，可靠的迭代烧伤率是杀手。一旦我拥有预算指标，我终于有一些引人注目的谈话积分常见的谈话：
- “先生。客户，我们的敏捷发布计划会议说，“社交媒体”计划将需要5次迭代，总计25万美元。预期的收益值吗?”
- “是的，副总统女士，我们可以添加紧急功能。然而，该团队表示，这将需要另外2个10万美元的迭代。你能批准增加预算吗?”
- “团队，我们必须对错误无情。在额外的迭代中，任何阻止我们才能获得的错误将花费50,000美元，我不希望从我的年度奖金中出现。“
或者使用度量标准来反驳常见的项目错误:
- “当然，您可以从我的项目中拍摄高级测试仪。但这将导致我目前的迭代以$ 50k的费用。此外，团队认为它将增加30％的风险，其中缺少剩下的200万美元的工作截止日期。将财务影响为50k +（30％x $ 200k）= 110千万美元。你还准备吃那些成本吗？
- “我知道我们正在落后，但如果我们延长迭代，直到我们觉得我们已经完成，我无法预测财务影响。但是，如果我们只是通过一个额外的迭代将项目扩展，我可以告诉您它会花费50k。“
那你呢？您是否发现敏捷项目更容易或更难以预算？
评论（23）
马克茎
你好
好帖子。自2010年以来，我一直在使用这种敏捷项目的方法，它的工作真的很好。
然而，即使它如此简单，一些人仍然不理解这种方法。
谢谢
Joe Astolfi.
嗨,杰西,
关于敏捷预算的很好的、直接的解释。这与我用来评估敏捷计划的方法相同。关键的考虑因素之一是，团队成员必须专注于一个团队，或者尽可能专注于一个团队。谬论仍然存在，认为将人们的时间分配到多个项目中是件好事。我们还没有意识到在上下文切换过程中产生的浪费量。
我所做的与您的例子不同的一件事是估计一个组织的员工的分配少于100%。这包括培训、休假、组织会议和其他不计入项目预算的活动。除非我从组织中获得了更好的信息，否则我通常会选择80%作为指导原则。
感谢以清晰简洁的方式发布这一点。
乔
马克，谢谢你的评论。很多人不理解的原因，是因为我们没有接受过这样的训练。继续取得成功，并耐心地对待那些怀疑你为何如此成功的人:)
乔，关于20％的非收费时间分配的好点。我的例子是指将这些成本纳入混合率或加载成本的组织。您的解释将计算扩展到另一个模型。非常感谢您的评论。
艾伦最终
我喜欢帖子;极好地放了杰西。在像我们这样的大型国民中，我们使用每个国家的混合率，而不是世界上最容易揭示的信息，而是可以使用。我一直在建议Scrum Masters和PMS，以至于他们至少需要了解故事点的成本，并且从非常相似的计算中获得了这一点。这样，当产品所有者考虑特定故事的业务价值，或者另一个版本的价值，他们可以理解真正的成本。亚博vip9通道
艾伦，谢谢你的善意的话。我完全同意，每层成本点是一个有用的公制。但是，我不会广泛播出该公制。我只会将其用作内部指标，以将给定积压项目（故事点）的大小转换为积压项目（美元）的贴纸价格。这样，该团队并未通过像故事点这样的公用事业度量的任意解释来衡量。但是，您的观点正在鼓励一个新的博客文章......嗯。
Samar Elatta.
我真的很喜欢这个方法。谢谢分享。我一直在使用类似的方法，但在开始做发布计划时使用这个比率来估计项目的总成本，因为我指导的组织需要预先知道总成本。
萨马尔，感谢您的评论。我完全同意你的看法，大多数组织都有一个诚实的问题，就“费用是多少？”通常，真正的问题是“我应该向您的项目分配多少预算？”它让我疯狂听到敏捷专家拒绝回答这个问题和需求动态资金模型。授予，每月甚至季度资金周期将是理想的，每个下午或产品所有者都必须使业务案例更多的迭代。亚博vip9通道但在我见过的几十家公司中，几乎从未发生过。相反，我宁愿在系统内工作要用*一些*金钱，然后在该约束中提供最有价值。
马克古斯塔夫森
我只是留下了一个小的软件公司,对于一个成熟和稳定的scrum团队建立的速度,我们可以向我们的客户提供自定义代码,要求它(我们通常不喜欢做定制工作)的价格基于成本/故事点(佣金与适当的标记,利润等)
我现在正在向一个具有强大预算过程中的更大的公共公司发展的发展。这篇文章将大大帮助我，因为我将Scrum引入我们的Dev过程！
马克，谢谢你的夸奖。每个故事点的成本是一个很好的度量标准，可以用来将团队的内部计划度量(故事点)转换为面向涉众的度量(标签价格)。但是，要注意不要把这个标准暴露给高级管理人员。他们将倾向于使用it作为一种性能指标，并将其作为一种控制成本的手段。相反，你应该专注于你的可靠性，用固定的燃烧率和稳定的速度。
再次感谢评论。
格雷厄姆凯莉
杰西关于你之前的两点:
1）完全同意在给定预算的制约中提供“最有价值”。这真的是最低可行产品的精益哲学的联系。
2）我不同意没有透露故事的态度。我是透明度的巨大粉丝，因此是责任。对于太长的软件开发被视为隐藏在（通常看似）不灵活的黑洞背后。敏捷是帮助这个，但它仍然可以进一步进一步。软件需要变得更加负责，并围绕分配成本对故事点的透明度是这样做的很好的方式。这也可以是停止管理范围蠕变的好方法。
格雷厄姆,很好。我同意给待定项目设定一个标价会让业务人员在最后时刻考虑所有这些附加内容。亚博vip9通道如果传播转换度量(每故事点的成本)能够在您的组织中创造更多的透明度和开放的对话，我也完全同意。然而，我不止一次地看到它适得其反:“为什么你的速度在每次迭代中不提高15%呢?“为了实现我们的PMO效率目标，您真的需要将每个故事点的成本降低到1000美元”....“为什么你们团队不以工作日为单位进行评估?”用错误的单位来估计，然后再换算成劳动力成本，这似乎很复杂。”
最后，我相信“平衡”胜过“透明度”。创造开放文化做得好，但其他团队可能会发现他们必须管理渗透到他们的内部文化的霸道的数量。
约翰
我同意杰西的观点。故事点不应该直接映射到人工成本的原因是，故事点是“相对的”规模。如果你使用斐波那契数列，2和8之间的工作量，2不一定是8的4倍。
通过比较可以通过历史基准测量的点的权重比较可以测量的重量，相对尺寸允许估计工作更准确。通过将故事指向显式劳动力成本/小时/天，您正在失去相对尺寸的好处，并使其明确，估计中更容易出错。
威廉福恩
好帖子。我认为这是我第一次看到这一点简单而清楚地解释了这一点。值得注意的是，在一天结束时，我们仍然是一如既往地处理估计数。杀手烧伤率使得这些数字更真实。问题是烧伤率将波动 - 这是野兽的本质。除非你在很长一段时间做敏捷它可能很难实现这一目标。即使您确实有可靠的烧伤率，为偶尔的管理/客户准备了与管理/客户端的偶尔对话，它开始花费更多“比你告诉它会花费”
威廉，谢谢你的夸奖。关于敏捷转变过程中产生的意外成本，我认为你提出了一个我认为值得用一篇完整的文章来发表的观点。敬请期待……
Arunkumar
杰西小套
谢谢你的这个美妙的帖子。这让我们了解敏捷项目可以做出成本计算的良好理解。该文件非常简单易懂。继续发布更多。
再次感谢!
Arunkumar，谢谢你的慷慨评论。如果您继续评论更像这样，我会继续发布更多:)
唐娜伍德拉夫
这与我们目前的一些估计和预测过程不同，我们今天关注我们的项目，这些过程主要是瀑布的项目。我想知道你如何估计非劳动力和外部劳动力成本？目前我们预测项目何时批准。（硬件，软件，工作陈述等）。劳动力是我思考的容易的一部分。想法？
斯瓦蒂
这是一个很棒的帖子。我想知道如何计算第二种方法的完全加载的成本。
谢谢
asad jobunputra
我没有专门的团队。我有任何给定的Sprint的专用人员分支，但我必须与其他举措共享我的团队（支持旧产品，新产品开发，客户定制）。
您如何调整预算中的预算和迭代的预算方法，但在整个项目/年内没有相同的工作人员？
萨
因此，基本上这使得它成为基于资源的预算模型而不是基于可交付的固定价格模型。
这也是有意义的，因为敏捷从不会在项目工作开始前强调完整的需求规范文档集。
谢谢你的博客文章。
杰里米方式
我是被介绍到这个方法的，而且我从来没有接受过任何关于敏捷it精益预算的培训。我对即将学到的东西很兴奋。