敏捷开发团队

敏捷开发团队成熟度提高如何做?怎样的团队是高敏捷团队?如何确定团队的敏捷性?本文重点对Product Owner和Scrum Master这两个角色的评估,围绕这两个角色来给出初级,中级,以及高级敏捷团队的参考标准,快来看看你的团队是否敏捷吧!

如何评估敏捷开发团队成熟度

当一个产品团队采用敏捷开发模式时,如何来确认这个团队是否真的已经敏捷了呢?这是非常重要的,在日常工作过程当中,团队的工作模式很大程度上会受团队负责人或者服务性领导的影响,有时候会因为这个负责人的一些个人工作风格,而使团队的敏捷模式偏离了方向,没有让团队真正的敏捷起来前面一篇文章也介绍过,在敏捷开发模式团队内部,Product Owner 和 Scrum Master 这两个角色非常重要,他们是带领整个团队前进的,下面的评估参考标准其实基本上是围绕这两个角色展开的。

一个团队花了很多钱请来了外部的培训师和教练,同时雇佣 5 个员工组成“敏捷办公室”为新的 Scrum 团队提供建议和帮助。他们失败是因为他们认为实施 Scrum 仅限于开发团队。发起敏捷转型的管理层认为,只给开发人员提供培训和支持就足够了。他们没有考虑到 Scrum 对产品经理、测试人员、 UED 等人员的工作带来的影响。如果这些地方没有改变,组织惰性会把整个团队带回原点。

Scrum 简单但并不容易,原因如下:

1、成功的变革不是完全的自上而下或者自下而上;

2、结束状态是不可预知的,Scrum 需要持续的改进;

3、Scrum 在整个组织中是无处不在的;

4、Scrum 和传统培训/教育是截然不同的;

5、变化来的比以往更快;

6、最佳实践是危险的,要找到适合自身的方法;

Scrum 不仅是技术层面的转型,更意味着理念的革新,整个团队都要参与进来

1、团队要学会在没有大而全的计划的情况下开始工作;

2、团队要学会在没有详细需求文档的情况下,通过用户故事和交流分析和理解需求,开始设计和编程;

3、团队要习惯于频繁递交代码和持续集成;

4、团队是在高度透明的环境下工作,每个人的进展所有人都了如指掌;

立即登录阅读全文
登录或注册即可解锁全站内容,即表示你理解并同意 服务协议 与 隐私政策

5、团队需要进行结对编程,需要频繁的沟通和讨论;

初级敏捷团队

1、Team 内 PO 角色清楚,PO 负责管理 Product Backlog;

2、PO 是需求的主要来源,并负责从各方收集需求,并对需求负责;

3、PO 负责 Product Backlog 优先级的确定,当变动发生时也是如此;

4、Team 中有一个人可以承担 Scrum Master 这个角色的工作,基本上由此人长期承担 Scrum Master 的工作;

5、基本能够协调 Team 解决在 Sprint 内遇到的问题。但是对跨 Domain 的问题解决推动能力弱;

6、由 Scrum Master 协助团队成员进行维护 Sprint Backlog,并培养团队成员自行维护 Sprint Backlog 的习惯;

 

7、Scrum Master 负责主导和主持站会,站会在固定地点和固定时间,在标准时长内结束,Scrum Master 对团队每个成员的工作内容都很清楚,可以通过站会发现大部分问题和风险;

8、Scrum Master 负责各种会议的如期进行,如plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review 等等;

9、Scrum Master 负责主导和主持 plan meeting,给出工时的评估方式,给出本次sprint的计划内容和优先级别,引导大家进行 sprint 内容的拆分,引导大家完成工时的评估;

10、Scrum Master 负责主导和主持总结会议,主要由 Scrum Master 负责总结本次迭代的优点和缺点,并针对缺点制定出改进措施并进行跟进;

11、Scrum Master 负责监控风险和进度,并能知会给利益相关人;

12、Team 大部分情况下能够完成对 DOD 的承若;

中级敏捷团队

1、PO 负责管理 Product Backlog,Team 认可 Product Backlog 内容;

2、Team 会协助PO收集需求,也会积极提出需求,Team 认可需求并对需求负责;

3、PO 协助 Team 进行 Product Backlog 优先级的确定,当变动发生时也是如此;

4、Team 中 Scrum Master 这个角色的工作有 Backup,当 Scrum Master 不在时,Backup 可完全承担该角色的工作;

5、完全能够协调 Team 解决在 Sprint 内遇到的问题。对跨 Domain 的问题解决推动能力较强,但对跨部门的问题解决推动能力较弱;

6、团队成员自行维护 Sprint Backlog 的习惯已形成,Scrum Master 只需监督和提醒;

7、Scrum Master 协助站会有效进行,站会在固定地点和固定时间,在标准时长内结束,团队成员对于其他成员的工作内容都很清楚,团队成员可以协助 Scrum Master 发现一些问题和风险,大部分问题和风险还是由 Scrum Master 发现;

8、Scrum Master 协助各种会议的有效进行,如 plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review 等等;

9、Scrum Master 协助plan meeting 有效进行,和团队成员共同商讨确定工时的评估方式、本次 sprint 的计划内容和优先级别,进而共同完成 sprint 内容的拆分和工时的评估;

10、Scrum Master 协助总结会议有效进行,和团队成员共同商讨总结本次迭代的优点和不足,能够针对不足制定出有效的改进措施并进行有效的改进,而优点能够继续保持;

11、Scrum Master 主导,团队成员参与监控风险和进度,并能定期通知给利益相关人;

12、Team 共同完成对 DOD 的承若;

高级敏捷团队

1、Product Backlog 由 PO 发起管理,由 Team 共同参与讨论完善;

2、Team 共同提出和收集需求,共同对产品负责;

3、Team 共同对 Product Backlog 优先级进行确定并负责,当变动发生时也是如此;

4、Team 中任何一个人都可以承担 Scrum Master 这个角色的工作;

5、可以帮助 Team 跨越 Sprint 中遇到的一切障碍,对跨 Domain 和跨部门的问题解决推动能力均较强,保障 DoD 按约定完成;

6、团队成员自觉维护 Sprint Backlog,Scrum Master 定期检查团队成员维护 Sprint Backlog 的情况;

7、团队成员积极地参加站会,站会高效地效进行,站会在固定地点和固定时间,在标准时长内结束,团队成员对于其他成员的工作内容都很清楚,团队成员积极提出问题与风险,和 Scrum Master 共同发现所有问题和风险;

8、Scrum Master 辅助,团队成员主导各种会议的有效进行,如 plan meeting、总结会议、PRD reivew、ERD review、Code review、Case review 等等;

9、Scrum Master 辅助,团队成员主导 plan meeting,Team 共同对工时评估的结果,本次sprint 的计划内容及拆分结果,优先级别确认结果负责;

10、Scrum Master 辅助,团队成员主导总结会议,Team 共同对本次迭代的结果负责,能够共同认识到不足的根本原因所在,后期所有团队成员都积极有效的改进,将不足逐渐转变为优点,而优点能够越做越好;

11、Team 共同积极监控风险和进度,并能及时通知给利益相关人;

12、Team 从专注功能实现专为专注产品实现,Team 有能力识别产品的正确路线,共同促使产品不断被完善;

同样都是十二条参考评估标准,越成熟的敏捷团队,不光对 PO 和 SM 的要求越高,还对团队成员的要求也逐渐提高。在敏捷开发团队内部,是一个互相学习,互相进步的过程,可以促进整个团队的能力和水平的提升,因此对团队的发展是非常有好处的,特别是团队内部职场新人比较多的时候,花大成本去培训、去传帮带,还不如让他们在团队工作当中去学习和成长,这样可以更加快速的帮助他们提高,也提高了团队整体的实力。

点个赞鼓励一下作者吧~

加入创新交流群

免费送7大行业30案例 及时看最新指南/研报
点赞
收藏
请用微信扫码分享哦~
分享

勿删,用于自定义目录加锚点,隐藏即可

相关文章推荐

0 thoughts on “创新指南 | 评估敏捷开发团队成熟度的12大参考标准

  1. 评估敏捷开发团队成熟度需要有系统的方法和标准,这篇文章为敏捷开发者提供了非常好的思路。

发表回复

点赞
收藏
请用微信扫码分享哦~
分享

还差一步
扫码锁定入群名额

加我时请备注下方群名

创新战略交流群

免费送“2024新业务孵化/战略创新指南”

B2C增长创新群

免费送“10大消费行业50个增长案例汇总”

B2B增长创新群

免费送“7大B2B行业30个增长案例汇总”

AI应用创新群

免费送“20篇AI研报+110套GPT提示”
关闭按钮
欢迎来到Runwise即能创新社区!
登录装饰图,三个人围坐在电脑前,对某个灵感进行沟通和讨论
已有账号?
电话咨询
7x24热线,欢迎致电咨询
微信咨询
扫码添加专家微信
扫码添加专家微信
享专家1V1咨询