人人都是Scrum Master：对于Scrum团队，PM应该从何下手

如何跟踪项目进展，了解团队生产率，分析千行代码缺陷率等，相信对于一个PM来说，PV, EV, SV, CV, Defect Density等这些概念都是烂熟于胸的，然而对于Scrum的PM，面临的困境是，项目开始的时候，要开发的产品没有明确的需求和时间轴，手头拿到的只是一个High Level的Product Backlog，PM甚至不知道6个月后这个Backlog会不会面目全非。显然，传统的管理方式是很难让人客观了解项目的进展并评价项目。为了客观评价一个Scrum团队的承载力和效率，点融黑帮今天给大家提供几个容易上手的度量标准和追踪的方法，简单快速帮助大家评价和管理一个Scrum团队。

Velocity （已经完成的故事点！）

好吧，我们说的是在一个Sprint中已经彻底完成的故事点，没有Defect，不是部分完成的，而是真正的已经把User Stories转化为已经生产运行的软件的大小（点数）。

什么？已经被解决的Defect算不算，你觉得你去4S店买了辆车发现雨刮器噪音太大，结果人家帮你修好了问你要修理费，你会给吗？ 只有真正完成并交付使用的功能才被记录成为某个Sprint的Velocity，它代表的是一个Scrum团队真正的速率。

哦，对了，正规的项目交付中，我们还分为已完成的Velocity和被接受的Velocity，前者是团队的认知，而后者是PO的认知，如果两个值不一样，恭喜你，你有了一个Impediment。此外，请注意，我们计量的单位是故事点，而不是人天，工作小时或者其他什么，若干个Sprint的ramp up以后，我们希望Velocity和股票一样涨涨涨！

下一个Sprint的承载力（这个单位是人天！）

如果你不知道在下一个Sprint你有多少人能有多少时间为你的项目工作，那你自己就是一个Impediment，从趋势角度来说，我们希望看到的是一个稳定的承载力，任何不稳定的变化，即便是承载力的上升，也未必对团队的速率和质量有好处。

如果一个团队成员有20%投入在你的项目上，是否应当叠加他的人力呢，我的答案是否，试想你每天要花人力到处去找他，找到他也不一定能持续性的解决问题，天知道到底是加强团队承载力还是削弱，这些人有时候也许能解决大问题，但如果我是你，我会在管理成本和Impediment里都记上一笔。和Velocity不同的是，有时候我们并不喜欢这个值涨涨涨，我们更喜欢看到稳定的趋势，否则，你需要正视这个Impediment。

下一个Sprint的承载力（这回说的是故事点啦！）

如果你跑了5个Sprints，发现Velocity渐渐稳定在50左右，这时候，你就可以根据50故事点这个数字作为你团队交付能力的一个重要参照，也可以成为你未来项目走向和预判的一个重要数据支撑。

在Sprint Planning Meeting上，你的团队成员会承诺在下一个Sprint中完成多少个Story Points，如果累计的数字和50相差甚远，你最好问问团队，哪里出了问题。记录每个Sprint Planning中得出的预估完成故事点的数量，将他们和Velocity表对比，你就知道哪里出了什么问题。

Sprint中的范围蔓延 （你最好问问你的PO!）

你需要了解每个Sprint中增加/减少的Story Point，甚至是增加/减少的Story，我们希望这样的变化趋于0，但我们可以接受一定范围内的增加，但当这种趋势越来越不可控的时候，你最好问问你的PO，因为他看起来是你团队最大的Impediment。

分析问题，解决问题 (二八法则！)

如果你信奉二八法则，你可以试试帕累托分析来分析问题和解决问题，找到你的defect，通过鱼骨图找到造成问题的原因并记录下来，你会很快发现你80%的defect是由20%的原因造成的，解决了20%的Root cause，80%的问题将迎刃而解，是不是很酷。

Sprint的成功或失败 （直面成功或者失败！）

每个Sprint都应该有一个准确的结果定义，成功或者失败，不存在接近成功或者有些失败。你可以定义成功的标准，按时交付，按质交付，成本的控制，但重要的不是定义成功或者失败的指标，重要的是给团队一个Sprint结束后的准确评价，如果一个Sprint获得了失败的结果，那么每个团队成员在评审会议中都应该找到解决办法，期望下一次可以获得成功。让你的团队产生对成功的渴望，追逐每一个Sprint的完美交付，如果你没有这么想，那么你就是那个Impediment。

小结

这些指标和分析给谁看，给Senior Management Team？不不不，他们只想知道你的项目是不是红色，即便是橙色预警，他们也默认你的团队可以自行解决。这些信息应该给到你的Scrum团队，让他们知道发生了什么，是否存在问题，发生问题的原因是什么，最终帮助解决问题，快速成长和提高。 当然，如果你的团队缺乏足够的自我约束力，足够的工作积极性，你最好检讨下是不是面试环节出了问题 lol。

 

本文由点融黑帮 @Richie Zhang 原创投稿，并经人人都是产品经理编辑。未经许可，禁止转载。