在敏捷项目中，预算的计算是非常重要的，它直接影响着项目的进行和开发的进度。那么敏捷项目预算怎么算出来的呢？通常，敏捷开发数据是根据以下几个方面来计算预算的。

首先，敏捷项目的预算是根据开发团队的人员技能和成本来确定的。团队成员的技能水平和工资待遇是预算的重要因素之一，因为开发团队的人力资源是项目进展的基础。通常情况下，具有高技能水平的人员工资也相应较高，因此在确定预算时需要综合考虑团队成员的技术水平和工资要求。

其次，敏捷开发数据的预算还要考虑到项目的规模和时间安排。项目的规模和时间是决定预算的另外两个重要因素。较大规模的项目通常需要更多的人力和时间投入，而短期项目则需要更高的人力集中度和高效率的工作。在敏捷项目中，要根据项目规模的大小和时间的安排来调整预算，以确保开发的顺利进行。

最后，除了人员技能、成本和项目规模时间外，敏捷开发数据的预算还要考虑到项目的风险。虽然敏捷开发在一定程度上可以降低项目的风险，但仍然有可能遇到一些风险和挑战。在制定预算时，要对潜在的风险进行评估，并事先留出一定的财务储备以应对可能发生的问题。这样可以有效缓解项目的风险，并保证项目的顺利进行。

综上所述，敏捷项目的预算是根据开发团队的人员技能和成本、项目的规模和时间以及项目的风险来确定的。通过综合考虑这些方面的因素，可以制定出科学合理的预算，为敏捷项目的开发提供必要的财务支持。同时，在项目进行中也要随时对预算做出调整，以适应项目的变化和发展。

浅谈敏捷估算与规划 最近在看敏捷软件开发实践：估算与规划，结合自己在工作的中的实践，浅谈一点自己的想法和总结

总的来说敏捷估算与规划更关注纵向的特性，而非横向的活动根据大小/速度=时间以及故事点/实际时间=速度的关系，敏捷项目规划能灵活地结合时间速度大小这些变量来规划和调整产品愿景按照优先级和速率梳理出分层的发布计划或者迭代计划，再按照优先级进入迭代开发敏捷估算与计划更强调集体合作和响应变化敏捷计划是具有欺骗性的在某个层面上，它相当容易建议一些故事卡片，确定它们的优先级，把它们分配到不同的发布迭代周期，然后添加其他的细节来获得下一轮的迭代计划

计划对任何敏捷开发项目都是不可缺少的组成部分首先，敏捷开发小组会进行大量的计划活动，但这些活动被更为均衡地分布于项目的整个开发过程其次，敏捷开发小组会直接面对不确定性这一被许多非敏捷开发小组所忽视的关键因素计划重要吗？当然重要随着知识的获取和不确定性的降低调整计划重要吗？当然重要

敏捷开发方法强调实际交付价值而不是做出一些非凡的但是无法实现计划和承诺获得适应变化的应用环境的灵活性，与绝对地遵守原始计划是互相矛盾的

减少目标不确定性（我们到底要构建什么）和方法不确定性（我们如何构建它）

计划是基于我们在某个特定时间点上所知道的东西做出的，而不确定性则是对我们所不知道的事情对目标或者方法的另一种表述

1.规划的目的

好的规划过程通过以下活动来支持这种对价值的探求：

减少风险（估算能揭示项目中存在的部分黑暗角落，提高对项目中的各项风险认识）

降低不确定性（持续的规划能逐步明确项目中的某些不确定性）

提供更好的决策支持（项目规划时所作出的许多决策都是折中后的决定，我们经常在功能特性与投入的精力成本和时间之间进行类似的折中，要做出这些决策，就需要对成本和收益进行估算）

建立信任（频繁地可靠地交付承诺的功能可以在产品的开发人员和产品的客户之间建立信任）

传递信息（计划可以传递针对项目的期待，并且描述完成项目的可能路径之一）

2.规划失败的原因

基于活动而不是基于特性进行计划（特性才是客户价值的计量单位基于活动的计划导致超期的原因包括：活动不会提前完成，延误沿着计划表向下传递，活动不是互相独立的）

多任务处理导致更多的延迟

不按优先级开发特性

忽视了不确定性（传统规划方法的第四个缺点是无法意识到不确定性的存在反映这种不确定性的方法之一是将结束时间表述为一个时间范围随着项目的进展，项目的不确定性和风险会逐渐减少，估算就可以进一步细化，变得更加精准）

把估算当作承诺（每个估算都包含了一定的可能性，他表示该特定工作在估算的时间长度内完成的可能性，并不能当成承诺）

3.敏捷规划方法

规划更多的是关于你要学习什么，而不是它（产品）最终是什么当我们承认在某种程度上不知道结果，也不可能提前知道结果的时候，规划就成为一个设定并修正目标的过程，而这些目标指引我们实现一个更长远的目标

（1）规划的不同层次

设定和修正目标的时候，重要的是记住我们无法看到地平线以外的东西，而且当我们试图规划的距离超出视线范围越远，计划的准确性降低得就越迅速

（2）满意条件驱动发布规划和迭代规划

4.使用故事点估算

（1）故事点是相对

故事点是用于表达用户故事功能或其他工作的总体规模的度量单位，我们给每个故事分配一个点值分配的原始点值本身并不重要，重要的是值得相对大小故事点估计是对开发该功能所需的工作量开发工作的复杂性以及蕴藏的风险等方面的综合

两种常用的故事点估计：

一以将要处理的用户故事中，从您认为最小的那些故事里面选择一个，然后设定它被估计1个故事点

二选择一个基本处于中等的用户故事，然后给它分配一个大致处于你的取值范围中间的点值

（2）速度 velocity

要理解为什么没有单位的故事点估计有可能会有效，就必须介绍速度这个概念速度是对开发小组的进度率的度量可以通过计算小组在一次迭代中完成的用户故事点数的总和来得到速度

敏捷估计与规划的一个关键原则是先估计出规模然后推算出持续时间

速度修正估计误差

随着开发小组在项目的用户故事上取得进展，他们的速度在最初几次迭代中就会显示出来基于故事点的估计方法的美妙之处就在于对速度的使用使得规划误差可以自我修正

5.使用理想日估计

理想时间（ideal time）是某件事在剔除了所有外围活动之后所需要的时间

耗用时间（elapsed time）是时钟（也许是日历）上显示出流逝掉的时间

两种对持续时间的度量分别有自己的用途

用理想时间而不是耗用时间来预测某件事的持续时间总是更准确，而且要容易得多

当不考虑机构性开销的时候，理想日可以被看作另一种对规模进行估计的方法，就像故事点一样可以用速度把以理想日的数量表示的规模估计转换成对持续时间的估计如果选择使用理想日进行估计，就应该为每个用户故事分配一个总的估计值

6.估计方法

收益边界渐减法则：即回报的增长幅度随着投入的增加而减小

（1）共同估计

最佳的估计是由包括将要做此工作的人在内的小组合作得到的原因一：敏捷开发中，往往不知道一项工作将有特定的哪个人来完成原因二：某个人的估计其他人可能有别的考虑

（2）估计的尺度

12358 斐波那契数列

1248 每一个数都是前一个的两倍

0有可能会作为估计范围中的一个有效值，如果我们想把所有功能都保持在一个10倍的范围内，那么极小的功能分配非零值会限制最大功能的规模且如果工作确实更接近于0而不是1，开发小组可能也不希望在计算速度时考虑完成这些功能的贡献

离最近几次迭代更远的用户故事或者其他对象可以被当做史诗用户故事或主题为了估计这些大对象，可以在后面添加大的数字：

12358132040100

（3）得到估计值的方法

专家意见

类比

分解

（4）规划扑克

更小规模的会议

开发小组需要在两个不同时期打规划扑克首先，在项目正式启动前或者在它的第一次迭代中对用户故事的初始合集进行估计需要开发小组进行两到三次1-3个小时的会议其次，小组需要在开发过程中对在迭代中发现的新用户故事进行估计

规划扑克会有效的原因：首先，规划扑克做估计时把多条专家意见放在了一起，形成了跨功能的小组，比任何单独的个人更适合做估计其次，规划扑克期间会进行活跃的对话，规划者会被要求证明自己的估计的正确性第三，对个人估计的平均可以引向更好的结果，对估计进行团体讨论也可以得到同样的效果最后，规划扑克起作用也因为它很有趣

7.重估的情况

始终牢记故事点和理想日是对规模的估计，就会发现只需要在我们确信一个用户故事的相对大小发生了变化的时候，才需要重新估计

8. 在故事点和理想人天之间进行选择

选择故事点的优势

故事点有助于驱动跨功能的行为

故事点估计不会过期

故事点是对大小的纯粹度量

故事点估算通常更快

我的理想人天不等于你的理想人天

有利于理想人天的考虑因素

理想人天在团队以外更容易解释

理想人天估算更容易开始

理想人天便于预测速度

9.为价值做规划

要建立产品功能（范围）进度和成本的最佳组合，需要对发布的产品中将要包含的用户故事和主题的成本和价值进行深远的考虑

（1）确定主题的优先级

即使我们有时间，也很少会有足够的时间来做所有的事所以要确定优先级尽管确定优先级的责任由整个开发小组共同承担，但成果由产品所有者享有估计少量的功能往往是很困难的我们将单个的用户故事和功能聚集到一些主题中然后，根据用户故事和主题之间的相对关系，确定它们的优先级，来满足建立发布计划的需求选择主题的时候应该让它们都能都能分别独立地定义一组对用户或是客户有价值的功能

确定优先级时的因素：获得这些功能带来的经济价值；开发所需的成本；所产生的学习和知识的量及重要性；减少的风险

（2）确定经济优先级

经济指标：金钱的时间价值净现值内部收益率投资回收期贴现回收期

（3）确定渴望度优先级

阈值功能是产品要成功就必须具备的那些功能它们常常也称为必需的（must-have）功能改善阈值功能的性能或者增加阈值功能的数量对客户满意度没有多少影响

线性功能就是一个处于越多越好状态的功能这些功能称为线性功能的原因是客户满意度与功能的量线性相关一个这样的功能表现得越好（或者它越多），客户就会觉得越满意因此，产品价格常常和线性特性相关

最后，兴奋点和惊喜点是那些提供了很高的满意度，并常可以为产品增加额外价格的那些特性但是，缺少兴奋点和惊喜点并不会让客户满意度降到中性以下

实际上，兴奋点和惊喜点也常称为未被了解的需求，因为客户或用户在看到这些特性之前并不知道自己需要它们

用Kano模型评估主题（依赖问卷调查）

相对权重：另一种方法（依赖于专家判断）

平时工作中，可能调查问卷的方式更广泛一些，对用户进行分类分组，能得到广泛的数据支持

敏捷式开发到底是怎么操作的？1敏捷团队内部的行为也有制度约束，只是这个约束大多来自于团队内部（团队自己制定的各种纪律，由团队自我监督），而不是来自于团队外部（公司制定的管理制度，团队外部的人监督）2敏捷开发也会产生文档，文档主要作为一种工作的中间成果和知识的载体存在，而非作为证据存在敏捷开发中的文档不求面面俱到，但必要的文档还是一定会有的另外，诸如计划之类的文档，通常也是换了个形式存在，可能不再是一份word文件，而是墙上的一张白板3敏捷开发的过程，同时也就是一个敏捷团队成长的过程通过这个过程，让团队内的每个成员建立起共同的愿景行为模式工作方法甚至习惯，高效的沟通也是在这个过程中逐步形成的敏捷方法有十几个模型，每个模型都有若干个实践，很难说具体的实施步骤，建议可以先看看scrum方法，这种敏捷方法提供了一种比较开发的管理框架，和其他敏捷方法CMMI等公司级的管理方法相容性比较好