Table of Contents
hide
为什么 Scrum 简单但不容易？
Scrum 简单但不容易，原因如下：
- 一个成功的变革不是完全自上而下或自下而上；
- 最终状态不可预测，Scrum 需要持续改进；
- Scrum 在整个组织中无处不在；
- Scrum 与传统的培训/教育完全不同；
- 变化来得比以前更快；
- 最佳实践是危险的。找到适合自己的方法；
Scrum 不仅是技术变革，也是概念创新。整个团队在做事时必须采取以下态度：
- 团队必须学会在没有大而全面的计划的情况下开始工作；
- 团队必须学会通过用户故事和沟通来分析和理解需求，无需详细的需求文档，开始设计和编程；
- 团队应该习惯频繁的代码提交和持续集成；
- 团队在高度透明的环境中工作，每个人的进步都为大家所熟知；
- 团队需要结对编程，需要经常沟通和讨论；
Scrum 不仅仅是一个流程框架，更重要的是，它利用 Scrum 来构建团队，提升团队能力。团队磨合的程度几乎决定了 Scrum 实施的效果。但团队的成功不是一蹴而就的。如何在团队的不同阶段打磨团队，是每个人都面临的挑战。
本文重点介绍一个 Scrum 团队从创建到成熟的三个阶段，帮助你定位你的团队阶段，找到突破下一个阶段的方法。
敏捷团队：第一阶段
- 团队中的 PO（产品负责人）角色明确，由 PO 负责管理 Product Backlog；
- PO是需求的主要来源，负责收集各方需求，对需求负责；
- PO负责确定Product Backlog的优先级，发生变化时也是如此；
- 团队中有一个人可以担任 Scrum Master的角色，基本上这个人会长期担任 Scrum Master 的角色；
- 基本上能够协调团队解决Sprint中遇到的问题。但是，解决跨域问题的能力较弱；
- Scrum Master 协助团队成员维护 Sprint Backlog，培养团队成员自己维护 Sprint Backlog 的习惯；
- Scrum Master 负责领导和主持站立会议。站立会议在固定地点和时间，在标准时间内结束。Scrum Master 非常清楚团队每个成员的工作内容，大部分问题和风险都可以通过站会发现。；
- Scrum Master 负责按计划召开各种会议，如计划会议、总结会议、PRD（Performance review and development）reivew、Code review、Case review等；
- Scrum Master负责领导和主持计划会议，给出工作时间的评估方法，给出本次sprint的计划内容和优先级，指导大家拆分sprint内容，指导大家完成工作的评估小时;
- Scrum Master 负责领导和主持总结会议。Scrum Master主要负责总结本次迭代的优缺点，针对不足制定改进措施并跟进；
- Scrum Master 负责监控风险和进度，并可以通知涉众；
- 在大多数情况下，团队可以完成对 国防部的承诺；
敏捷团队：第二阶段
- PO负责管理Product Backlog，团队审批Product Backlog的内容；
- 团队将协助 PO 收集需求，并积极提出需求。团队认可需求并对需求负责；
- PO 协助团队确定 Product Backlog 的优先级，即使发生更改；
- Scrum Master 在团队中的角色是备份。当 Scrum Master 不在时，Backup 可以完全承担工作的角色；
- 完全能够协调团队解决Sprint中遇到的问题。促进跨领域解决问题的能力强，但促进跨部门解决问题的能力弱；
- 团队成员自己维护Sprint Backlog的习惯已经形成，Scrum Master只需要监督和提醒；
- Scrum Master 协助站立会议的有效进展。展位会议在标准时间内在固定地点和时间结束。团队成员对其他成员的工作内容非常清楚。团队成员可以协助 Scrum Master 发现一些问题和风险。Scrum Master 仍然发现了一些问题和风险；
- Scrum Master 协助各种会议的有效进行，如计划会议、总结会议、PRD评审、ERD评审、Code评审、Case评审等；
- Scrum Master 协助计划会议的有效执行，并与团队成员讨论确定本次 sprint 的工作时间、计划内容和优先级的评估方法，然后共同完成 sprint 内容的拆分和评估工作时间;
- Scrum Master协助总结会议的有效进展，与团队成员讨论总结本次迭代的优缺点，并能制定有效的改进措施，针对不足之处进行有效改进，优势得以持续保持；
- 在 Scrum Master 的带领下，团队成员参与监控风险和进度，并可以定期通知涉众；
- 团队共同完成其对 DOD（完成的定义）的承诺；
敏捷团队：第三阶段
- Product Backlog由PO发起和管理，Team参与讨论和改进；
- 团队共同提出和收集需求，共同对产品负责；
- 团队共同确定并负责 Product Backlog 的优先级，即使发生更改；
- 团队中的任何人都可以担任 Scrum Master 的角色；
- 能帮助Team克服Sprint中遇到的一切障碍，具有较强的跨域跨部门问题推动能力，保证DoD按约定完成；
- 团队成员有意识地维护 Sprint Backlog，Scrum Master 定期检查团队成员对 Sprint Backlog 的维护情况；
- 团队成员积极参与站立会议，高效有效地进行。站立会议在固定的地点和时间，并在标准时间内结束。团队成员对其他成员的工作内容非常清楚，团队成员积极提出问题和风险，与Scrum Master一起发现所有问题和风险；
- 在 Scrum Master 的协助下，团队成员领导各种会议的有效进行，如计划会议、总结会议、PRD reivew、ERD review、Code review、Case review等；
- 在 Scrum Master 的协助下，团队成员主持计划会议，团队对工时评估结果、本次 sprint 的计划内容和拆分结果、优先级确认结果共同负责；
- 在 Scrum Master 的支持下，团队成员领导总结会议。团队对本次迭代的结果共同负责，能够共同认识到缺陷的根本原因。后期，全体队员积极有效地改进，逐步将短板转化为优势。优势可以越来越好；
- 团队积极共同监控风险和进展，并能及时通知利益相关者；
- 团队专注于功能的实现，专注于产品的实现。团队有能力识别产品的正确路线，共同推动产品的持续改进；
概括
敏捷团队越成熟，它对 PO 和 SM 的要求就越高，对团队成员的要求也越高。
在敏捷开发团队中，这是一个不断学习和改进的过程，提升了整个团队的能力和水平，因此非常有利于团队的发展，尤其是在职场新人较多的情况下。
最后，最好让他们在团队工作中学习成长，这样可以帮助他们更快的进步，提升团队的整体实力。