Scrum敏捷开发实战(3):开启敏捷流程

0 评论 5047 浏览 30 收藏 14 分钟

一个软件产品的完整开发流程,分为需求确定、产品研发、产品验收、全量测试发布这四个阶段,而Scrum框架为每一个阶段都设定了对应的解决方案。本文作者对Scrum敏捷框架进行了分析,一起来看一下吧。

《Scrum敏捷开发实战》系列:

  1. 方法介绍
  2. 团队组建
  3. 敏捷框架(本章节)
  4. 看板工具
  5. 每日站会
  6. 常见问题

一、完整开发流程

Scrum敏捷开发实战(3):开启敏捷流程

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

  1. 需求确定阶段
  2. 产品研发阶段
  3. 产品验收阶段
  4. 全量测试发布阶段

在实际的开发过程中,为了提高效率,②③是有可能重叠交替进行,Scrum框架为每一个阶段都设定了对应的解决方案。

二、Scrum框架-334

Scrum敏捷开发实战(3):开启敏捷流程

三、完整的Scrum流程

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

3个角色:

  • Product Owner 产品负责人
  • Scrum Master 敏捷教练
  • Scrum Team 开发团队

3个物件:

  • Product Backlog 产品功能列表
  • Sprint Backlog 迭代任务列表
  • 燃尽图

4个仪式:

  • Sprint冲刺计划会
  • 每日站会
  • Sprint冲刺评审会
  • Sprint冲刺回顾会

3个角色我们在上一篇文章《组建敏捷团队》已经详细介绍,本章就不做过多的阐述。

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

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

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

4个仪式贯穿整个敏捷流程,领悟每个会议的作用,将决定整个敏捷开发的质量。

四、Sprint冲刺计划会

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

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

  • Sprint里程碑任务计划表
  • 可测试介入的时间节点、整体开发完成的时间节点、上线时间节点

冲刺计划会要注意几个关键点:

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

1. 任务估算

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

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

2. 任务卡

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

  1. 明确的交付内容
  2. 责任人(可以使用代号,只要不重复即可)
  3. 任务完成时间(可以用小时H或天D作单位)

Scrum敏捷开发实战(3):开启敏捷流程

五、任务卡

敏捷教练SM在和每个人确认任务卡片时,需要注意以下几点:

1)目标一致

做最后确认,确保所有人都清楚本次里程碑的目的和逻辑细节,只有理解了业务细节才能很好的拆解任务卡片,确保不丢失业务逻辑。

2)任务拆解

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

例:我们要画一张原画,正常需要7天,我们可以按照步骤拆解: 找参考(可省略)→ 画草稿 → 画线稿(将草稿清晰化)→ 上色(上底色、上阴影色、上第二层阴影色)→ 加特效(画背景、光影)→ 优化细节 → 完稿。

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

第二个好处是SM每天都知道谁交付了什么,如果没有完成第二天也能及时风控,而不是等几天之后才发现某人完成不了。

3)明确信息

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

例如:

  • 错误:完成接口的开发(不具体)
  • 正确:完成用户注册5个接口开发

4)消除瓶颈

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

如何评估任务估算过长?

  • 里程碑的总时长是否和你预期的相差过长,如果是,和团队表达你的想法,一起寻找瓶颈点
  • 培养自己的直觉,和历史同类任务进行对比进行判断
  • 把握不准的,可以使用同岗位使用扑克牌估时法,找出差异大的估时逻辑
  • 在前几次的里程碑中,观察和评估每个人的工作效率,用于后期对每个人的估时进行判断是否有很大的不饱和情况

那如果有人任务估算过长,应该如何处理呢?我们可以从以下几个角度进行分析解决:

  • 信息缺失:有可能是对所负责的任务还不是很了解,或把解决方案想复杂了,或对项目不熟悉,不知道有些方法已存在,可以直接使用等等,这些都可以通过深度沟通来解决;
  • 任务拆解:尽可能的拆细,查看每一天的任务的工作量是否饱和,直到无法再拆为止,拆到一个点就很容易评估时间;
  • 能力不足:一些新人刚开始可能不知道如何拆解任何和评估,这个时候需要更资深的开发来进行辅导,梳理业务逻辑,输出合理的卡片,辅导2~3次之后即可解决该问题(如果没有资深开发可以考虑招聘一个,一个经验丰富的开发,对于消除瓶颈有极大的帮助)
  • 态度问题:极个别的情况可能是员工的工作态度问题,态度问题很难在会议上进行解决,短期内也不太好解决,这时需要PO使用权威来推进,适当给予压力,日常工作中要进行引导,若发现还是没有改变的迹象,需要考虑替换;

5)打通关联

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

6)交付承诺

任务卡片确认完毕,明确三个时间节点,所有人达成共识,将任务按照优先级展示在看板上,输出里程碑计划表,全体成员承诺交付结果。

六、每日站会

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

所有人围绕在看板周围,每个人轮流上前回答一下三个问题:

  1. 昨天我为团队做了什么?
  2. 今天我将要做什么?
  3. 我需要哪些帮助?

回答完毕之后将已完成的任务移入Test泳道,将今天的任务移入Doing泳道。

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

  1. 固定时间、固定地点,养成习惯,迟到的人要有惩罚
  2. 全员参与、站立开会,保持专注,时长控制在10~15分钟
  3. 三个问题、更新进度,不要讨论技术问题,不要转移会议话题
  4. 注意聆听、回应问题,别人在讲时其他人要注意听,需要帮助时相关人员要及时回应

七、Sprint冲刺评审会

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

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

八、Sprint冲刺回顾会

每一个冲刺会完成后,都会举行一次冲刺回顾会议,在会议上所有团队成员对本次冲刺进行反思,包括:什么进展顺利?缺少什么?需要改变什么等等。

冲刺回顾会是针对迭代末期进行的时间盒会议,目的是帮助团队如何提高他们的工作效率和改进工作方式,就未来的迭代改进计划达成一致;同时梳理以往的项目缺陷和债务,对用户故事进行审视,是否需要新增、删除、修改用户故事,对用户故事进行优先级排序。

需要注意的是,让团队自己反思,PO尽量不参加,或者参加也尽量少说话,反思时要找出明确的问题和意见,不要情绪化,切勿开成批斗会。

Scrum敏捷流程让在早期发现可能的问题,可以用更快更小损失应对问题,“没有问题被扫入地毯下”,Scrum鼓励每个团队成员清楚的描述自己所遇到的困难,其他成员积极的响应解决,降低项目风险,SM必须有预警风控能力,能判断出可能的延迟或者偏差。

敏捷之路,不可能一帆风顺,团队只有在不断遇到问题解决问题才能快速成长。

作者:周武,曾就职于腾讯、边锋,现在一家上市公司产品负责人;公众号:周武说。

本文由@ 周武 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!