目录

一、使用故事点估算大小

1、故事点是相对的

2、速度

3、小结

二、使用理想人天进行估算

1、理想时间和软件开发

2、以理想人天作为对大小的度量

3、给出一个而不是多个估算值

4、小结

三、估算方法

1、共同估算

2、估算的尺度

3、得到估算值的方法

3.1、专家意见

3.2、类比

3.3、分解

4、计划扑克

5、为什么计划扑克会有效

6、小结

四、重估

五、在故事点和理想人天之间进行选择

1、有利于故事点的考虑因素

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

3、建议

4、小结

最近阅读了《敏捷软件开发实践——估算与计划》这本书，总的来说，是一本非常好的书籍。先前只是采用敏捷研发的流程，对于敏捷研发的关键环节理论理解不深，通过阅读本书，解开了很多疑惑。以下整理了第二部分的内容。

敏捷团队把对大小的估算与对时长的估算独立区分出来。

一、使用故事点估算大小

1、故事点是相对的

故事点是用于表达用户故事、特性或其他工作的总体大小的度量单位。当我们使用故事点进行估算的时候，我们给每个对象分配一个点值。我们分配的原始点值本身并不重要，重要的是点值的相对大小。

用户故事的故事点数反映了这个用户故事的总体大小。定义用户故事的大小并没有固定的公式，。更确切地说，对故事点的估算需要综合开发该功能所需的工作量、开发工作的复杂性以及蕴藏的风险等方面。

2、速度

为了理解为什么没有单位的故事点是有效的，就必须介绍一个新概念：速度。速度是对开发小组的进度生产率的度量。速度可以通过计算小组在一次迭代中完成的用户故事所分配的故事点数的总和来得到。如果小组完成了3个估算值都是5点的用户故事，他们的速度就是15,。如果他们完成了2个5点的用户故事，速度就是10.

下图的模型被用于显示对大小的估算如何被转换成对持续时间的估算和进度表。

如果把所有必须特性的故事点加在一起，就会得到对项目总体大小的估算。

如果知道团队的速度，就可以通过用大小除以速度来估算出迭代的次数。再把这个持续时间映射到日历上，就可以得到进度表。

速度修正估算误差

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

3、小结

故事点是对用户故事大小的度量。估算为10个故事点的用户故事的大小、复杂度或风险应该大致是估算为5个故事点的用户故事的两倍。10个故事点的用户故事点的大小、复杂度或者风险同样应该大致是20个用户故事的一半。有意义的知识给不同用户故事分配的点数的相对大小。

速度是对团队每次迭代的进度生产率的度量，在每次迭代结束的时候，团队可以看看他们完成了哪些用户故事，通过计算已完成用户故事的估算值之和来得到小苏的速度。

故事点知识对将要进行的工作大小的估算。与其说一个项目的持续时间好来得到小组的速度。

二、使用理想人天进行估算

1、理想时间和软件开发

在软件项目中，理想时间与耗用时间之间存在的差异并不是由于暂停、未完成的传球或者受伤造成的，而是由于我们在每天都会遇到的自然的额外开销。

理想时间为什么与耗用时间不相等的更多原因包括：

  • 为当前的发布提供支持
  • 休病假
  • 开会
  • 演示
  • 个人问题
  • 打电话
  • 特殊项目
  • 培训
  • 电子邮件
  • 回顾和预排
  • 面试候选人
  • 任务切换
  • 修复当前发布中的bug
  • 管理性检查

在软件项目中，多任务处理进一步扩大了理想时间和耗用时间之间的差距。被要求同时处理多个任务的软件开发人员在两个（或者更多）任务之间进行切换时会损失大量的效率。

在软件项目中，我们可以选择使用理想人天（idea day）对用户故事或者其他工作进行估算。使用理想人天进行估算时，你需要假定：

  • 所估算的用户故事是你将处理的唯一工作
  • 你所需要的所有东西在你开始工作时都会准备好
  • 不会被打断

2、以理想人天作为对大小的度量

当我们估算开发、测试和验收一个用户故事所需要的理想人天数时，并不需求考虑团队的工作环境所带来的的额外开销。

当不考虑组织性开销时，理想人天可以被看成另一种对大小进行估算的方法，就像故事点一样。然后，像故事点方法一样，我们可以利用速度把理想日的数量表示的大小估算转换成对持续时间的估算。

3、给出一个而不是多个估算值

如果选择使用理想人天进行估算，就应该为每个用户故事分配一个整体性的估算值。

4、小结

理想时间和耗用时间是不同的，一场美式橄榄球的理想时间是60分钟（4节，每节15分钟）。但是，在一场60分钟的比赛结束时，时钟上通常可能已经过了3个小时或者3个小时以上。导致这一差异的原因是比赛过程中可能出现的各种干扰。

使用理想人天而不是耗用人天，更容易估算开发一个用户故事所需的时间量。按照耗用人天进行估算要求我们考虑在处理这个用户故事时所有可能出现的干扰。而如果我们以理想人天进行估算，就只需要考虑完成这个用户故事所需要的时间。这时，理想人天是对大小的估算，虽然它没有故事点那么严格。

采用理想人天进行估算时，最好只为每个用户故事分配单一的估算值。应该把所有需要的时间加在一起，说某个用户故事需要9个理想人天，而不是说他需要4个程序员人天、2个测试人员人天和3个产品负责者人天。

三、估算方法

1、共同估算

估算值并不是由团队中的单个人建立的。敏捷团队并不是依靠某一位专家来进行估算。除了众所周知的原因——将要做此工作的人对工作做出的估算比其他人做出的更准确以外，最佳的估算是由团队——包括将要做此工作的人在内——协作做出的。

2、估算的尺度

研究显示我们在对同一数量级内的东西进行估算时做得最好。

如果我们要在一个数量级内估算所有的用户故事，就意味着要在一个同样细致的程度上编写所有的用户故事。对于还不确定是否需要的特性或者最近不会实现的特性，写一个更大粒度的用户故事往往可能更为恰当。这样大粒度的用户故事有时被称为史诗（epic）。

一组相关的用户故事可能会被整合在一起（如果使用记录卡片，通常用回形针订在一起），并在估算和发布计划中都被当做单一的实体。这样的一组用户故事通常被称为一个主题（theme）。仅仅从大小来说，一个史诗往往本身就是一个主题。

通过使用主题来聚合一些用户故事和将某些用户故事写成史诗，团队可以减少估算所需的工作量。但是，他们需要认识到，对于主题和史诗进行估算的不确定性，比对更明确、更小的用户故事进行估算时更高。

3、得到估算值的方法

3种最常用的估算方法：

  • 专家意见
  • 类比
  • 分解

每种方法 都可以单独使用，但要得到最佳结果，应综合使用这3种方法。

3.1、专家意见

在基于专家意见的估算方法中，专家被问到某件事情需要多长时间或者它会有多大，专家根据他自己的直接给出估算。

根据专家意见进行评估的一个好处在于它通常不需要太长时间。

3.2、类比

在使用类比进行估算时，估算者将估算中的用户故事与一个或者多个其他故事进行比较。

3.3、分解

分解是指将一个用户故事或者特性分解为更小、更容易估算的部分。

4、计划扑克

敏捷团队最佳的规划方法是打计划扑克。计划扑克把专家意见、类比和分解结合到一种令人愉快的估算方法中，可以产生快速而可靠地估算。

计划扑克的参与者包括团队所有的开发人员（开发人员包括所以的程序员、测试人员、数据库工程师、分析师、用户交互设计师等）。

团队需要在两个不同的时间玩计划扑克

  1. 在项目启动之前或者在项目的第一次迭代中，通常会有大量的对象需要估算。对用户故事的初始集合进行估算时，需要团队进行两到三次1~3小时的会议。这自然取决于有多少对象需要估算、团队的大小以及产品负责人能否简洁地阐明所有需求的能力。
  2. 在迭代的开发过程中，团队需要对新发现的用户故事进行估算。

5、为什么计划扑克会有效

（1）计划扑克把多个转件的意见放到了一起来做估算；

（2）在计划扑克期间会进行活跃的对话，估算者会被同事要求证明自己的估算的正确性；

（3）研究显示，对每个人估算值的平均可以带来更好的结果，对估算进行团队讨论也同样如此。

6、小结

花更多的时间和精力来得到一个估算值，并不一定会提高它的准确性。应该根据估算的目的来决定在估算中投入多少工作量。虽然众所周知，将要做某项工作的人才能给出最好的估算，但在一个敏捷团队中，我们无法提前知道谁将负责这项工作。因此，估算应该是一项团队协作完成的活动。

估算应该基于一个预先定义的尺度。将会在近期处理的功能以及需要非常可靠估算的功能应该足够小，因此他们可以使用一个1~10之间的非线性尺度来进行估算，例如1、2、3、5和8。在最近的几次迭代中不太可能需要实现的大功能可以不分解，用大的单位，如13、20、40和100来估算。

要得到一个估算值，可以依赖专家意见、类比和分解。计划扑克是一个有趣而有效的方法，它结合了上述3种办法。在计划扑克中，每个估算者有一叠写着有效估算值的卡片。没讨论一个功能，每个估算者就选择一张代表他的估算值的卡片。所有的卡片都会同时展示出来。团队对估算值进行讨论，重复这个过程直到团队的估算达成一致。

四、重估

在使用故事点或者理想人天进行估算时最常见的问题之一就是“我们何时进行重估？”要得到答案，至关重要的是记住故事点或者理想人天是对要实现的功能的总体规模和复杂度的估算。故事点尤其不是对实现一个功能所需时间的估算，实现一个功能所需的时间是一个关于功能的大小（以故事点或者理想人天表示的估算）和小组的进度率（以小组的速度来表示）的函数。

始终牢记故事点和理想人天是对大小的估算，只要在我们确信一个用户故事的相对大小发生了变化时，才需要重新估算。使用故事点或者理想人天的时候，我们不会只因为某个用户故事的实现时间比我们预想的时间长就进行重估。

无法学习才是真正的失败。从每一个重估的用户故事中学习，然后把取得的经验转化为成功的推动力。

记住故事点和理想人天是对功能规模的估算，可以帮助你知道何时应进行重估。只有在你对一个或者多个故事的相对大小的看法发生变化时，才应该进行重估。不要只因为进度没有你预期的那么快而进行重估。可以让速度这个很好地均衡器来解决大多数估算中的不准确性。

五、在故事点和理想人天之间进行选择

作为对大小的度量，故事点和理想人天分别有自己的优势。本章介绍了分别有利于两种方法的主要考虑因素。

1、有利于故事点的考虑因素

倾向于采用故事点进行估算的要点，如下：

  • 故事点有助于驱动跨功能的行为
  • 故事点估算不会过期
  • 故事点是纯粹对大小的度量
  • 故事点估算通常更快
  • 我的理想人天不等于你的理想人天

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

有利于采用理想人天进行估算的要点如下：

  • 理想人天在团队以外更容易理解；
  • 理想人天估算更容易开始
  • 理想人天便于预测速度

3、建议

作者建议使用故事点。发现把他们作为对大小的纯粹度量所带来的好处更有说服力。故事点对团队跨功能行为的促进是一个巨大的有利之处。

4、小结

团队可以选择使用故事点或者理想人天进行估算。两者都是具有一定优点的可行方法。

故事点的优势是可以帮助促进团队的跨功能行为。此外，由于故事点是更为纯粹的对大小的估算，因此即使团队在技术上或者领域知识上取得了进步，也并不需要重估他们。用故事点进行估算往往比用理想人天估算要快。最后，与理想人天不同，可以在团队成员之间对故事点进行比较。如果一个团队成员认为某件事需要4个理想人天，而另一个成员认为只需要1个理想人天，也许他们都是对的，但是他们缺乏讨论的共同基础，无法建立一个单一的估算值。

理想人天的优势在于更容易向团队之外的人进行解释，以及更容易开始。

倾向使用故事点，使用故事点进行估算的优点更有说服力。如果团队对单纯的大小进行估算存在困难，我会让他们用理想人天开始估算，然后再让他们转化到故事点上。我会更多的问“这个功能的大小与我们刚才估算的那个相比怎么样？”而不是“他会需要多少个理想人天？”大部分团队几乎不会注意到这种渐进式的转变，而当他们意识到的时候，他们已经是在用故事点而不是理想人天进行思考了。

敏捷软件开发实践——估算与计划02相关推荐

  1. 敏捷软件开发实践——估算与计划（01）

    目录 一.计划的目的 1.为什么要进行估算和计划 2.优秀的计划是什么 3.敏捷计划是什么 4.小结 二.计划失败的原因 1.基于活动而不是基于特性进行计划 1.1.活动不会提前完成 1.2.延误沿着 ...

  2. 软件开发计划_敏捷软件开发实践：估算与计划读书笔记113第11章 确定渴望度优先级...

    <敏捷软件开发实践:估算与计划>第11章 确定渴望度优先级,重点和要点的思维导图及文字内容. 第11章 确定渴望度优先级 If you have a choice of two thing ...

  3. 软件开发计划_敏捷软件开发实践：估算与计划读书笔记123第21章 关于计划的沟通...

    <敏捷软件开发实践:估算与计划>第21章 关于计划的沟通,重点和要点的思维导图及文字内容. 第21章 关于计划的沟通 The more elaborate our means of com ...

  4. 敏捷软件开发实践-Sprint Status Track

    介绍: 对于敏捷软件开发来说,能时刻保持跟进项目的进度是非常重要的,因为你可以随时了解团队的健康状况,并且对各种突发情况进行突发的处理,从而保证每个迭代结束后我们的项目可以按时的交付. 实现方式: 看 ...

  5. 敏捷软件开发实践-客户合作胜过合同谈判

    2019独角兽企业重金招聘Python工程师标准>>> 不能像订购日用品一样来订购软件.你不能够仅仅写下一份关于你想要的软件的描述,然后就让人在固定的时间内以固定的价格去开发它.所有 ...

  6. 敏捷软件开发实践-Sprint Setup Meeting

    介绍: 对于一个迭代周期Sprint来说,最先开始的活动并且也是最重要的活动之一就是Sprint Setup Meeting. 在这个会议上,我们主要会去探讨一些这个Sprint我们需要完成哪些sto ...

  7. 《软件工程》第3章敏捷软件开发

    敏捷方法都具有以下共同的特性 1.规格说明.设计和实现过程交织在一起: 2.系统按照一系列增量进行开发: 3.使用广泛的工具来支持开发过程. §3.1敏捷方法 敏捷方法的原则 原则 描述 客户参与 客 ...

  8. 敏捷软件开发和精益看板管理

    引自 blog.sina.com.cn/s/blog_493a84550100ax35.html 最近看了InfoQ上关于精益看板在软件开发上的一些实践和应用的文章,敏捷软件开发借鉴了很多TPS精益生 ...

  9. 《敏捷软件开发(原则模式与实践)》读书笔记

    <敏捷软件开发>读书分享 由于书是由英文书籍翻译,读起来会难免拗口,本次分享是由<敏捷软件开发>结合网上相关资料总结而成. 传统的瀑布式开发 瀑布模型式是最典型的预见性的方法, ...

最新文章

  1. bootstrap3中关于布局的两种样式
  2. C# 引用类型和值类型
  3. python中outside loop_Python: 'break' outside loop
  4. 英特尔nuc能代替主机吗_制砂机生产的沙子可靠吗？能代替天然沙子吗？
  5. ubuntu创建文件夹和删除文件
  6. 【主席树】可持久化数组（金牌导航 可持久化数据结构-3）
  7. paip.提升效率---模块化设计方法V2012.9.15
  8. ant design 时间控件清空值
  9. java工厂模式应用场景_详解Java设计模式之《简单工厂模式》
  10. Win10 KeilC51-C251-ARM共存方法
  11. 2019高考数学必考知识点,高考数学知识板块
  12. Call to a member function validate() on null
  13. Python学习Day01
  14. ZOJ - 3939
  15. 能领取拼多多优惠券的微信小程序
  16. STM32f1之L298N电机驱动+PWM调速（附主代码）
  17. SDKMAN!使用指南
  18. 推荐一些坚持原创的公众号
  19. 液晶12864显示字符
  20. python中的装包与解包*，**

热门文章

  1. python requests post请求_实例解析Python3 如何利用requests 库进行post携带账号密码请求数据...
  2. 百度搜索结果 转换_百度搜索搜不到“百度拦截搜索结果”
  3. 如何使用htmlq提取html文件内容
  4. Java游戏服务器系列之Netty详解
  5. 面试常问的 25+ 个 Linux 命令
  6. stm32单片机入门视频教程看哪个？一般用什么软件编程比较好？
  7. JavaScript初学者编程题(12)
  8. JavaScript初学者编程题(9)
  9. java 数字三角形_数字三角形 Number Triangles（java的MLE解决办法）
  10. 关于学习Python的一点学习总结（47-＞静态方法和类方法）