引入"团队领导"角色
假设有3个团队开发同一个产品
红色的P是PO, 黑色的S是SM, 蓝色是其他团队成员;
如何决定哪些人属于哪个团队? 怎么分配成员? 有人觉得让PO来做人员分配, 但这不是PO职责内的事情; PO是领域专家, 可以指导团队的前进方向, 但不应该牵扯到这类细节; 尤其当PO是chicken的时候; [Pigs and Chickens http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig http://www.whatis.com.cn/word_5529.htm]
通过引入"团队领导"这个角色来解决这个问题; 或许叫他是Leader, Boss, Chief Scrum Master等等; 他不用领导某个团队, 但是会负责跨团队的问题, 例如谁来担任某个团队的SM, 大家如何分组等等; [Team Leader, 可能是Tech Leader, 可能是Manager之类的角色来担当这个任务]
怎样在团队中分配人手
多个团队开发同一个产品时, 一般的分配人手策略:
- 让指定的人来做分配, 例如Team Leader或PO或Manager(如果他的参与度比较高, 就能做出相对正确的决定)
- 让团队自己决定; [有时个人也可以提出愿望, 对于开放式文化的公司, 前提是你能力还行]
两种策略组合的效果较好;
在sprint计划会议之前, 团队领导会和PO以及所有的SM一起开团队分配会议; 共同讨论上一个sprint, 决定是否要进行重新分配, 可能会合并团队, 或者调换某人; 对一些问题达成一致后, 写到团队分配提案中, 在sprint计划会议上讨论;
会议上首先是遍历产品backlog高优先级条目, 然后讨论分配人手; 集中控制, 分散式优化; (以初步计划分组, 然后在sprint过程中按照实际情况调整)
是否使用特定的团队
假设技术选型包括三种主要组件: Client, Server, DB; 参与这个产品开发的有15人, 该怎样创建团队:
方式1) 特定于组件的团队
创建针对特定组件展开工作的团队; e.g. client团队, server团队和db团队;
如果大多数US都设计到多个组件, 这样的形式效果不好; 例如: 有一个US"留言板", 用户可以在上面彼此留言; 这个特性需要更新客户端的用户界面, 向服务器中添加逻辑, 还有增加数据库中的表;
这需要三个团队协作来完成这个故事, 内耗太多; [交流协调所花的时间]
方式2) 跨组件的团队
创建跨组件的团队, 团队的职责不会被束缚在任何特定的组件上;
如果大多数US都包括多个组件, 那这种团队划分方式的效果会很好; 每个团队都可以自己实现包括client, server和DB三部分的完整故事, 可以互相独立工作;
在实施Scrum的时候, 可以打乱特定于组件的团队(方式1), 创建跨组件的团队(方式2); 减少由于dependence造成的block; "我们没法完成这个US, 因为要等server完成API" [对于大型的项目, 或者已经既定的项目组, 可能还是无法避免, 需要在sprint计划的时候由Team Leader好好安排一下时间线]
如要有很强烈的需求, 也可以临时创建针对特定组件展开工作的团队;
是否在sprint之间重新组织团队
由于各自优先级最高的US类型不同, 不同的sprint之间会有很大差别: 因此导致各个sprint理想的团队构成也有所不同; 没有common的sprint, 每个sprint都有特殊之处;
在sprint中, 组件一个只负责客户端的团队, 每个人都熟悉客户端代码, 或许不错; 到了下个sprint, 也许组两个跨职能团队, 把客户端代码的人拆分出去也可以;
"团队凝聚力"是Scrum的核心要素之一, 如果一个团队合作多个sprint, 他们就会变得紧密; 会学会如何达成团队涌流group flow (http://en.wikipedia.org/wiki/Flow_(psychology)#Group_flow); 生产力巨大提升, 这需要一定时间磨合; 如果不断变化团队组成, 就无法得到强悍的团队凝聚力;
所以, 如果确实想重组团队, 先要仔细考虑下后果; 是否是长期变化? 如果是短期变化, 最好考虑跳过这一步; 如果是长期变化, 那就行动起来;
例外: 第一次在大型团队中开始实施Scrum的时候, 需要就团队拆分进行一些实验, 之后才能找到令人满意的做法; 要确保所有人能够理解: 在最开始几次时犯些错误是可以接受的, 只要可以持续改进;
兼职团队成员
Scrum书中的话: 在Scrum团队中含有兼职成员一般都不是好主意;
在兼职成员Joe进团队前, 需要认真考虑: 团队确实需要J么? 确定J不能全职工作么? J还要做其他什么事情? 能不能找其他人coverJ的其他工作, 让J在那份工作中只起到被动的, 支持性的作用? J能否从下一个sprint起在团队中全职工作, 把他其他的工作转交给别人?
有时候没有其他办法, 你确实需要J, 例如他是唯一的DBA [database administrator], 其他团队也非常需要他, 他永远不可能把所有时间分配给你的团队, 公司也无法雇佣其他DBA; 这种情况下就只能让J兼职; 但是确定遇到这种情况你需要做出评估;
"宁愿要3个全职成员, 也不愿要8个只能做兼职的"; [8个兼职确实不如3个全职, 时间计算率上可能是40%或60%, 但真正投入时间会大大折扣, 来来回回也影响团队计划]
如果有人需要把时间分配给多个团队, 最好有一个主要从属的团队; 找出最需要他的团队当作"主队"; 如果没有其他人把他要走, 那他就要参加主队的每日会议, 计划会议, 回顾会议等; [QA在sprint中抽2,3天帮别人测试defect或DEV帮忙改1-2个紧急bug的情况还是不少的, 重点是要有自己侧重的团队, 帮忙只是暂时的]
怎样进行Scrum-of-scrums
Scrum-of-scrums实际上是一个常规会议, 让所有的SM聚到一起交流;
e.g. 四个产品, 三个都只有一个Scrum团队, 另一个产品有25人, 分成多个Scrum团队:
这意味着有两个层次的Scrum-of-Scrums; 一个是"产品层次"的Scrum-of-Scrums, 包括Product D中的所有团队, 另一个是"团体层次"的Scrum-of-Scrums, 包括所有产品;
产品层次的Scrum-of-Scrums
这个会议很重要, 基本每周要有一次(或更多)[那meeting真的多死了]; 会议上要讨论集成问题, 团队平衡问题, 为下个sprint计划会议做准备等等;
Scrum-of-Scrums aganda: (30mins)
1) 每个人描述一下上周各自的团队都完成了什么, 这周计划完成什么, 遇到什么障碍;
2) 其他的需要讨论的跨团队的问题, 例如集成等等;
Scrum-of-Scrums的议程不是最主要的, 关键要有定期的会议来沟通;
团体层次的Scrum-of-Scrums
这个会议称为"脉动" [pulse?] 每周的全体会议;(所有参与开发的人员) 会议15mins;
会议的形式:
1) 开发主管介绍最新情况; 例如即将发生的事件信息;
2) 大循环; 每个产品组都有一个人汇报上周完成的工作, 这周计划的工作, 以及碰到的问题; 其他人也会做报告(配置管理领导, QA leader等)
3) 其他人看可以自由补充信息, 或者提问;
主要目的是发布概要信息, 而不是提供讨论或者反映问题的会议; 保证这一点, 15分钟一般足够; 如果出现热烈的讨论, 打断它, 请感兴趣的人会后留下继续讨论; [每周全体会议有点太忙的感觉...不一定是每个人必须参加的]
为什么要全体的脉动会议? 因为团体层次上的Scrum of Scrums主要以报告形式进行, 很少出现讨论; 在这个圈子外, 有许多人对这种信息感兴趣; 基本上大家都想知道其他团队在做什么; [说实话, 是这样, 虽然这些信息用处不大, 好像gossip一样] 既然打算花时间告诉彼此团队间都在做什么, 不如让所有人参加; [所以不是强制性的比较好, 相关的人通知一下必须参加]
交错的每日例会
如果有很多的Scrum团队参与单个产品的开发, 而且都在同一时刻进行每日例会, 那PO每天只能参加一个团队的daily meeting;
所以要避免团队在同一时刻进行每日例会:
每日例会不在团队房间进行(找个会议室, 白板旁边之类的), 每个会议大约15分钟, 但是每个团队在房间定下30分钟, 防止稍微的超时;
优点:
1) PO和相关的人(Manager?)可以在早上参加所有的例会; 想清楚了解当前的sprint进展情况, 有什么严重风险, 这是最好的方式;
2) 团队成员可以参加其他团队的例会; 这种情况不对, 但有时两个团队在相似的环境下工作, 会有几个人参加彼此的例会来保持同步;
缺点: 减少了团队的自由度--无法选择喜欢的或者说舒服的时间开例会;
[问题比较大的会是PO吧, 每天这样开会应该哭不出来想去死, 大多数APO收个邮件看一下或者有问题的时候再过来比较正常, 否则压力会让PO疯了]
救火团队
e.g. 在一个大型产品的开发过程中, 因为团队成员花了太多时间救火--修复早期版本中的bug, 所以无法实施Scrum; 这是个恶性循环, 花时间救火, 最好根本没有时间进行前瞻性的工作来防火(改进设计, 自动化测试, 创建监控工具与警报工具) [Scrum对团队的能力也有一定的要求]
创建一支专门的救火团队, 一支专门的Scrum团队来解决这个问题; 团队的工作是稳定系统, 有效防火;
救火团队/支持团队有2项工作:
1) 救火; 2) 保护Scrum团队原理各种干扰, 包括阻挡那些不知哪冒出来的, 增加临时特性的要求;
救火团队被安排在离门最近的地方, Scrum团队坐里面; 救火团队可以从物理上保护Scrum团队, 使他们不会受到急切的销售人员或者气疯的客户的干扰;
救火团队和Scrum团队都有高级工程师, 这样互相之间就不会有依赖核心人员的情况;
这也是对解决Scrum自行启动问题的一种尝试; 类似于分割团队; 这样Scrum团队有了空间努力工作, 最后能稳定系统; 救火队员也放弃预先计划的想法, 完全针对外部反应展开工作, 只管修复即将出现的下一个问题;
救火团队常常需要Scrum团队中核心人员的帮助, 可能是整个团队的帮助, 但大多数时候能防止Scrum受外部干扰; 几个月后, 系统达到足够稳定的状态, 解散救火团队, 创建新的Scrum团队;
[代价会不会有点大, 用一个团队为一个Scrum做救火的事情, 或许找1,2个人修bug就好了, 对于经常需要发布更新, 在开发重要时期的产品或许需要这种分配]
是否拆分产品backlog
假设有一个产品和两个Scrum团队, 那应该有几个product backlog, 几个PO?
策略1) 一个PO一个backlog
优点: 可以让团队根据PO当前设定的优先级来自行管理; PO关注他需要的东西, 团队决定怎么分割工作;
Sprint计划会议开始前, PO把US贴在产品backlog墙上(索引卡), 按照相对优先级排序; 通常贴上去的US要比一个sprint能完成的多;
Scrum团队选择墙上的空白贴上自己团队的名字作为团队墙; 从高优先级的开始把US逐个挪到团队墙上;
>黄色箭头表示US卡从产品backlog墙移动到团队墙的过程;
会议中, PO与团队会针对索引卡进行讨论, 把US在团队间移动, 移动相对位置调整优先级, 拆分成更小的条目等等; 过程大概1hour后, 团队会在自己的团队墙上形成一个sprint backlog的初步候选版本; 然后团队独立工作, 进行时间估算把故事拆分成任务;
这个过程会显得很嘈杂混乱和疲劳, 但不乏趣味和类似社交的过程; 结束时团队都能得到足够信息来启动sprint;
策略2) 一个PO, 多个backlog
PO会维护多个产品backlog, 每个团队对应一个;
缺点: PO要把US分配给团队, 而这项工作团队自己处理比较好;
[Senior的PO可以帮助团队在安排sprint backlog上节省时间, 有时这样也不错]
2)3)
策略3) 多个PO, 每人一个产品backlog
和2)有点像, 每个团队有一个产品backlog, 但每个团队都有一个PO;
缺点: 如果两个产品backlog对应了同一个代码库, 那两个PO可能会发生严重的厉害冲突; [关于哪个先做, 功能受到影响之类的问题]
如果两个产品backlog对应不同的代码库, 那就像把整个产品分成不同的子产品然后独立运作一样, 回到了每个团队一个产品的情况;
代码分支 branch
多个团队在同一代码库上工作, 势必会遇到SCM(软件配置管理software configuration management)系统中的代码分支问题;
- 主线/主干Main Branch的状态要严格保持一致, 最起码所有的东西能够通过编译, 所有的单元测试可以通过; 每时每刻都能创建一个可以工作的发布版本; 最好能做到持续构建系统在每晚进行build, 并把结果自动部署到测试环境中;
- 给每个版本打上标记tag; 无论什么时候, 只要是为验收测试进行发布, 或发布到产品环境, 主线中就应该进行版本标记, 用来精确表示所发布的内容; 将来的任一时刻, 都可以回退到某个历史版本中, 创建一个维护分支;
- 只在必须的时候创建分支; 规则: 如果你无法在不违反现有代码基线策略的情况下使用该代码基线, 那么只有在这种情况下才能创建新的代码基线; 因为每个活动分支都会增加复杂性, 增加管理成本; [branch之间的merge耗时耗力]
- 将分支主要用于分离不同的生命周期; 无论是否决定让每个团队在他们自己的代码基线上进行编码, 如果你打算在同一个代码基线上将短期的修复版与长时间的变化进行合并, 这将是个困难的任务;
- 经常同步; 如果在分支上工作, 那当代码可以构建时, 就应该和主线进行同步; 每天进行主线到分支的同步, 保持和其他团队所作变化的更新; 时间隔得越久, 同步会变得更难; [bugfix的branch可以等到fix完了在做integration, 其他的应该保持代码同步]
多团队回顾
在sprint demo结束之后, 各个团队各自按自己的方式做回顾;
在sprint计划会议上(同步sprint的情况下), 开始时可以让每个团队中找出一个发言人, 总结他们回顾中得到的关键点(5min), 然后就这些问题进行讨论(10-20mins); [这些东西可以先用mail交流整理好, 在planning的时候做这些太费时]
缺点: 在回顾之后, 计划会议之间, 没有足够的时间休整;
对于单个团队的产品, 不用在计划会议上对回顾进行总结, 因为每个人都真正参与了回顾会议;
---管理多个Scrum团队 End---
16 怎样管理地理位置分散的团队
Scurm和XP的大多数功效想要发挥, 团队成员最好是在一起紧密协作, 可以结对编程, 面对面交流;
总是会有一些分散的团队, 也许有些团队成员时不时在家工作; [有时候不同国家office的成员会组成一个team, 通过视频会议, 电话, 共享桌面等方式交流合作, "地球是平的"]
策略: 尽量把物理位置上分散的成员之间的沟通带宽增至最大:
- 能够一起结对编程;
- 能够在每日例会上面对面交流;
- 任何时候都能当面讨论;
- 可以真正的会面合作;
- 整个团队可以主动举行会议;
- 团队对sprint backlog, 燃尽图, 产品backlog和其他信息传递设施有相同理解;
其他措施:
- 每台工作站前面都配备网络摄像头和耳麦;
- 可以远程通话的会议室, 摄像头[类似视频会议室], 麦克风, 计算机桌面共享软件等等;
- 远程窗口; 大屏幕显示其他地点的固定画面; 增强一起工作的氛围;
- 交换程序; 来自每个地方的人按照某个规律交叉访问;
通过类似技术和手段, 慢慢实验然后观察->调整->观察->调整的过程中掌握合适的方法进行sprint计划会议, 演示, 回顾和每日Scrum会议等等;
离岸
离岸的方式有2种: 分散的团队和分散的成员;
第一种方式是被迫的选择; 一般会以第二种方式开始进行离岸开发;
原因:
1) 团队成员可以彼此更好地了解;
2) 两地之间能有良好的沟通基础, 让团队有愿望把基础打好;
3) 在开始的时候, 离岸团队较小, 没法独自组成有效的Scrum团队;
4) 独立离岸团队可以正常运作之前, 需要一段紧张忙碌的信息共享时期;
长期来看, 也许会慢慢过渡到"分散的团队"这种方式;
在家工作的团队成员
在家工作有时效果很好, 只要你还没孩子的话~ [有些办公室环境实在不适合程序员进入状态]
团队处在相同的物理位置是Scrum的基本原则之一;
通常让团队自己决定在家工作的时间和频率[先要有VPN]; 离家太远或者特殊状况在家工作也是经常发生的; 原则上是鼓励团队在多数时间内聚在一起; 在家工作时通过instant message或者语音通话软件(skype)/电话来参加每日scrum会议; 保持在线, 可以实时通信;
尝试聚焦日: 例如周三, 表示如果得到团队许可, 你可以在周三在家工作; 大多数人会在周三在家完成大量工作, 同时保持协作; 因为只有一天, 团队成员不会脱离同步状态太久; [每周这样有点多, 偶尔为之调节一下就好, 毕竟在同一个办公环境交流更顺畅]
---管理地理分散团队 End---
17 Scrum master检查列表
SM日常执行的常用管理事务:
sprint开始阶段
-
Sprint计划会议之后, 创建Sprint信息页面;
- 在wiki上创建从dashboard指向所创建页面的链接;
- 把页面打印出来, 贴在团队工作区域周围的墙上, 让其他人可以看到;
-
给每个人发邮件, 声明新的sprint启动; 邮件中包括sprint目标和指向sprint信息页面的链接;
-
更新sprint数据文档; 加入估算生产率, 团队大小和sprint长度等等;
每一天
-
确保每日Scrum会议可以按时开始和结束;
-
为了保证sprint如期完成, 需要适当地增删故事;
-确保产品负责人了解这些变化;
-
确保团队可以及时得知Sprint backlog和燃尽图的最新状况;
-
确保存在的问题和障碍都能被解决, 报告给PO以及开发主管;
sprint结束时
-
进行开放式的Sprint演示;
-
演示开始前一两天通知到每个人; [Meeting schedule]
-
与整个团队以及PO一起开Sprint回顾会议; 开发主管也应该邀请[一般是偶尔参加], 他可以帮忙把你们的经验教训加大大传播范围;
-
更新sprint数据文档; 加入实际生产率和回顾会议中总结的关键点;
---SM检查列表 End---
18 额外的话
Scrum必须针对每一种不同的环境来进行具体实施, 很难站在通用的角度上讨论什么是最佳实践; [没有best practice, 只有适合的和更好的]
http://www.crisp.se/konsulter/henrik-kniberg
http://blog.crisp.se/author/henrikkniberg
---其他 The End---
[前几章的方法和经验都很棒, 后面的部署特别是多团队的管理方面不一定适合各个公司, 大家在实践中找到更好更适合的方案才是Scrum发展的重点]