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

2 评论 14197 浏览 38 收藏 8 分钟
🔗 产品经理在不同的职业阶段,需要侧重不同的方面,从基础技能、业务深度、专业领域到战略规划和管理能力。

如何跟踪项目进展,了解团队生产率,分析千行代码缺陷率等,相信对于一个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 原创投稿,并经人人都是产品经理编辑。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 此文严格来说应是“原创翻译”吧?语句明显翻译风啊!

    来自北京 回复
    1. 一头雾水进来,一头雾水出去

      来自四川 回复
专题
53336人已学习15篇文章
无论是个人运营体系还是公司运营体系的构建,你都能在这里找到。
专题
12269人已学习12篇文章
在商战中,运营设计是至关重要的一部分。本专题的文章分享了运营设计的那些思路和技巧。
专题
35570人已学习18篇文章
内容运营的正确姿势,你都能在这里找到!
专题
15713人已学习14篇文章
在我们的生活中,因为大数据的应用,很多事情变得越来越便利。本专题的文章分享了大数据的应用场景。
专题
11483人已学习12篇文章
从二维到三维空间的过渡,其交互范式也会随之从2D GUI时代转换到3D UI时代。本专题的文章分享了XR空间交互指南。
专题
146120人已学习15篇文章
作为产品经理,你多多少少得懂点技术。