考察一个敏捷团队的研发效能，通过参加站会就能观察出来。
很多教材描述的站会内容就是 Scrum master 问团队成员昨天做了什么，今天准备做什么，遇到了什么问题没有？而且时间越短越好，时间应该控制在15分钟以内。这样的询问，Scrum master最关心的是团队成员的利用率，基本思想是不能有人闲着，似乎只要没人闲着，事情就会有进展。
为什么很多 Scrum Master 只关注团队成员利用率呢？因为简单。问问谁都在干什么，不需要了解客户想要什么，也不用关心产品经理的需求优先级列表，也就是不用关心业务本身。这样天天开站会的结果就是让团队成员没有聚焦在完成交付上，只要能表明自己很忙就行了。
如果你是客户，你会关心团队成员每天都忙不忙吗？客户关心的问题是事情的进展，做完了哪些事情？什么时候能够交付？简而言之，客户关心的是价值的流转效率，也就是按照现在的交付速度，对比需求列表，什么时候能够完成交付。其实不仅仅是客户，团队之外的群体也关心价值流转效率高过团队成员的利用率，比如团队向公司高层领导的汇报内容就是哪些功能已经完成了，是不是能够按时交付。
既然价值流转效率的重要性高于人员的利用率，那么在团队的站会上就应该围绕如何尽快完成计划的用户故事（功能点）而展开，其次才是每个人的工作是否饱满。Scrum master应该按照下面的顺序在站会上提出问题：
- 排在最前面的用户故事今天能做完吗？
- 如果做不完，这个用户故事下的子任务有完成了的吗？
- 还需要什么帮助才能保证这个用户故事能尽早完成？
- 已经完成了手头上的任务的团队成员是否可以帮助完成这个用户故事？
如何才能提高价值流转效率呢？
首先产品经理应该按照交付的优先级给需求列表排序，对于敏捷团队而言需求都是写成为用户故事的，也就是产品经理应该给用户故事列表排出优先级。敏捷团队按照优先级根据人员的工作负荷 (capacity) 确认本次迭代可以完成的用户故事列表，排在最前面的优先完成。Scrum Master 应该控制好同时进入开发的用户故事数，一般不要超过 3 个。跟打仗一样应该集中兵力消灭敌人，步步为营，切忌把战线拉得太长！
Little’s Law 也证明了只有减少队列长度才能降低平均等待时间，所以在站会上 Scrum Master 要慎重决定是否开始新的用户故事的工作。Scrum Master 在反思会上可以和团队一起关注 Cycle Time，也就是每个需求从开始进入研发到完成的时间。
如何在关注价值流转效率的同时提高人员利用率
可能有人会问只关注价值流转效率，减少同时进行的项目，那么有些工作其他成员干不了闲下来了，岂不是增加了项目交付的成本？这里就涉及到敏捷团队的自组织性问题。作为研发负责人的你，应该减少微观管理，让团队成员形成自我驱动力，自觉补位。当团队成员完成了手上的工作时，他们应该看看团队中还有哪些正在进行的工作，主动加入进去帮助完成这些工作，帮助团队提高交付效率。
Scrum Master 在站会上可以询问有没有团队成员可以帮助完成正在进行的工作，培养团队的自组织文化，记录好每个人在每项任务上花的时间，在反思会上可以和团队一起看看人员的利用率。**提高团队成员利用率的核心要素是团队成员自己提高自己的利用率，呈现自己的价值，而不是等待任务。**因为人是可以学习的，只要团队成员积极主动，就能承担更多种类的任务。虽然在短期可能会看到完成某项任务多花了些时间，但是长期看，整个团队因为密切配合，减少了因为等待而产生的浪费，价值流转效率和人员利用率会同时得到提高。
结论
本文提出敏捷团队应该以价值流转效率为重点，兼顾团队成员的利用率。价值流转效率决定了敏捷团队的交付速度和整体研发效能，而团队成员的利用率是团队成员自己应该考虑的问题，因为这是团队成员自我价值的实现方式。
3898
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
