2023年Scrum敏捷开发实战（3）：开启敏捷流程-1

Scrum敏捷开发实战（3）：开启敏捷流程《Scrum灵敏开发实战》系列：

方法介绍团队组建灵敏框架（本章节）看板工具每日站会常见问题一、完整开发流程

一个软件产品的完整开发流程分为4个部分，分别是：

需求确定阶段产品研发阶段产品验收阶段全量测试发布阶段在实际的开发过程中，为了提高效率，②③是有可能重叠交替进行，Scrum框架为每一个阶段都设定了对应的解决方案。

二、Scrum框架-334

三、完整的Scrum流程

完整的Scrum流程包含了3个角色、3个物件，以及4个会议；

3个角色：

ProductOwner产品负责人ScrumMaster灵敏教练ScrumTeam开发团队3个物件：

ProductBacklog产品功能列表SprintBacklog迭代任务列表燃尽图4个仪式：

Sprint冲刺方案会每日站会Sprint冲刺评审会Sprint冲刺回顾会3个角色我们在上一篇文章（《组建灵敏团队》）已经具体介绍，本章就不做过多的阐述。

3个物件属于灵敏工具，会使用即可，其中“产品功能列表”由产品负责人维护，然后进行优先级排序，以用户故事的形式展现，能够让团队成员简单理解。

“迭代任务列表”是当前冲刺迭代版本的任务集，由产品将用户故事拆成任务，并让团队成员各自领取。

“燃尽图”则是一个公开的图表，是项目进度的一种看板表现形式，有助于项目成员能够直观的理解项目进展，直到全部任务开发完毕。

4个仪式贯穿整个灵敏流程，领悟每个会议的作用，将打算整个灵敏开发的质量。

四、Sprint冲刺方案会

每个冲刺版本都由一个Sprint冲刺方案会开头，产品负责人PO或团队成员选择用户故事，然后由产品负责人具体讲解用户故事，产品经理负责讲解满意用户故事的产品功能解决方案，开发团队进行任务估算。

冲刺会最终产出1张表和3个时间节点：

Sprint里程碑任务方案表可测试介入的时间节点、整体开发完成的时间节点、上线时间节点冲刺方案会要留意几个关键点：

一个Sprint的周期不宜过长，掌握在4周内，而且以2周为佳每次会议全员必需参与，每个人都要清晰本次版本的目标，我们能交付什么，明确各自的职责和责任全员承诺，PO不死压完不成的任务量任务估算时可以讨价还价，但一旦接受则全部人都要对里程碑nodelay，做到当日事当日毕尽量不要压缩测试的时间在任务进度表没有出来之前，不要中断会议1.任务估算

任务估算是冲刺方案会中最重要的一个环节，只有理解了本次会议的需求内容，才能估算出精确     的时间，确保里程碑的进度可控，SM要在这个环节把控全局，确认好里程碑的时间节点。

假如团队内岗位都不相同，团队成员分别编写自己的任务卡，而假如有相同的岗位，应当以小组的形式来估时，比如一个团队中有2个后端，那他们就要对本次里程碑的全部任务都进行估时（可参考扑克牌估算法），双结果不同需要争论并重新出牌，结果比较接近即结束。

2.任务卡

一张完整的任务卡要包含三个内容：

明确的交付内容责任人（可以使用，只要不重复即可）任务完成时间（可以用小时H或天D作单位）

五、任务卡

灵敏教练SM在和每个人确认任务卡片时，需要留意以下几点：

1）目标全都

做最终确认，确保全部人都清晰本次里程碑的目的和规律细节，只有理解了业务细节才能很好的拆解任务卡片，确保不丢失业务规律。

2）任务拆解

单个任务1天为最佳，最多不能超过2天，绝大多数的任务都是可以拆解的，许多人无法拆解是没有把握正确的拆解方法，我们可以根据页面数量、接口数量、制作步骤等方法进行拆解。

例：我们要画一张原画，正常需要7天，我们可以根据步骤拆解：找参考（可省略）→画草稿→画线稿（将草稿清楚化）→上色（上底色、上阴影色、上其次层阴影色）→加特效（画背景、光影）→优化细节→完稿。

拆解到人天的好处就是让每个人都知道每天要完成什么内容，工作目标清楚透亮     ，验收时只有两个结果是和否，不存在模糊不清的进度（比如完成30%这种），既让成员有肯定压力，也能够有效的削减工作不饱和的状况。

其次个好处是SM每天都知道谁交付了什么，假如没有完成其次天也能准时风控，而不是等几天之后才发觉某人完成不了。

3）明确信息

任务卡片里的内容要清楚精确     ，要有量化的内容，不能用模糊不清的概念，SM要能够理解每个卡片上交付的内容，假如不理解需要让成员修改，并检查每个人卡片上三要素是否齐全。

例如：

错误：完成接口的开发（不详细）正确：完成用户注册5个接口开发4）消退瓶颈

检查卡片时需要关注是否包含了全部的需求，是否有估算时长与预期、或和以往类似功能时间严峻不符的任务卡片，单人的任务时间是否过长，评估整体里程碑时长是否过长。

如何评估任务估算过长？

里程碑的总时长是否和你预期的相差过长，假如是，和团队表达你的想法，一起查找瓶颈点培育自己的直觉，和历史同类任务进行对比进行推断把握不准的，可以使用同岗位使用扑克牌估时法，找出差异大的估时规律在前几次的里程碑中，观看和评估每个人的工作效率，用于后期对每个人的估时进行推断是否有很大的不饱和状况那假如有人任务估算过长，应当如何处理呢？我们可以从以下几个角度进行分析解决：

信息缺失：有可能是对所负责的任务还不是很了解，或把解决方案想简单了，或对项目不熟识，不知道有些方法已存在，可以直接使用等等，这些都可以通过深度沟通来解决；任务拆解：尽可能的拆细，查看每一天的任务的工作量是否饱和，直到无法再拆为止，拆到一个点就很简单评估时间；力量不足：一些新人刚开头可能不知道如何拆解任何和评估，这个时候需要更资深的开发来进行辅导，梳理业务规律，输出合理的卡片，辅导2~3次之后即可解决该问题（假如没有资深开发可以考虑聘请一个，一个阅历丰富的开发，对于消退瓶颈有极大的关心）态度问题：极个别的状况可能是员工的工作态度问题，态度问题很难在会议上进行解决，短期内也不太好解决，这时需要PO使用权威来推动，适当赐予压力，日常工作中要进行引导，若发觉还是没有转变的迹象，需要考虑替换；5）打通关联

SM需要全局观看每个人的任务排序和时间，观看上下游任务连接状况，合理调整挨次，确保任务的连贯性，尽早的交付可供测试的软件。

6）交付承诺

任务卡片确认完毕，明确三个时间节点，全部人达成共识，将任务根据优先级展现在看板上，输出里程碑方案表，全体成员承诺交付结果。

六、每日站会

里程碑确定之后，通过每日站会来推动项目进度，由SM发起，全体成员参与，PO和其他需求方选择性参与（但只参加、不说话），每日站会是快速专注的会议，用来共享进度和迭代看板进展，每个团队成员就他们将要完成的任务对其他人口头承诺。

全部人围绕在看板四周，每个人轮番上前回答一下三个问题：

昨天我为团队做了什么？今日我将要做什么？我需要哪些关心？回答完毕之后将已完成的任务移入Test泳道，将今日的任务移入Doing泳道。

一个有效的站会需要做到以下原则：

固定时间、固定地点，养成习惯，迟到的人要有惩处全员参加、站立开会，保持专注，时长掌握在10~15分钟三个问题、更新进度，不要争论技术问题，不要转移会议话题留意倾听、回应问题，别人在讲时其他人要留意听，需要关心时相关人员要准时回应七、Sprint冲刺评审会

在开发完毕后，即将交付上线之前，由SM发起，全体成员参与，开发团队将可交付物演示给需求方，需要方进行功能评审，收集反馈看法。

评审会并不是必需的，但Scrum团队要常常和需求方保持信息互通，确保接受到最新的市场动态和用户反馈，交付的产品满意利益相关者的期望，让团队的产出有价值。

八、Sprint冲刺回顾会

每一个冲刺会完成后，都会进行一次冲刺回顾会议，在会议上全部团队成员对本次冲刺进行反思，包括：什么进展顺当？缺少什么？需要转变什么等等。

冲刺回顾会是针对迭代末期进行的时间盒会议，目的是关心团队如何提高他们的工作效率和改进工作方式，就将来的迭代改进方案达成全都；同时梳理以往的项目缺陷和债务，对用户故事进行端详，是否需要新增、删除、修改用户故事，对用户故事进行优先级排序。

需要留意的是，让团队自己反思，PO尽量不参与，或者参与也尽量少说话，反思时要找出明确的问题