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 的要求就越高,对团队成员的要求也越高。
在敏捷开发团队中,这是一个不断学习和改进的过程,提升了整个团队的能力和水平,因此非常有利于团队的发展,尤其是在职场新人较多的情况下。
最后,最好让他们在团队工作中学习成长,这样可以帮助他们更快的进步,提升团队的整体实力。