有利于采用故事点进行估计的要点
●故事点有 助于驱动跨功能的行为
●故事点估计不会过期
●故事点是纯粹对规模的度量

●故事点估计通常更快
●我的理想日不等于您的理想日

注:

  1. 不要过分估计, 估计有回报递减原则;   小组共同估计.

  2. 规划扑克；  :斐波纳契数列：0，0.5，1，2，3，5，8，13，20，30，50，无穷大

                             等比数列；

  3. 故事--史诗--主题；  故事的规模要控制在一个数量级内，小于10人日；

(1)获得这些功能带来的经济价值。
(2)开发(可能还包含支持)新功能所需的成本。
(3)开发新功能所产生的学习和知识的量及重要性。--产品知识+项目知识
(4)开发这些功能所减少的风险。

       --进度风险；成本风险；功能风险；技术风险；商业风险；

1. kano模型， 

• 优先开发阀值功能，即必需功能；必需的功能要在发布前完成，不过不是所有的必需功能都需要全额完成；必需功能再多无法提高满意度；但没有会影响降低满意度；
• 其次，时间允许，开发尽可能多的线性功能；----越多越好
• 时间允许，确定少量的亮点功能。

评估方法1： 问卷调查功能的正反两个态度

评估方法2： 相对权重法---专家判断,有此功能的收益和无此功能带来的惩罚做估算

速度驱动的迭代规划

使用" 昨日天气"的方法来确定在当前途代中应该规划多少个故事点或是理想日。

承诺驱动的迭代计划，要求开发小组把用户故事逐个添加到法代中，直到他们无法承诺完成更多的故事.

更倾向用承诺驱动的迭代规划方法，因为速度本来就不准确。

一直采用2周的迭代长度可能会使开发小组过度紧张，因为一直会有交付的压力，最终期限也总是不会超过下周。我最喜欢用来减轻这种紧张的办法是采用6次2周的迭代加1次1周的迭代的大循环。我把这个循环称为:“6x2+ 1”。

在2周长度的迭代中，开发小组处理产品所有者确定为优先的对象。而在1周长度的迭代中，小组自行选择工作。这并不意味着欢乐时光或是在沙滩上休息1周，而是让小组中的人员使用这个时间来集中处理他们认为项目中应该优先处理的事情。程序员可以进行一些他们认为如果在其他迭代中间进行则风险太高的重构工作，或是试验一些有关的新技术。测试人员可以用这个时间来把一些遗留的手工测试自动化，赶上进度。分析师则可以对他认为没有受到
足够重视的，即将到来的大型故事进行处理。

给小组一个机会，让他们可以有1周的时间自行确定工作优先级，可以很有效地恢复小组的活力。需要强调的是，这1周的时间不是用来倾倒以前迭代中的散漫工作的垃圾场，而是用来让小组清理一些技术欠账的时间。这些技术上的欠账要么是在以前的迭代中学习如何成为敏捷开发时产生的，要么是在项目还不是敏捷开发的时候产生的。

 这个对功能进行缓冲的过程和DSDM(Dynamic Systerms DevelopmentMethod,动态系统开发方法)敏捷开发过程中的做法-样。在DSDM项目中，需求分为4类:必有的(Must Have)、应有的(Should Have)、可有的(Could Have)和不会有(Won't Have)的。DSDM把这个分类过程称为MoSCoW规则。

项目中只能把不超过70%的计划工作量分配给必有的需求。这样，DSDM项目建立了-一个相当于30%项目持续时间的功能缓冲区。

不要对每一个活动缓冲，------关键链法；

进度缓冲区设置规则

●平方和的平方 根方法在有10个以上的用户故事或者功能被估计时最可靠。但是如果您项目中的故事或功能少于10项，也许根本就不应该规划缓冲区。

 由于我们对每个对象的估计都是在50%和90%点上，这意味着这两个估计值之间的差大约是标准差的两倍。每个对象的标准差就是(w:-aj)/2，其中w;表示第I个用户故事的最坏情况(90%估计值),而a;表示同-一个故事的平均情况(50
%估计值)。我们希望项目缓冲区提供的保护水平能够和每个任务被它自己的90%估计值保护时一一样，为整个项目提供达到90%保护的水平。

 
●项目缓冲区至少应该反映整个项目持续时间的20%。更小的缓冲区也许不能为整个项目提供足够的保护。
 

绘制这类耗散图的时候要记住4条简单的规则。
●只要完成了工作， 就要降低顶部。
●对工作进行重估时， 顶部可能向上，也可能向下移动。----重估变动上部
●添加新工作时，底部被降低。
●去掉工作时，底部被升高。
 

在停车场图中，发布中的每个主题(或- -组用户故事)周围都有一个大矩形框。

每个框上都标注了它们的名称、主题中故事的数目、这些故事的故事点或理想日数目，以及已完成的故事点比例。

一次迭代中使用的任务板图

//1  任务在签入前准备好测试标准和环境。

//2 开发完，进入待测试验证阶段，测试通过后，才已完成

在一个项目中，了解还剩多少事要做远比了解已经做了多少事有用。

此外，跟踪已完成的工作量并把它与原始估计需要的工作量进行比较，会导致“评估顾虑"(Sanders 1984)。当估计者对提供估计值感到顾虑的时候，众所周知的“战斗或逃跑”的本能就会开始起作用，估计者就会更多地依赖本能而不是分析的方法(Jorgensen 2004)。
//不建议跟进个人速度

当被问及一个项目的进度表时，把要交付的故事点数目加起来，除以对速度的猜测值，然后说出类似“我们将在6月14日交付，离现在还有7.2次迭代”的话是很有诱惑力的做法。这种做法是错误的，因为它给人的印象是我们用来建立计划的知识足够精确，可以支持这样的估计。

//注意范围，考虑不确定性

作为这种沟通的一一个例子， www.XProgramming.com 的Ron Jfeffries(2004)
建议像下面这样表述:
目前，看起来这是一个200点的项目。根据我们在其他项目上的表现(或者随机的猜测),在具有N名程序员,和您的密切参与下，这样规模的项目需要4~6个月的时间。

不过，我们每2周就会向您交付一次软件，并根据您的满意程度勾出完成的功能故事。好消息是如果您不满意，就可以停止开发。更好的消息是，如果您在完成所有功能前就感到满意了，您也可以停止开发。不好的消息是，您需要和我们一-起工作，来让我们了解您的满意的含义是什么。最好的
消息是，一旦有足够的功能可以工作，让程序是有用的了，您就可以要求我们准备部署它，我们也就会那样做。随着开发的进展，我们都可以看到我们的进展速度，我们对项目所需时间的估计也会得到改进。在每种情况下，您都会看到现在正在做什么，您也会看到具体的证据表明有用的软件正在运行您所说明的测试。只要是我了解到的事情，您也马上就会知道。
 

与传统甘特图不同点//1。 停留在功能层面上；没有资源分配，即谁负责那些工作；