北京
冲刺结束前三天，经理发来一条消息，问我是不是还在参与这个项目。
那个冲刺周期里，我一直在做认证服务。测试用例写完了，合并请求经过评审、修改、合并。我还跟质量保障同事做了一次走查，把需要留意的边界情况都过了一遍。那段时间我埋头干活，产出是实打实的。
但看板上，我的名字只挂在一张未关闭的工单上。
认证相关的用户故事被移到“测试中”，指派给了质量保障同事。一个缺陷修复在评审阶段被质量保障负责人发现后，关闭时挂的是对方的名字。我还带着一个初级开发做了一次调试，但那次调试从头到尾没有建过工单。看板上呈现出来的样子，就像我这个冲刺几乎没碰过项目。
没有人做错什么。质量保障同事按流程走，经理回应了利益相关方提出的真实问题，系统也完全按照设计的方式运转。
这个系统在设计时就没有考虑过工作移交之后开发者的可见性。
这是混合型“敏捷—瀑布”团队里相当常见的一种模式。冲刺看板跟踪的是用户故事的状态，不是开发者的实际贡献。你的工作一旦移交到质量保障环节，名字就从工单上消失了。工单要么挂在别人名下关闭，要么在测试队列里躺上好几天。冲刺进行到一半，看板显示你处于空闲状态，而你恰恰在做最有价值的那部分工作。
解决办法是结构性的，不是态度问题。
在写第一行代码之前，先在父级用户故事下面建一个开发子任务，指派给自己。把合并请求和评审记录都关联到这个子任务上。父级工单移到质量保障环节时，子任务仍然挂在你的名下。等有人问你这次冲刺交付了什么，点一下就能回答。
每个用户故事大约多花两分钟。它不会改变质量保障的工作流程，但能让你的工作对任何查看看板的人都清晰可读——包括你经理的经理，他们看到的仪表盘汇总，可能你根本不知道他们也在看。
我试过的每个团队反应都一样：先是好奇，然后是轻微的懊恼，觉得怎么没人早点这么做。
大多数企业敏捷团队里的可见性问题，不是绩效问题，而是信息架构问题。团队在构建软件，但工作流是为跟踪工单设计的。
这两件事不是一回事。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
