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

朝阳问

我们团队在实践 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 的状态来表示。总之，你可以通过自定义来扩展状态墙呈现的信息。

但是，不管用物理墙还是电子墙，都可能会遇到状态更新不及时的问题。怎么解决呢？

从机制上，在站会前或站会中更新状态墙，起码可以保证状态墙能按天的节奏更新。

但更重要的是要找出为什么大家不愿更新状态？是不是没有动机？为什么不能坚持更新？是不是没有动力？

换位思考一下，做了这个事对我没什么好处，不做这个事对我没什么坏处，那我为什么要做呢？

我们帮助团队养成一个新的习性，就要去给他们安上动机和动力，减少执行中的障碍。对及时更新的成员给予正向反馈，对不及时更新的成员给予负向的反馈。

说完了组织层面的开放，来说说个人层面的开放。

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

总结

我们可以用「用户故事地图」和「项目状态墙」来可视化需求状态和团队状态。

引入一个实践时，给团队讲清楚这个实践的价值，达成团队共识，约定不执行的惩罚措施（比如请所有人喝酸奶），在回顾会议中讨论是保留，改进还是放弃。

人有「从众心理」，都希望自己是合群的，因为做大多数更有安全感，所以达成团队共识很重要。达成共识后，要注意「破窗理论」，一旦有人执行不力，要立即严肃处理，不然其他人就会效仿。如果个别人总是出现问题，那就要跟他单独沟通，尝试去理解他，帮助他理解实践的价值，如果实在不行，恩威并施，争取让他在行为上与团队保持一致。