研发团队状态评估模型


评估目的:

参考来源为Spotify团队管理实践,组织层面对研发小队的支持调查。我们进行了适应性改造,并探索出一套评估流程。

目的是为了帮助我们寻找团队需要聚焦于改善的点,以及了解团队需要哪些组织层面上的支持,便于组织更有针对性的协调资源并加强关注。

评估结果 不用于 考核、激励或负面评价。


评估项:

团队名称: XXXX ,评估时间: 2020年XX月XX日

评估项(V0.0.1) 评估结果
产品负责人(Product owner)
敏捷教练(Agile coach)
支配自己的工作(Influencing work)
易于发布(Easy to release)
合适的流程(Process that fits the team)
使命(Mission)
组织级支持(Organizational support)
达成目标的信心(Confidence to reach the goal)

当前评估项版本为V0.0.1,随着评估的深入和发展,可持续升级评估项。

结果标识说明:

结果用圆圈和箭头表示。

圆圈表示当前状态: 绿色表示正常黄色表示存在轻微问题红色表示存在严重问题。

箭头表示发展趋势: 表示没有变化 表示正在变好 表示正在恶化。

评估流程:

  1. 开场:评估引导师(一个熟悉此评估方法的人,SM是团队内部最佳选择)向团队成员介绍评估的目的、评估项及结果标识。

  2. 评估:评估师大声朗读第一条评估项及参考标准,停顿10秒后,朗读这条评估项的“解读”,然后询问团队成员是否有疑问,如没有疑问,请团队开始在纸上写下自己的评估结果,包括当前状态及变化趋势。

  3. 达成一致:团队成员都写完后同时说出自己的结果,如结果有不一致,请成员发言阐述自己的理由,然后询问是否有人变更自己的评估结果,直到达成相对一致意见。如经过2次阐述后仍然存在分歧,引导师将采用相对较差的结果作为最终结果。

  4. 逐条评估:循环第2、第3步,直到评估完所有的条目。

  5. 回顾评估方案:最后对本评估方案中的评估项、评估方法进行回顾,收集改进建议。

评判参考标准:

产品负责人(Product owner) —— 团队内有专职的产品负责人对任务的优先级进行排序;排序时,产品负责人能够综合考虑商业价值和技术因素。

解读:“产品负责人”是一个概括角色,可代表团队内部PO,也可代表真正的产品业务负责人,但对团队来说,重要的是,要做的任务故事是否有明确的优先级,并能得到团队的认可(考虑了商业价值和技术因素)。与之相对的是,团队不知道优先做哪个故事,都是重点,团队被分散单独负责一个一个的故事,疲于奔波。

敏捷教练(Agile coach) —— 团队有一位敏捷教练(或类似角色)帮助团队识别障碍、指导团队持续进行过程改进。

解读:“敏捷教练”也叫SM、敏捷主管等,是团队内部的角色,不是指外部敏捷培训师(临时教练)。

支配自己的工作(Influencing work) —— 团队内的每个成员都可以支配自己的工作、可以积极参与工作计划的制订、可以选择自己做什么任务。每个成员都可以把自己10%(每周3小时)的工作时间投入到自己感兴趣的内容学习中。

解读:冲刺计划是大家一起制定的,任务是可以自由选择的,而非某人指定。有自由学习时间,代表不会进行严重的加班赶工。

易于发布(Easy to release) —— 团队可以(并且确实做到!)轻松发布产品,而不需要很多的争论和同步。

解读:“争论”理解为流程、标准不明确,每次需要花费时间去讨论;“同步”理解为对信息、数据、依赖的沟通或等待,如上线审批、通告、上线包准备、外部依赖接口沟通或同步等会花费较多时间。

量身定制的流程(Process that fits the team) —— 团队拥有自己的工作流程并且持续对其进行改进(是否没有流程或是流程混乱)。

解读:自己可以并确实制定了团队的工作流程,每个人都知道,不认同的地方可以协商改进。

使命(Mission) —— 团队有一个组内所有人都知道并关心的使命;待办项列表中的故事都是和这个使命相关的。

解读:如没有真正的产品或公司使命,可理解为合同、合约任务,是否都知道并关心,不关心的现象可表现为不知道为什么要做这个故事,任务做完再也不管了等。

组织层面的支持(Organizational support) —— 团队知道去哪里寻求解决问题所需的支持,无论是技术问题、资源问题还是“软性问题”(“soft” issues)。

解读:知道组织提供了哪些支持(是否公开透明、团队是否有知晓的途径)。是否知道,不代表自己是否使用过这些支持。

达成目标的信心(Confidence to reach the goal)—— 团队是否对于达成团队使命目标充满信心。

解读:团队任何体现状态的内容都可代表信心的状态,比如积极讨论改进、主动争取任务、拥抱需求变更等,与之相对的是消极、冷眼旁观、抵触变化等。


文章作者: KavenRan
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 KavenRan !
 上一篇
一文读懂数据湖架构体系 一文读懂数据湖架构体系
1.1 数据湖的定义及发展需求数据湖(Data Lake)是Pentaho的CTO James Dixon提出来的,是一种数据存储理念——即在系统或存储库中以自然格式存储数据的方法。 目前,Hadoop是最常用的部署数据湖的技术,所以很多人
2020-12-16
下一篇 
DDD领域驱动设计实践 DDD领域驱动设计实践
参考来源:使用DDD指导业务设计的一点思考 https://insights.thoughtworks.cn/ddd-business-design/后端开发实践系列——领域驱动设计(DDD)编码实践 https://insights.t
2020-08-26
  目录