敏捷ACP.敏捷估计与规划.Mike Cohn.

第一部分    传统规划失败的原因  vs  敏捷规划有效的原因

要回答一个 新产品的范围/进度/资源的组合问题，传统规划过程一般不会产生令人非常满意的答案和最终产品。以下- -些论据可以支持这个结论:
●大约2/3的项目会显著超出费用预算(LedererandPrasad1992)
●产 品中64%的功能很少或从不会被使用(Johnson 2002)
●一般项目花费的时间会超出进度表100%(Standish2001)

导致规划失败的5个原因:

• 传统规划方法的一一个 关键问题就是，它们强调的是各项活动的完成而不是对功能的交付。基于活动的规划的第一个问题在于客户并不能从活动的完成中获得价值。功能才是客户价值的计量单位。因此，规划也应该是在功能层面上，而不是在活动层面上。
• 传统规划方法常会失败的第二个原因是多任务处理，也就是同时处理多个任务。多任务处理会对生产率产生可怕的影响。
• 传统规划方法不定能够带来高价值产品的第三个原因是，制订的计划没有按照对用户和客户所具有的价值大小来排列工作的优先级。
• 传统规划方法的第四个缺点是不承认不确定性的存在。我们忽视了与产品相关的不确定性，假定最初的需求分析就可以产生对产品的完整、完善的定义。
• 在每个估计中都包含了-一个可能性，它表示一项特定工作在估计的时间内完成的可能性.很多公司把估计当成了承诺.

敏捷规划的目的是以迭代的方式发现总体产品开发问题的最佳解决方案, "在哪段时间内使用哪些资源来得到哪些功能"。敏捷估计和规划方法可以成功找到这样的解决方案的原因包括:

• 计划是在不同层次上做出的，并且重规划频繁地发生;
• 计划是根据功能而不是根据任务做出的;首先估计规模，然后根据规模的估计值推算出持续时间;
• 小故事保持L作的流动，而且每次迭代结束时会消除处理中的工作;
• 是在小组层次而不是个人层次对进度进行度量;承认不确定性并为之做计划。

敏捷估计和规划的12条原则:

(1)整个小组参与。虽然可能很明显只有1~2个特定的小组成员会处理正在估计的故事或任务，但整个小组做出的估计才是最好的。小组成员间分担的职责越多，小组可以共享的成功也就越多。
(2)在不同层次上进行规划。发布计划、迭代计划和每日计划分别以不同的精度覆盖了不同的时间范围，而且各有其特定的用途。
(3)使用不同度量单位，让对规模和持续时间的估计保持独立。
(4)用功能或者日期来体现不确定性。如果新功能的量是固定的，就把不确定性表示为一个日期范围(“我们会在第三季度完成”或者“我们会在7~10次迭代中完成" )。如果日期是固定的，就需要表示在要交付的确切功能上的不确定性(“我们将在12月31日完成，产品至少会包含这些新功能，最多可能只会再包含那些新功能”)。不确定性较大的时候，就使用较大的单位(例如迭代、月，然后是季度)。

(5)经常重规划。
(6)跟踪进度并沟通。燃尽图和其他让人一眼就能看明白的项目进度指示器是最好的。
(7)承认学习的重要性。
(8)规划具有适当规模的功能。迭代中用0.5人天作为单位;
(9)确定功能优先级。
(10)把估计和计划建立在事实上。有关一一个功能完成了多少的问题。很容易知道-一个功能完成了0%的时候(我们还没有开始处理它),也相当容易知道我们已经完成了100%的时候(产品所有者的所有满意条件测试都已经通过了)。

(11) 保留一些松弛度。尤其是在规划一次迭代的时候，不要规划用掉所有小组成员100%的时间。
(12)通过前瞻规划协调多个小组。在涉及多个开发小组的项目中，应该通过滚动前瞻规划来协调他们的工作。通过前瞻和把特定功能分配到即将到来的特定迭代，可以规划和调节小组间的依赖。

第二部分  敏捷规划与估计

1. 规模估计:  相对故事点  vs  理想人天,  更建议用故事点做规模估计

,    

故事点	理想人天
有利于采用故事点进行估计的要点 ●故事点有 助于驱动跨功能的行为 ●故事点估计不会过期 ●故事点是纯粹对规模的度量 ●故事点估计通常更快 ●我的理想日不等于您的理想日	有利于采用理想日进行估计的要点 ●理想日在小组以外更容易解释 ●理想日估计更容易开始
注:   1. 不要过分估计, 估计有回报递减原则;   小组共同估计.   2. 规划扑克；  :斐波纳契数列：0，0.5，1，2，3，5，8，13，20，30，50，无穷大                              等比数列；   3. 故事--史诗--主题；  故事的规模要控制在一个数量级内，小于10人日；

     2. 为价值做规划

                                

确定优先级的因素	(1)获得这些功能带来的经济价值。 (2)开发(可能还包含支持)新功能所需的成本。 (3)开发新功能所产生的学习和知识的量及重要性。--产品知识+项目知识 (4)开发这些功能所减少的风险。        --进度风险；成本风险；功能风险；技术风险；商业风险；
确定功能满意度优先级	1. kano模型，  优先开发阀值功能，即必需功能；必需的功能要在发布前完成，不过不是所有的必需功能都需要全额完成；必需功能再多无法提高满意度；但没有会影响降低满意度； 其次，时间允许，开发尽可能多的线性功能；----越多越好 时间允许，确定少量的亮点功能。      评估方法1： 问卷调查功能的正反两个态度          评估方法2： 相对权重法---专家判断,有此功能的收益和无此功能带来的惩罚做估算 优先级=价值百分比 /成本百分比 ；  比值越大，优先级越高。

第三部分   项目进度安排------发布计划+迭代计划+进度表

1. 发布规划---项目是受功能驱动的，--高层次视图，以用户故事为基础，以价值交付为目标

   发布规划就是建立很高层次的、覆盖超过一次迭代周 期长度的计划的过程。一次典型的发布可能会覆 盖3~6个月，而且根据迭代周期的长度,可能具有3~12次或者更多次迭代。粗略地看，确定一次发布中可以有多少工作，以及确定要实现哪些用户故事是一个非常直接的过程。用规划出的迭代次数乘上开发小组预期的或历史的速度，就可以得到能够完成的工作总量。然后我们可以选择适合这个工作量,发布计划本身常常是被简单地记录成-一个列表，列出项目将要开发的用户故事。

   //1. 发布规划，不是建立计划，规定谁负责哪个故事，谁负责哪个工作和活动顺序留给团队，并且尽量推迟决定。

  //2 。 发布规划，不拆解故事到任务。

 2. 迭代规划---迭代计划会上确定，迭代计划会不分配任务，迭代目标是小组统一的承诺

   优先级变化的一个来源是选代回顾会议。在迭代回顾中，要向项目利益相关者、扩展的项目开发群以及其他所有感兴趣的人演示在这次选代中增加的新功能和新能力.在这些法代回顾中常会得到高价值的反馈.他们常会提出一些好的新想法，会取代以前确定的高优先级对聋的位置.

	用户故事---》任务
	任务分解结构
	速度驱动的迭代规划 使用" 昨日天气"的方法来确定在当前途代中应该规划多少个故事点或是理想日。
	承诺驱动的迭代计划，要求开发小组把用户故事逐个添加到法代中，直到他们无法承诺完成更多的故事. 更倾向用承诺驱动的迭代规划方法，因为速度本来就不准确。
●正在处理的发布的时间长度 ●不确定性的多少 ●获得反馈的难易程度 ●优先级可以保持多久不变 ●不用外部反馈自行工作的意愿的强弱 ●迭代的系统开销 ●紧迫感的产生有多快	选择选代长度时考虑的因素
一直采用2周的迭代长度可能会使开发小组过度紧张，因为一直会有交付的压力，最终期限也总是不会超过下周。我最喜欢用来减轻这种紧张的办法是采用6次2周的迭代加1次1周的迭代的大循环。我把这个循环称为:“6x2+ 1”。 在2周长度的迭代中，开发小组处理产品所有者确定为优先的对象。而在1周长度的迭代中，小组自行选择工作。这并不意味着欢乐时光或是在沙滩上休息1周，而是让小组中的人员使用这个时间来集中处理他们认为项目中应该优先处理的事情。程序员可以进行一些他们认为如果在其他迭代中间进行则风险太高的重构工作，或是试验一些有关的新技术。测试人员可以用这个时间来把一些遗留的手工测试自动化，赶上进度。分析师则可以对他认为没有受到 足够重视的，即将到来的大型故事进行处理。 给小组一个机会，让他们可以有1周的时间自行确定工作优先级，可以很有效地恢复小组的活力。需要强调的是，这1周的时间不是用来倾倒以前迭代中的散漫工作的垃圾场，而是用来让小组清理一些技术欠账的时间。这些技术上的欠账要么是在以前的迭代中学习如何成为敏捷开发时产生的，要么是在项目还不是敏捷开发的时候产生的。	6X2+1

 3. 估计速度---速度范围---历史值，试行一次迭代，作出预测

不确定性锥形
试行迭代
作出预测	(1)估计每个人每天可以在项目.上工作的小时数。 (2)确定在迭代中可以用在项目，上的总小时数。 (3)任意地、在某种程度上随机地选择用户故事，把它们扩展成组成它们的任务。重复这个步骤直到确定了足够的任务来填满迭代中的小时数。 (4)把上述步骤确定出的速度转换成一个范围。

 4. 为不确定性做缓冲规划---功能缓冲区+进度缓冲+成本缓冲

功能缓冲区	这个对功能进行缓冲的过程和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%。更小的缓冲区也许不能为整个项目提供足够的保护。

第四部分  计划的跟踪与交流

1. 发布计划的监督---发布燃尽图；发布条形燃尽图；停车场图；

在发布开始的时候，我们会建立-一个计划，其内容类似于“在接下来4个月时间的8次迭代中，我们要完成大约240个故事点(或理想日)的工作。
 

这些力量(已完成的工作、改变的需求和修改的估计值)可以看作类似于船只所受到的风的力量(称为偏航，leeway)和海 的力量(称为漂移，drift)。 考虑一下图19-1，它显示出对- -条船起作用的力量。图中显示的船实际航行的距离会比从里程表上读出的数据少。类似地，虽然船上的罗盘在整个航程中都显示朝向正东，风会让它产生朝南的偏航。如果不进行航向调整，这条船会花更长的时间，才能到达-一个离最初目标有- -些距离的某个地方。如果在头脑中重新标注图19-1中的箭头，把漂移和偏航改成需求的变化(增加或除去功能)和估计值的变化。图19-1就反映了相对于进度表跟踪-一个软件项目的挑战。
 

发布燃尽图
发布燃尽条形图	绘制这类耗散图的时候要记住4条简单的规则。 ●只要完成了工作， 就要降低顶部。 ●对工作进行重估时， 顶部可能向上，也可能向下移动。----重估变动上部 ●添加新工作时，底部被降低。 ●去掉工作时，底部被升高。
停车场图	在停车场图中，发布中的每个主题(或- -组用户故事)周围都有一个大矩形框。 每个框上都标注了它们的名称、主题中故事的数目、这些故事的故事点或理想日数目，以及已完成的故事点比例。

 2. 迭代计划跟进---任务板，迭代燃尽图；

任务板	一次迭代中使用的任务板图 //1  任务在签入前准备好测试标准和环境。 //2 开发完，进入待测试验证阶段，测试通过后，才已完成
迭代燃尽图	在一个项目中，了解还剩多少事要做远比了解已经做了多少事有用。 此外，跟踪已完成的工作量并把它与原始估计需要的工作量进行比较，会导致“评估顾虑"(Sanders 1984)。当估计者对提供估计值感到顾虑的时候，众所周知的“战斗或逃跑”的本能就会开始起作用，估计者就会更多地依赖本能而不是分析的方法(Jorgensen 2004)。 //不建议跟进个人速度

 3 与计划和进度有关的沟通

就计划进行沟通	当被问及一个项目的进度表时，把要交付的故事点数目加起来，除以对速度的猜测值，然后说出类似“我们将在6月14日交付，离现在还有7.2次迭代”的话是很有诱惑力的做法。这种做法是错误的，因为它给人的印象是我们用来建立计划的知识足够精确，可以支持这样的估计。 //注意范围，考虑不确定性 作为这种沟通的一一个例子， www.XProgramming.com 的Ron Jfeffries(2004) 建议像下面这样表述: 目前，看起来这是一个200点的项目。根据我们在其他项目上的表现(或者随机的猜测),在具有N名程序员,和您的密切参与下，这样规模的项目需要4~6个月的时间。 不过，我们每2周就会向您交付一次软件，并根据您的满意程度勾出完成的功能故事。好消息是如果您不满意，就可以停止开发。更好的消息是，如果您在完成所有功能前就感到满意了，您也可以停止开发。不好的消息是，您需要和我们一-起工作，来让我们了解您的满意的含义是什么。最好的 消息是，一旦有足够的功能可以工作，让程序是有用的了，您就可以要求我们准备部署它，我们也就会那样做。随着开发的进展，我们都可以看到我们的进展速度，我们对项目所需时间的估计也会得到改进。在每种情况下，您都会看到现在正在做什么，您也会看到具体的证据表明有用的软件正在运行您所说明的测试。只要是我了解到的事情，您也马上就会知道。   与传统甘特图不同点//1。 停留在功能层面上；没有资源分配，即谁负责那些工作；
就进度进行沟通
小结	燃尽图是对进度进行沟通的主要手段，但它们常常需要同时有一一个图 显示开发小组在每次迭代中的速度。把速度考虑成-一个取值范围而不是单个值是有益的。有一个好方法可以达到这一目的，就是同时使用最近一次迭代的速度 、前8次迭代的平均速度和前8次迭代中最差的3次迭代的平均速度。这3个值很好地描绘出刚发生的情况、长期平均的情况和最坏条件下可能发生的情况。