《敏捷估计与规划》

Posted 2023-04-22

参考技术A 一、为什么要读这本书？

    去年在负责IT服务流程管理产品过程中，发现如果客户主动要求项目的发布日期和内容罗列清晰，团队的目标感、时间紧迫性会比较好；如果项目不紧急，产品的需求不是客户提出的（可能是领导提出的规划等等），团队整体感觉会有些松散，每周的成果不明显，或者新的需求内容经常做的不完整，整体效率不是很高；

     1. 期望能给团队每周明确的目标；

     2. 期望能帮助团队规划好阶段性任务；

     3. 期望能更好的把控项目周期进度；

二、通过读这本书想要获取什么？

     1. 什么是敏捷开发？敏捷的含义是周期短，还是任务划分细致明确？

     2. 敏捷开发的过程是什么样的？

     3. 敏捷开发中需要协调哪些资源？如何进行协调？

     4. 敏捷开发过程中如何把握控制任务的颗粒度？

     5. 一个周期的目标如何确定？时间范围控制在多久？​

     6. 多个项目并行的时候，如何进行敏捷规划？

     7. 敏捷开发过程中，成果如何检验？

     8. 在敏捷开发过程中，多个敏捷过程后会不会造成团队人员压力过大？如何进行调节？

1. “大多数项目所面临的最关键的风险是开发出错误的产品”--------所以做产品的过程是时刻需要有批判性思维，在一个项目开始阶段，应该审视识别需求，哪些是关键重要、最核心的？其实感觉无论做什么都是这个道理，为什么要做这件事？做了以后有什么意义？

2. 计划不是一成不变的，需求也不是一直不变的，其实是时刻根据当下的情况、当下的理解，不停去调整、校验纠正的过程。首先识别前期比较重要的几个目标，然后去着手做，然后慢慢去拓展、深入到整个产品或项目中，不断将目标具化，将需求细化成最符合用户需求的。

3. 敏捷开发的目标、成果的校验，不是功能的完成，而是功能对客户的价值，就是你这个敏捷周期里面做的功能是不是客户需要的，做好的成果要及时给客户体检，进行改进。

1. 基于活动而不是基于功能进行规划；

活动的规划客户不能从中获得价值，功能才是客户价值的计量单位；基于活动的规划导致超期的原因包括：

（1）“活动不会提前完成”-----产品经理在和开发团队沟通计划的时候，比如1天可以完成，规划给了3天时间，那么往往最快都是3天才会完成，很少会主动把进度提前；（帕金森定律）

（2）“延误随进度表传递”-----开发任务中间大部分关联性都是很强，比如A做完某个功能后，B才能刚开始做，如果A延误了，那么后面整个相关的B、C、D等等都会有延误的风险。

（3）活动不是独立的；

2. 多任务处理导致更多的延迟；

一个人同时处理的任务越多，反而会效率更差一些，给开发团队的任务应尽量独立，按模块或功能划分，跨度不能太大；

3. 不按优先级开发功能；

规划的任务应该包含优先级，并且让每个成员认识到最核心价值的任务，优先来处理对客户或者用户最有价值的功能；

4. 忽视了不确定性；

在项目初期，计划是不可能具体到明确的日期的，我们要承认这种不确定性，可以划定一个结束的日期范围，随着项目的进展，不确定性和风险会逐渐减少，然后在做更为精准的估计；

5. 把估计当成承诺；（很多管理和开发之间的矛盾冲突经常有这个）

实际过程中，让开发去估计一个任务的日期，尤其很多他们不熟悉没有遇到的技术，其实是很难估计的，我们不应该强制去要求，他们往往会给我们大致的时间，但是我们不能把这个估计时间当做他们的承诺时间。

☆☆总体读完后，对我最有帮助的是：

1. 给开发的任务应该尽量明确、独立，可以保持在2-3个，尽量不要多任务处理，尤其是业务跨度大的，这样风险很大；

2. 开发经常口头给出的时间是预估的，不能当做是承诺，因为他们没有对详细的需求、要求了解透彻，所以应当给他们仔细评估的机会。

（1）帕金森定律：工作总是要拖到最后一刻才完成；

1. 开发任务的关联怎么建立呢？我们内部的办公软件，如何定义这个规则呢？

“寻求客户合作的价值重于对合同的谈判”—应该将项目关联所有人员都朝着共同的目标努力，开发小组和客户面对项目的时候，能够以与之相同的合作态度朝共同目标前进，最终目标是向项目客户和用户交付尽可能多的价值。（以往的项目过程中，很容易项目客户和开发之间互相埋怨，针锋相对，作为项目管理人员，应尽量引导双方建立共同的目标。）

项目取得成功的关键在于：所有项目参与者都把自己看作朝向一个共同目标前进团队的一员，在敏捷开发小组内，建立“我们一起参与其中”的思想，避免“扔过去不管”的心理状态；敏捷小组一般包含的角色有：产品使用者、客户、开发团队、项目经理等；

（1）敏捷开发小组大多采用2~4周的迭代，迭代受时间限制，即使要放弃一些功能，也必须按时结束迭代。

（2）每次迭代开发的内容要尽可能达到交付、发布的质量，每次迭代结束的时候让产品达到潜在可交付状态非常重要，可以多个迭代后整体发布。

（3）每次迭代要确定任务的优先级别，并且及时的对计划进行检查和调整。

敏捷规划方法：   

  一、规划洋葱模型依次是：战略、资产、产品、发布、迭代、当前日，开发小组只关心3个层次：发布、迭代、当前日，按照这3个层次进行规划。

（1）发布：确定主题；

（2）迭代：产品经理需确定每次迭代的内容和优先级；

（3）每日例会：可对每天的工作进行协调和同步；（不能照搬，可以根据自己团队的情况制定周期，保持大家经常沟通，确定认知一致即可）

另外3个层次：产品规划要求产品所有者超越本次发布以外，为已发布的产品和系统的发展做出规划。资产规划则是选择合适的产品，来最好地实现公司的战略规划所确定的远景。（ 这项工作作为产品经理要额外关注，锻炼和提升此方面的能力，这是高级产品经理进阶的必备 ）

二、满意条件

在发布规划的时候，明确产品上线的满意度条件（要达到什么样的目标、效果）；

第3章 第二部分 规模估计

根据发布或迭代的功能表，推算出规模，从而推算出要花多少时间完成，从而细化为进度计划表。 （我之前的工作中，如果有改进调整的需求方案，我会和开发沟通好需求，同时协商制定好计划的上线时间，然后每周出一个发布计划列表，将成果及时发布给用户使用，但是之前没有把这个过程当做是一个敏捷的迭代，在迭代功能的完整性上面考虑的还不够）

在预估迭代所需的工作量后，排期时应注意，比如每天7小时上吧，开发可能处理工作的时间只有6个小时，另外1个小时，可能会被各种会议、临时的各种安排打乱，所以在排期时要考虑到对这些干扰的时间进行排除，对上线的目标日期进行延长。

阐述的“ 规划扑克 ”方法非常好，适用于团队合作的初期，可以利用几次这样的机会，召开会议，讲解迭代的功能需求，让开发小组对迭代的功能列表所用工期进行分别估计，然后查看大家的估值差异，每次让估值最高和最低的人来说明估值理由，对不明确的需求进行进一步沟通，经过多轮后，大家都工期的估值会逐渐接近； 【这里方法不是很详细，具体可以查看书中的描述】

（1）每个敏捷小组人数最好控制在10以内，如果团队人数比较多，可以划分为多个敏捷小组；

（2）每个敏捷迭代的功能所耗费工作量，换算排期后，最好控制在10个工作日左右；如果超出太多，可以减少迭代的功能列表，重新预估；

敏捷精髓：Scrum的规划原则

Scrum的规划原则

概念

    有一种谬论的观点认为：Scrum不需要做规划，只要一开始第一个冲刺，就能弄清所有的细节。

事实并非如此，在Scrum中，我们也制定计划，会在不同时间点制定细节程度不同的计划，与传统开发团队相比，Scrum团队通常花更多时间做规划。