前阵子，一个负责产品开发的负责人，给我说，他对正在进行的产品交付项目的要求是：能够在短期内看到成果；可以随时快速的清楚进展；不需要那么多“没必要”的设计文档，却迟迟看不到交付的功能；能够随时对成果展示的不满足项进行变更。
嗯，那你们就最需要使用敏捷了，就让我们一起从《敏捷估算与规划》这本书开始进行实践吧。
1传统项目管理和敏捷项目管理的区别
首先我们一起来看一下传统项目管理和敏捷项目管理的区别？
区别1：传统项目是基于活动（项目活动）而不是基于特性（功能完成）的交付，一方面使得客户很难从活动完成中获得价值，另一方面，完成面向的是活动的完成，而不是功能特性的完成，虽然在现在的传统项目里也增加了需求的项目各阶段跟踪，但各阶段仍然面向的是需求活动，而不是功能的交付。
而基于特性（价值）的计划，审核活动的进度时，审核的重点应该是缺少的功能特性而不是遗漏的活动。
区别2多任务处理导致更多的延期
同时处理多个任务，会对生产效率产生可怕的影响。当一个人同时处理3个或者更多的任务时，用于增值任务的时间会迅速减少，而且不同任务之间切换时需要一段过渡时间。因此尽量使用专职人员，专注于在同一时间只做一件事，或者尽可能在同一天内上午和下午分别处理不同的内容。
而敏捷项目通过对在制品的限制，让团队成员尽量在短时间内聚焦于一个任务，即停止启动，聚焦当前。
区别3不按优先级开发特性
传统项目完成特性的顺序是随机的，按照便利性来安排优先级和开发顺序，而不是像敏捷项目以功能特性的价值来安排开发优先级。而且既然所有工作都需要完成，也就不需要按照什么顺序，如果在项目前期规划时，由于时间受限，需要削减功能时，会考虑到优先保证主要功能，但是如果在开发到后期，周期较紧时，如果一开始没有明确的定义，项目进展到后期，同样由于进度的压力，也会将一些更有价值的活动压缩或者不做。那么最好的方式，就是在前期做好评估，实现定义清晰关键的和高优先级的交付内容，确保关键特性或者任务不会被迫放弃或者被压缩。
区别4忽视了不确定性
传统项目容易忽视用户最终需要什么（WHAT）和产品怎么开发（HOW）的不确定性，会导致虽然完成项目，但可能不是用户想要的，项目遗漏重要的项目的活动等，反而增加了项目延期、放弃功能、降低交付质量的可能。
项目需求和计划会存在一定的不确定性，传统项目通常采用的做法是所有的需求一次交付，虽然使用需求跟踪+阶段演示的方式，或者项目最初风险评估就需要考虑到项目如果延期的应对措施，也可以部分避免这个问题，而敏捷使用短周期迭代的方法和最小可用系统的方式，可以在短周期内减少用户需要审核和产品怎么做的不确定性的影响。
区别5把估算当成了承诺
很多公司混淆了估算和承诺，只要团队给出一个估算，就会被迫按承诺完成，而一方面一些开发人员经常给出的时间常常只是开发完成的时间，并没有考虑测试验证的时间；另一方面在做出承诺之前，也会有大量的外部因素（如：商业因素、风险、资源等）影响评估的结果。而这样的估算通常会作为绩效承诺进行考核，项目的延期就会导致项目的失败。不过现在项目计划都会有多种不同的承诺计划，同时考虑项目相关的资源到位和紧急情况，也是目前较为有效的办法。而敏捷开发团队是使用发布计划、迭代计划和每日计划的方式，在对故事进行估算后，然后使用速度对所需时间进行计算，得出迭代所需的周期，然后过程中随着每个迭代对速度进行快速的调整。
当然，所有的管理理论目前逐渐的趋同，但最终都是一个目的：快速的满足客户的需求。
了解了敏捷和传统项目管理的区别后，我们一起了解敏捷估算。
2敏捷估算
敏捷估算有两种方法，分别为故事点估算和理想人天估算。
在餐厅吃饭，我们会根据相对大小来点菜，而不会按照精确的数量进行点菜。我们标准的做法是来份小的，来份大的，故事点也是如此，是相对的。
我们可以使用两种方法来进行故事点的评估，一种是找最小的故事，设定为1，或者是找一个中等规模的故事，设定为5，总的范围设定为1-10，其他的故事都和这个故事进行比较，得出故事规模的相对大小。
而速度是对开发小组生产率的度量，可以通过计算小组在一次迭代中完成的用户故事所分配的故事点数的总和得到。
把所有特性的故事点数相加在一起，就是项目的总规模，加上速度，进而推算出迭代的次数；映射到时间表上，就是进度表了。经过几次迭代后，通过对速度的修正就可以对规划的误差进行自我修正。
当我们在估算用户故事所需要的理想人天时，在不考虑额外的组织开销时，此时可以将理想人天当作对大小进行估算的方法，同故事点一样，利用速度把以理想天表示的大小转换成对持续时间的估算。
但无论如何估算，你都会发现，在需要一个估算值时，无论你怎么精细的估算，最后你都不可能得到一个准确的数值能够精确的匹配到坐标值上。
故事点或者理想人天是对要实现的功能的总体规模和复杂度的估算，并不是关于时间的估算，实现一个功能所需的时间是一个关于功能的大小（故事点或者理想人天表示的估算）和小组的进度率的函数。只有当用户故事的相对大小发生变化时才需要进行重估。
那么都有哪些估算的方法呢？
最佳的估算是-包括将要做这项工作的人-由团队协作共同估算。一方面估算的时候并不清楚谁是任务的执行者；另一方面即使是专家估算的，也需要其他人员进行讨论确定。
估算的尺度使用两个非线性序列,分别为：
1、2、3、5、8
1、2、4、8
使用上述序列进行故事点的估算，当遇到估算为“0”的故事时，依然要体现出来，即使这种概率很小，或者还可以将多个故事点为“0”的故事集合成一个故事。
得到估算值的方法：
得到估算值的方法，每种方法都可独立使用，但要得到最佳结果，需要综合使用三种方法
快速获取一个估算值时使用咨询专家意见的方法；已有类似项目，可以使用类比估算的方法；也可以将一个用户故事或者特性分解为更小，更容易估算的部分进行估算。
敏捷最佳的估算方法就是打计划扑克（Grenning2002）,计划扑克把专家意见、类比和分解结合到一种令人愉快的估算方法中，可以产生快速而可靠的估算。估算的目的在于合理性，而不是准确性。
如何在故事点和理想人天间进行选择评估方式呢？
首先，故事点有助于驱动跨功能的行为，用故事点估算可以帮助团队学会跨功能工作，故事点的估算是对单一故事点的整体估算，而理想人天则需要按照专业进行估算。
其次，故事点估算不会过期，故事点估算不会随着团队对技术、业务领域和经验的不同而发生变化，只有在故事点的相对大小发生变化的时候才需要进行重新估算。
第三，故事点是纯粹对大小的度量故事点是纯粹的对大小的度量，不受开发成员的熟练程度的变化而变化，大小就是那么大，不会随之变化，这种不变性是任何对大小的度量都希望得到的特性。
第四，故事点估算通常更快，故事点估算的时候更多是从更高层次去进行估算，
最后，我的理想人天不等于你的理想人天
当然，理想人天在团队以外容易解释，且估算容易开始，也方便快速的进行估算和预测。
一般建议使用故事点进行估算，但是可以先使用理性人日进行估算，再慢慢转向故事点估算。
3为价值而计划
在使用估算方法完成故事点的估算后，就可以对项目进行进度表的安排了。然而在进度安排之前，需要建立产品功能（范围）、进度和成本的最佳结合。
当然，在短的时间内，不可能开发完所有的功能，就需要对故事和主题进行优先级排序。此时需要考虑该主题或故事的投入产出比如何？能够获得的学习和知识的重要性和多少？开发该主题可减少的风险大小？综合这些因素进行优先级的排序。
可以根据原始需求的渴望度进行优先级选择和排序，具体的方法有两种：1.使用KANO特性进行（阈值的特性即必需的特性；线性特性；兴奋点和惊喜点）；2.根据相对权重进行（价值工程，根据功能的价值和所占的权重进行评估）。
用户故事优先级排出后，通过对用户故事进行分解，来进行具体进度的安排。（具体分解的方法可以在《用户故事与地图》书籍里进行学习。）
具体进度安排主要从发布计划、迭代计划和每日计划上进行规划。
发布计划是建立高层次的，覆盖超过一次迭代周期的计划的过程，一次典型的发布可能会覆盖3-6个月，而且根据迭代周期的长度，可能会包括3-12次或者更多次迭代。
规划一次发布计划的步骤。
发布计划建立有两种方式：一种是建立一个显示出每次迭代中要开发什么，一种是决定整个发布要开发什么，每次迭代的具体内容以后考虑。总体来说，计划一次发布时，产品负责人需要选择将具有最高优先级的对象放入第一次迭代。
迭代计划中，团队将更专注、更详细的研究哪些事情对于要完全实现那些新的迭代所选择的用户故事是必须的。
迭代计划是在迭代计划会议上制定的。迭代计划是一个电子表格，或者一组每张上写有任务的记录卡片。无论使用哪种形式，任务需和故事对应起来。需要注意的是：迭代计划时不分配任务。否则会与团队成员为达到迭代目标而做出一致的承诺相矛盾。
每日规划是开发团队每天up to15min.的事件；开发团队借由每日 Scrum 站会来检视完成冲刺目标的进度，并检视完成 Sprint 待办列表的工作进度趋势。会议或以问题为导向来开会，或基于讨论来开会。站会后立即聚到一起进行更详细的讨论，或者为冲刺中剩余的工作进行调整或重新计划。
4准备好了吗，开始冲……
在以上3个步骤完成后，我们项目的规划活动也就完成，在讨论出交付计划后，对特性进行小的任务项的分解，以一个工作日为单位进行，在显目的地方设计看板的位置，将特性图和任务项分别贴上去，进行每日站会，确保每天都有交付，即可在短时间内可以快速实现第一个冲刺（sprint）的交付。
然后，持续sprint……
那么，你准备好了吗？
让我们一起开始实践《敏捷项目估算与规划》，开始对项目进行估算和规划……
#读书荐书专题,参与活动链接https://www.jianshu.com/p/3646b7e76fd8
#今日学习打卡
