|
随着组织中的scrum团队增加，特别是在多个scrum团队比较紧密地工作在一个产品上的时候(对大型的公司这个非常正常)，我们就不得不面对不同团队之间的协同的挑战，所以寻找和探索大规模敏捷的解决方案就变得很自然。行业里目前有一些大规模敏捷的解决方案，最基础的就是Scrum
of Scrums(SoS)，复杂一点的模型有Scaled Agile Framework(SAFe)，Large Scale Scrum(LeSS)，
Disciplined Agile Delivery(DAD)。我会对每个模型都专门一个篇幅做介绍，这篇短文先只介绍Scrum of Scrums。club.mypm.net
PgMp.mypm.net
bbs.mypm.net
Scaled Agile Framework项目管理者联盟
Scrum of scrumsPgMp.mypm.net
当多个scrum
team工作在同一个产品上的时候，虽然我们努力想做到全功能的特性团队，希望能在一个团队里做完所有的事情，而不需要依赖其他的团队，但这明显只是一个非常理想的状态;团队之间不可避免会有依赖，需要协同。Scrum
of
scrums的做法就是每个scrum团队选出1-2个代表，团队的代表聚在一起分享进度和协同解决依赖。如果组织很大，scrum团队太多，也会出现先按部门的划分在不同的部门里做SoS，然后不同部门的代表再聚在一起做“Scrum
of Scrum of Scrums”。也就是分层次的SoS。项目经理圈子
club.mypm.net
项目管理者联盟
Scrum of Scrums项目管理者联盟文章
怎么做SoS项目管理者联盟文章
SoS非常简单，它的主要形式就是一个(或一系列)会议。www.mypm.net
首先，这个会议多久开一次?项目管理者联盟
最频繁的情况是每天一次，最少的情况下是每周一次。pmp.mypm.net
我个人不太赞成每天一次的SoS，原因是一般来说团队之前还没有每天都同步的需要，如果真的有说明工作联系太过紧密了，可能背后是团队划分或是任务划分出了问题，我们需要先解决组织或任务划分问题。一周一次的会议相对于2周一个迭代的情况又太晚，所以一周2-3次的SoS相对比较合适。项目管理者联盟
谁可以作为团队的代表参加SoS
一般很自然的会让scrum
master去参加SoS会议，但这不是一定的，我希望能看到不同的团队有不同的做法。如果团队明显对其他团队有技术相关的依赖的时候，团队里地技术专家更需要参加SoS以从技术的角度阐述自己团队的需求。转自项目管理者联盟
总之，团队自己决定谁去参加SoS最合适，甚至轮流去参加也是一个可行的办法。项目管理者联盟
会议讨论什么内容?training.mypm.net
这个会议和scrum team里的每日站立会议非常像，我们也是基于回答几个问题来操作。项目管理者联盟
但是考虑到会议的目的不同，SoS需要每个团队代表回答的问题也有一些区别，一般情况我们会让大家回答下面这几个问题：www.mypm.net
1. 从上次会议到现在你们team做了哪些任务?项目管理者联盟
2. 到下次会议之前你们team计划完成哪些任务?pmp.mypm.net
3. 你们team有哪些困难需要其他team协助的?转自项目管理者联盟
4. 你们有没做什么会影响其他team工作的决定的?项目管理论坛
我们一定要注意，SoS会议千万别搞成了scrum
master来轮流汇报工作的会议，这不是SoS的目的，这个会议要解决的事团队之间相互影响和依赖的问题，所以我们希望能暴露出此类问题，并尝试在下次会议之前解决它。项目管理者联盟
|
