如何可视化需求状态和团队状态?

朝阳问

我们团队在实践 Scrum,每两周一个 Sprint,一个 Sprint 有 100 多个需求。
我们把几十名技术人员,按前端、测试等不同职能,划分为多个3-10人的小团队。然后围绕业务,按职能矩阵的方式,组成了几个 Scrum 团队。每个 Scrum 团队同时负责多款产品。
现在遇到的困难是,需求管理、团队管理的成本都很高,整个大团队的进展没办法直观、及时获取到。
去年年初尝试过使用精益看板,但是大家不愿意抄写那么多用户故事,也为了统计方便,就改为使用 JIRA 来管理,但又引入了更新 issue 状态不及时问题。现在完全无法直观看到全局进展,仅靠 Sprint 结束之后的数据统计,来判断这个 Sprint 是否有进步。我也想尝试 Scrum of Scrums 的方式,但是能获取到的资料有限。这些问题不解决,就会制约团队扩大规模。我也经常在想是不是我们哪里做错了,小波有什么建议吗?

小波老嬉答

如何及时直观地了解需求状态和团队状态?
需求状态包括:什么时间交付哪些特性,哪些已经完成了,哪些正在开发中,哪些被阻塞了等。
团队状态包括:谁在做什么事,哪个环节是瓶颈,谁被卡住了需要帮助等。

这个话题涉及 Scrum 的五个价值观之一「开放」,开放包括组织层面的开放和个人层面的开放。
组织层面,将所有的信息可视化出来,包括用户需求,干系人期望,交付计划,项目进度,用户反馈等。打造一个「信息化工作场所」,任何人走入这个场所都可以快速获取到想要的信息。
个人层面,开放地学习新的实践,接纳他人的反馈等。

如何可视化需求状态?
在实施 Scrum 时我们通常会用「用户故事 User Story」来描述产品需求,用「产品待办列表 Product Backlog」来组织「用户故事」。可是,在一个个迭代中,不断地完成一些需求,又新增一些需求,日复一日,好像没有尽头。
另外由于产品待办列表是个一维的列表,也难以直观地呈现产品的全局状态。


Jeff Patton 提出了一个实践:用户故事地图 User Story Mapping。它可以很好地在需求拆分的过程中保持需求的全景,并且用二维地图的形式呈现多样的信息。比如通过贴绿色的便签表示已完成,贴红色的便签表示被阻塞。

如何可视化团队状态?
我们可以用状态墙可视化项目状态,物理的或电子的都可以。

通过在需求卡片上贴头像的方式,可以直观地显示谁在做什么事。通过设置 WIP Limit,可以直观地显示出团队的瓶颈。想知道谁被阻塞了,可以增加一个 Block 的状态来表示。总之,你可以通过自定义来扩展状态墙呈现的信息。
但是,不管用物理墙还是电子墙,都可能会遇到状态更新不及时的问题。怎么解决呢?
从机制上,在站会前或站会中更新状态墙,起码可以保证状态墙能按天的节奏更新。
但更重要的是要找出为什么大家不愿更新状态?是不是没有动机?为什么不能坚持更新?是不是没有动力?
换位思考一下,做了这个事对我没什么好处,不做这个事对我没什么坏处,那我为什么要做呢?
我们帮助团队养成一个新的习性,就要去给他们安上动机和动力,减少执行中的障碍。对及时更新的成员给予正向反馈,对不及时更新的成员给予负向的反馈。

说完了组织层面的开放,来说说个人层面的开放。
作为敏捷的导入者,要以身作则地展示自己的开放。倾听,接纳,换位思考,不要把团队成员当成一个整体,而是真正去关心每一个独特的「人」。通过一对一教练,引导,辅导帮助成员理解、认同、适应新的习惯。

总结
我们可以用「用户故事地图」和「项目状态墙」来可视化需求状态和团队状态。
引入一个实践时,给团队讲清楚这个实践的价值,达成团队共识,约定不执行的惩罚措施(比如请所有人喝酸奶),在回顾会议中讨论是保留,改进还是放弃。
人有「从众心理」,都希望自己是合群的,因为做大多数更有安全感,所以达成团队共识很重要。达成共识后,要注意「破窗理论」,一旦有人执行不力,要立即严肃处理,不然其他人就会效仿。如果个别人总是出现问题,那就要跟他单独沟通,尝试去理解他,帮助他理解实践的价值,如果实在不行,恩威并施,争取让他在行为上与团队保持一致。