硝烟中的Scrum和XP-我们如何实施Scrum 15)多团队 Part 2/2 16)地理分散 17)检查列表 18)其他


		引入"团队领导"角色
假设有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团队都有高级工程师, 这样互相之间就不会有依赖核心人员的

补充：综合编程 , 其他综合 ,