开好计划会议只要搞清楚这两件事

敏捷江湖桃花岛梅师姐 发表于 2021/12/10 16:47:27 2021/12/10
【摘要】 作计划这个事我们从小到大都进行,现在也需要经常作计划,学习计划,读书计划,出行计划,攒钱计划,购房计划,脱单计划,恋爱计划,成长计划……等等,这些都是和个人相关的,计划其实主要解决两个事:做什么和如何做。同样到敏捷中的计划会议也是一样,会议的核心就是解决这个Sprint做什么以及如何做的问题。所以要是把这两个事说明白,就可以认为是一个成功的计划会议。

前言

2001年敏捷宣言诞生到现在,敏捷已经走过了20个年头,越来越多的团队采用了敏捷软件开发模式,其中作为框架指导的Scrum方法应用最广,Sprint计划会议作为核心的事件成为敏捷开发中必不可少的一个环节。众多团队在每个迭代开始都会召开计划会议,可是经常出现“开始计划特别好,结果交付乱糟糟”,在一次敏捷线上分享活动中,就有开发者提出一个疑问:一个好的计划会议的标志是什么?开了这么多的计划会,如何知道每次开的好好不好?今天我们就一起来探讨一下这个话题。

问题分析

作计划这个事我们从小到大都进行,现在也需要经常作计划,学习计划,读书计划,出行计划,攒钱计划,购房计划,脱单计划,恋爱计划,成长计划……等等,这些都是和个人相关的,计划其实主要解决两个事:做什么和如何做。同样到敏捷中的计划会议也是一样,会议的核心就是解决这个Sprint做什么以及如何做的问题。所以要是把这两个事说明白,就可以认为是一个成功的计划会议。这样问题就聚焦到把做什么和如何做这两件事情说明白

解决方法

做什么——迭代待办列表

确定做什么的过程,就是形成迭代待办列表的过程。通常一个迭代是两周,在计划会议中确定团队接下来的两周做什么任务,这里面有三个核心内容:产品待办列表、团队速率和迭代目标。

产品待办列表

在敏捷开发中计划是分层进行的,不同的团队会对环节进行删减和个性化设置,常见的分层计划形式有:

  • 5层计划:愿景、产品路线图、发布计划、迭代计划、每日计划
  • 4层计划:产品路线图、发布计划、里程碑计划、迭代计划
  • 3层计划:发布计划、迭代计划和每日计划。

不论是哪一种,计划的顺序都是自上而下,先有上一级,再有下一级。更多关于敏捷计划的相关内容可以参考《关于敏捷规划你需要知道的几件事》

所以在我们的迭代计划会议之前,首先要有一个发布计划,形成一个根据发布计划、按照优先级顺序排列好的产品待办列表。作为会议的任务输入项才能确定接下来这个迭代做什么。

关于产品待办列表的更多内容,可以参考《规划与设计—产品待办列表

团队速率

团队速率简单来说就是团队在一个迭代中能够完成多少任务,也就是团队的生产能力。常用的表示有两种方法。

一种是采用故事点数。比如:某Scrum团队1个迭代可以完成 30个故事点,那么30个点就是他们的速度;通常这个数值是默认等于最近一次迭代中的速度,BeckFowler称为昨日天气法。有些团队还喜欢使用平均值的方法,可能是过去3次迭代的平均值。如果是新的团队或者没有历史迭代就需要他们预计自己的速度。

另一种是采用工时描述。比如:团队7个人,每个人可用于工作的时间在70%,其他30%用于迭代之外的工作和缓冲(支撑其他团队、会议、回复邮件等),这样团队在两周的迭代中可用的工时就是 7*8*10*70%=392小时,其中还要如果有请假等不能工作的情况要从可用工时中减去。

如果采用故事点数,就是和产品待办列表的单位对齐;采用工时,就是和迭代待办列表中的任务相同。两种方法团队都可以尝试使用,最后选择适合自己的方法。

迭代目标

除了产品待办列表和团队速率两项内容还有一个重要的信息,就是迭代目标。迭代目标通常由产品负责人PO根据业务的情况去确定。团队基于这个目标,按照团队的速度,从产品待办列表中选择适当的条目形成迭代待办列表。

如何做——故事分解为任务

得到了迭代待办列表之后,列表中的条目都是故事的形式,通常代表产品的某个功能或者特性,如何将这些特性实现,接下来需要拆解为具体的任务,由团队在迭代内完成交付。

比如:迭代中有个故事为“作为管理员应该可以进行积分管理”,这个是从用户的角度去描述。开发团队实现这个功能,就需要分解为团队可以理解的任务描述形式:积分功能业务逻辑开发、积分功能数据库设计和实现、积分规则设计。如下图所示。

111.png

在拆分任务的时候,任务的颗粒度可以参考在1天(8小时)内完成,这样可以保证在每日站会的的时候大家都有进展可以汇报,避免积压出现瓶颈。

分解为任务之后,团队可以对每个任务进行再次估算,得到这个迭代要完成任务的估算总和,将它和团队的生产能力进行比较,了解当初的承诺是否合适,可以进行调整,避免承诺不足或者过度承诺。

在计划会议上搞清楚本次迭代团队需要完成哪些故事,以及如何完成这些特性,基本上这个会议就是一个成功的会议,过程图如下所示。

222.png

除了上面两个核心的问题,计划会议还有其他的一些要素需要关注下。

计划会议的其他要素

参会人

建议整个项目团队(产品负责人、开发人员、测试人员、UI设计师等)和干系人(客户、项目发起人、职能经理等)都参加计划会议,这样可以让大家项目的进展和团队当前正在完成的工作有所了解。通常干系人时间有限,可以只参加确定做什么这个阶段,后面的如何做阶段保证团队成员都参加即可。

会议时长

在敏捷中的各种会议都有一个可参考的时间盒,基于团队的规模和迭代的长度。5-9人的团队、长度为2周的迭代中,计划会议时长通常在4个小时以内。

谁来做——任务领取

前面解决了做什么和如何做这两个问题,下一个问题就是谁来做。在敏捷中提倡团队成员主动领取任务,而不是被动的等待分配任务。从心理学的角度上,主动领取代表着一种承诺,会增加成员的仪式感和责任感。关于领取任务的时机,可以在计划会议上领取,也可以在迭代中即时领取1-2项,做完手中任务再去领取新的任务。

这两种方法团队都可以尝试,选择适合自己团队的方式。通常建议采用后面的方式,因为计划会议是团队对本次迭代的内容共同进行承诺的一个过程,敏捷强调团队共同责任制,而这时候领取任务就会变成个人负责制,弱化了团队对任务的所有权。还有在迭代过程中也会有一些意外情况导致任务的重新分配,所以不建议计划会议上领取任务,包干到个人。

写在最后

敏捷方法旨在管理不确定性,这里的不确定性是指与目的(客户的目标和需求)相关的不确定性和与手段(技术和人)相关的不确定性。敏捷方法用来应对不确定性的一个方法是,基于在迭代开发中获得的进展和收集到的新信息,进行频繁的重新计划。所以在前面的分层计划中可以看到迭代计划之后还有每日计划,迭代计划不是一劳永逸的,在迭代过程中要根据情况实时调整,调整的核心是聚焦于迭代目标的实现,交付有价值的产品。

参考附录

1.Scrum精髓:敏捷转型指南.Kenneth S. Rubin.北京:清华大学出版社,2014

2.敏捷软件开发实践:估算与计划. Mike Cohn. 北京:清华大学出版社,2016

3.敏捷项目管理:快速交付创新产品(2) .Jim Highsmith. 北京:电子工业出版社,2019.11

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区),文章链接,文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:cloudbbs@huaweicloud.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。