入门指南 | 敏捷开发团队成熟度评估参考标准

当一个产品团队采用敏捷开发模式时，如何来确认这个团队是否真的已经敏捷了呢？这是非常重要的，在日常工作过程当中，团队的工作模式很大程度上会受团队负责人或者服务性领导的影响，有时候会因为这个负责人的一些个人工作风格，而使团队的敏捷模式偏离了方向，没有让团队真正的敏捷起来。前面一篇文章也介绍过，在敏捷开发模式团队内部，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 负责监控风险和进度，并能知会给利益相关人；

更多推荐阅读