敏捷项目管理21天学习计划--敏捷估计与规划

个人过之前的章节，我们可以清楚的知道，估算交付时间、交付成本、可获得利润，对项目是否可以落地有重要的影响。

敏捷估算的基础：

1. 为什么要估算:估算可以让团队了解项目规格计算ROI和IRR，形成可执行许可的基础，有了估算，市场也可以提前的为后期产品上市做准备；
2. 谁执行估算？：产品负责人、敏捷教练；
3. 会议什么时候进行？自然是越快越好，在整个项目进行之间，同样随着逐步完善更多的信息，估算也要持续进行。敏捷提倡：拥抱变化，那既然拥抱变化，估算也要做调整，该加人手就要加人手。不要一味指望加班来压缩成本，随着90后，00后步入市场，这一代更注重生活品质，毕竟工作是为了生活；
4. 估算如何创建？方式有多种：从各个维度，如时间、人工、物料等方面入手；
5. 相对尺码：主要用于用户故事上；
6. 价值点：交付价值和成果。也只有交付可用的软件，将客户利益最大化，客户才会把尾款付给我们。

---

项目规模测量：通过代码量、时间维度、人力维度、功能复杂性几点考虑。
7. 故事点：是相对测量、相对独立、相互进行对比；
8. 分配故事点要考虑：复杂性、投入量、风险等因素；
故事点估算的步骤：故事应拆分为小的，独立的。每个故事应由1个人不超过两天的时间内完成，否则，就会3. 陷入胶着状态，其代价往往是巨大的。同时团队要达成共识，敏捷是一种思想，需要团队成员转变思想，有一个人员掉线，就会影响行进速度和稳定向。在过程中需要不断的对话、协调、改进（年假、事假等未知因素，往往会影响团队的进度和故事点的完整性）。

---

故事点之类比估算：讲一个故事和其他故事相比，如果故事类似，其精确性、完成时间不能相差太大。同时建议研发团队一起评估，避免一言堂。

1. 理想日：没人任何打扰，所有信息都可用的情况下专注的进行唯一 一项工作；很多企业提倡多面手，即一个人可以做A岗位也可以做B岗位，认为这种就是高效？这是错误的，试想一下，编码10分钟开会1小时，开会想着编码，编码想着准备开会的发言。嘿嘿…代价也蛮高的，奇怪的是很多企业高层选择视而不见，没人向CEO提出这种不良现象。
   2… “编程10分钟，吹水1小时”通过这句玩笑，我们可以看出，研发人员不是机械的工作是创作，就要保持一个相对私密的空间，不受外部的打扰。这里多说几句：”很多初次走上管理岗位的研发兄弟们，往往会犯一个错误，亲自上阵；对各项评估会议不屑一顾，认为是瞎搞。这其实是思维没有转变过来，岗位的高度，决定岗位日常所要工作的重点。管理岗位的重点是规划、协调、避免风险、掌控进度，而不是亲自介入进来开发。用一句话总结：进化成人了，别再用猴子的思维了，你要关注的是一片香蕉林，而不是一两个香蕉的好坏“。

---

故事点和理想日的对比：更有助于驱动跨职能行为（协调资源、答疑等等支持行的工作）；故事点的估算不会衰败：通过不断的对话确定思想统一；故事点特性：挟制了估算时间的增长。后者：有差异，来自团队成员；理想日的不确定性，会使外界认为是靠谱的，事实上即为不靠谱。

估算规模： 敏捷评估建立在合理的预测估算，不应追求100%的精确性。

有以下几种方法：

1. 宽带德尔菲：用来收集项目的准确估算，在会议中只讨论估计是可能会遇到的问题，估计本身和所花的成本不做讨论。会议结束后，团队每个人进行单独的估算，一定要独立，拒绝结对式的估算。组员估算完毕后，收集所有估算，并在画表中画出来，展示差异，进行讨论。需要注意的一点，这是匿名的，即不要展示其姓名，记得有一次，集团做满意度调查，调查卷上还有姓名一栏，结果也如我所料，行政部门收集到的是100%满意。真正的问题反而被遮盖，失去本应起的作用，这是一种浪费。
2. 步骤：团队选择组建成员、启动会议：讲明游戏规则和进行的程序、个人准备、估算会议、配置任务：收集估算单，汇总、任务评审：找出差异，达成共识。
3. 计划扑克：由于本人极度反感扑克和麻将，这里不介绍，自己百度；

---

亲和估算：主要用来进行大规模的估算，优势：快速、简单、决策制定过程透明可见、积极合作而非对抗；

步骤：

1. 沉默的相对尺码：产品负责人提供产品待办事项，排列在墙上，由组员考虑每样物品在执行中所花费的时间、付出的努力。不讨论技术；
2. 编辑墙：根据对尺码达成的一致性，移动尺码；
3. 分类；
4. 产品负责人所面临的挑战：根据估算出来的尺寸，可能不符合产品经理的理想状态。那就需要根据实际情况重新估算或者其他的措施；
5. 储备数据：最后一步，上述一切步骤，都是为一个结果：储备数据；

---

体恤尺码：优点与亲和力的差不多，即团队成员决定每个尺码的基准；L、XL、XXL的基准要统一；

---

计划扑克：不介绍，自己百度；

---

确定项目规模：主要看ProductBacklog中有多少事项，记住一点，ProBacklog动态而非静态的；需要在整个项目的生命周期进行不断的查看、调整；正是由于动态的，由我们确定团队的规模，团队的数量、冲刺的持续时间、版本中的冲刺数量和目标上限；

估算是为了辅助我们的工作，而非KPI\KBI的考核，敏捷宣言中”适应变化而非遵循规范“的特性决定了我们估算所花费的时间成本，尽早的投入研发中才是不二的选择，过多花费估算时间来确定其100%精确性，实际上是一种浪费。