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

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

cd04235fa

如何跟踪项目进展,了解团队生产率,分析千行代码缺陷率等,相信对于一个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和股票一样涨涨涨!

1.webp

下一个Sprint的承载力(这个单位是人天!)

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

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

2.webp

下一个Sprint的承载力(这回说的是故事点啦!)

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

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

3.webp

Sprint中的范围蔓延 (你最好问问你的PO!)

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

4.webp

分析问题,解决问题 (二八法则!)

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

5.webp

Sprint的成功或失败 (直面成功或者失败!)

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

6.webp

小结

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

 

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

您的赞赏,是对我创作的最大鼓励。

评论( 1

登录后参与评论
  1. 此文严格来说应是“原创翻译”吧?语句明显翻译风啊!

    回复
加载中