写点什么

计划会议想开好,这两件事必须清楚

  • 2021 年 12 月 08 日
  • 本文字数:2650 字

    阅读完需:约 9 分钟

摘要:一个好的计划会议的标志是什么?开了这么多的计划会,如何知道每次开的好好不好?今天我们就一起来探讨一下这个话题。

 

本文分享自华为云社区《开好计划会议只要搞清楚这两件事》,作者:敏捷的小智。

前言


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

问题分析


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

解决方法

做什么——迭代待办列表


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

产品待办列表


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

• 5 层计划:愿景、产品路线图、发布计划、迭代计划、每日计划

• 4 层计划:产品路线图、发布计划、里程碑计划、迭代计划

• 3 层计划:发布计划、迭代计划和每日计划。


不论是哪一种,计划的顺序都是自上而下,先有上一级,再有下一级。


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

团队速率


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


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


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


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

迭代目标


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

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


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


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



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


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


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



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

计划会议的其他要素

参会人


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

会议时长


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

谁来做——任务领取


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


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

写在最后


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

参考附录


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

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

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


点击关注,第一时间了解华为云新鲜技术~

发布于: 54 分钟前阅读数: 6
用户头像

提供全面深入的云计算技术干货 2020.07.14 加入

华为云开发者社区,提供全面深入的云计算前景分析、丰富的技术干货、程序样例,分享华为云前沿资讯动态,方便开发者快速成长与发展,欢迎提问、互动,多方位了解云计算! 传送门:https://bbs.huaweicloud.com/

评论

发布
暂无评论
计划会议想开好,这两件事必须清楚