敏捷开发团队成熟度提高如何做？怎样的团队是高敏捷团队？如何确定团队的敏捷性？本文重点对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 的要求越高，还对团队成员的要求也逐渐提高。在敏捷开发团队内部，是一个互相学习，互相进步的过程，可以促进整个团队的能力和水平的提升，因此对团队的发展是非常有好处的，特别是团队内部职场新人比较多的时候，花大成本去培训、去传帮带，还不如让他们在团队工作当中去学习和成长，这样可以更加快速的帮助他们提高，也提高了团队整体的实力。
0 thoughts on “创新指南 | 评估敏捷开发团队成熟度的12大参考标准”
对于刚刚接触敏捷开发的团队，这篇文章提供了非常好的参考和引导。
敏捷开发团队成熟度评估是企业管理的重要一环，这篇文章为此提供了非常好的探讨
这篇文章提供了非常好的参考和建议，值得敏捷开发团队认真学习和借鉴。
这12个参考标准非常实用，我会将其运用到我的团队中。
作为一个拥抱创新的企业家，我认为评估团队成熟度是非常重要的。
评估敏捷开发团队成熟度是发展的必经之路，这篇文章为此提供了非常好的建议和指导。
评估团队成熟度是创新和发展的必要前提，这篇文章提供了非常好的指导。
我非常欣赏这篇文章提供的12大参考标准，值得我们借鉴和学习。
评估敏捷开发团队成熟度需要有系统的方法和标准，这篇文章为敏捷开发者提供了非常好的思路。
我发现自己团队在几个标准上存在欠缺，需要进一步优化才能更好地满足客户需求。
我认为这篇文章非常实用，可以帮助我们更好地运用敏捷开发模式
这篇文章很有用，让我对敏捷开发团队成熟度的评估有了更清晰的认识。