读《SCRUM与极限编程》笔记2

1、怎样组合使用scrum与XP？
scrum注重的是组织实践和管理实践，而XP注重的是实际的编程实践。他们解决的不是同一个领域的事情，可以相得益彰，互相配合。
XP中一些有价值的实践：
（1）结对编程
可以把代码审查作为结对开发的替代方案
（2）TDD，测试驱动开发：意味着先写一个自动测试，然后编写恰好的代码可以通过这个测试，然后对代码进行重构，主要是提高可读性和消除重复。
TDD对系统设计的正面影响特别大。
（3）增量设计：开始的时候设计简单化，然后再次基础上不断完善。而不是一开始就冻结他，不再改变。
持续的设计改进，很大程度上市TDD带来的成果。
（4）持续集成
（5）代码集体所有权：尤其是结对编程后，这项任务就被提高了很高的级别，有人生病也不会影响这次的sprint。
（6）引入代码标准
（7）可持续的开发速度/精力充沛的工作：减少加班
2、验收测试
在scrum中避免不了的环节，如何把验收测试缩短到最短，提高代码质量，如何提高代码质量呢？
（1）将测试人员加入到scrum团队
（2）每个sprint少做点工作
团队中的测试人员是主要工作是测试的人员，而不是只做测试的人员。他可以还做其他工作，例如：测试人员可以作为组织演示会的人员，检查产品的完成标准。
验收测试作为sprint的一部分吗？不是固定的，但是最好不作为，可以通过调整每个sprint的投入程度，来作为修改bug的工作。参考下图：

在接下来的sprint中遗留一些时间修改上次遗留的bug，如果修改bug占用太多的时间，我们就会分析原因找到解决措施提高质量，我们会确保sprint的长度，确保修改一定数量的高优先级的bug。在sprint paln会议上会将会将投入程度设置到最低。
3、怎样管理多个scrum团队？
多个团队间的产品不会有重合，不会互相影响。
在scrum中，团队分割缺失很困难。不要想的太多，也别费太大劲做优化，先做实验，观察虚拟团队，然后确保在回顾会议上有足够的时间来讨论这种问题。迟早就会发现针对你所在的环境的解决方案。需要重视的是，必须要让团队对所处环境感到舒适，而且不会彼此常常干扰。
最佳的团队尺寸：5-9人，3-8人。
4、是否同步多个sprint？
我的第一印象是不用。
书中提到的好处：
（1）可以利用sprint之间的时间来重新组织团队，如果各个sprint重叠的话，要想重新组织团队，就必须打断至少一个团队的sprint进程。
这种情况不应该经常发生吧，为什么要重新组织团队结构呢？
（2）所有团队都可以在一个sprint中向同一个目标努力，他们可以有更好的协作。
团队之间的协作，那我考虑是不协作太多可以合并为一个团队了？
（3）更小的管理压力，即更少的sprint计划会议、sprint演示和发布。
5、我们为什么引入“团队领导”的角色
假设三个团队开发同一产品。
会通过引入“团队领导”的角色来解决这个问题，也许可以叫做“scrum中的scrum master”，或者团队领导，他不用领导某个团队，但是会负责跨团队的问题，例如谁担任哪个团队的scrum master，大家如何分组等等。
6、我们怎么在团队中分配人手？
（1）让一个指定的人做分配，例如前面提到的团队领导，或者产品负责人，或者职能经理（如果他的参与度比较高，就能做出正确的决定）
（2）让团队自己决定
（3）二者的组合
第三种的效果最好，在sprint计划会议之前，团队领导会跟产品负责人和所有的master一起开团队分派会议。我们共同讨论上一个sprint，决定是否需要重新进行分配。也许会合并两个团队，或者调换某个人。我们就一些问题达成一致，并写到团队分配提案中，在sprint计划会议上进行讨论。
plan会议上，宣布这是初步放案，接下来的时候，你们还可以取另一个团队，或者把你们这个团队一份味儿，或者跟另一个团队合二为一，怎么都行。
这种方式比较好，开始集中式控制，后续分散式优化。
7、是否使用特定的团队？
跨组件的团队，也就是说团队的职责不会被束缚在任何特定的组件上，团队是按照功能划分。
8、是否在sprint之间重新组织团队？
如果不断变换团队的组成，你就永远无法得到强悍的团队凝聚力。所以，如果你缺失想要重新组织团队，请先考虑一下后果。这是个长期变化还是短期变化，如果是短期变化，最好考虑跳过这一步。如果是长期变化，那就干吧。
还有一种特例就是，在第一次的大型团队实施scrum的时候，你需要就团队拆分进行一些实验，最后才能找到令所有人全都满意的做法。要确保所有人都能够理解：在最开始几次时发错误是可以接受的，只要能够持续改进。
9、兼职团队成员
在scrum团队中含有兼职成员一般都不是什么好主意。
如果有一个人需要把他的时间分配给多个团队，哪最好让他有一个主要从属的团队。找出最需要他的团队，把他单过他的主队。如果没有取他人把他拖走，哪他就得参加这个团队的每日scrum会议、sprint计划会议、回顾等等。
10、怎么进行scrum of scrums？
实际上是一个常规会议，是为了让所有的master聚到一起交流。
分为产品层次的scrum of scrums、团队层次的scrum of scrums

（1）产品层次的scrum of scrums
一周一次或者一天一次，会议上回讨论集成问题、团队平衡问题、为下个sprint计划会议做准备等等。
一般会议程安排如下：（1）描述上周各自团队完成了什么，这周计划完成什么，遇到的阻碍；（2）其他需要讨论的跨团队的问题，例如集成。
（2）团队层次的scrum of scrums：严格控制会议时间
会议形式：（1）开发主管介绍最新的情况，例如即将发生的信息（2
大循环，每个产品组都有一个人汇报他们上周完成的工作，这周计划完成的工作，以及碰到的问题，其他人也会作报告（配置管理领导、QA领导等）（3其他人都可以自由补充任何信息，或者提问任何问题。）
这是个发布概要信息的论坛，而不是提供讨论或者反应问题的场所，只要保证这一点，15分钟就够了。有时也会超时，如果出现热烈讨论，就要打断它，请感兴趣的人在会后留下继续讨论。
11、交错的每日例会
如果所有团队再同一时间早开例会，那么像po无法参加所有，最好错开早开：
好处有二：（1）po从整体了解每个团队的进度，可以掌控风险（2）团队可以了解其他团队的进展。
缺点是团队缺少自由度。
12、救火团队
救火团队的两项任务：（1）救火（2）保护scrum团队原理各种干扰，包括挡开那些不知从何而来、临时增加特性的要求。
经过几个月以后，这个系统达到了足够稳定的状态，就可以解散救火团队。
13、是否拆分产品backlog？
假设有一个产品和两个scrum团队，那么应该有几个产品backlog呢？几个PO呢？
（1）一个PO，一个产品backlog：这种方式是所有人召集到一起，po建华所有backlog贴到墙上，各个团队选择backlog移到自己的团队backlog中：


整个过程会很累，但是所有团队通常都会得到足够的信息去启动他们的sprint。
（2）一个产品负责人，多个backlog
这样做的劣势是：po要把故事分配给团队，而这项工作交给团队自己做会更好。

（3）多个产品负责人，每人一个backlog

如果两个产品backlog都对应同一个代码库，那两个po可能会发生严重的厉害冲突。如果两个产品backlok所对应的代码库不同，拿这样做，就跟把整个产品分成不同的子产品然后独立运作毫无二致。也就是我们回到了每个团队一个产品的情况。
14、代码分支
有多个团队再同一个代码库基础上工作，我们就势必会碰到SCM（软件配置管理）系统中的代码分支问题。现在已经有很多关于处理多人协同工作问题的书和论文了
15、多团队回顾
如果有多个团队开发同一个产品，我们怎么样做sprint回顾呢?
各自团队回顾后，在下次在sprint计划会议上（因为在同一个产品上，所有团队时间同步一起参与），每个团队将回顾总结汇报，然后大家一起讨论。控制时间。然后再开始真正的计划会议。
17、scrum master检查列表
sprint开始阶段：
（1）sprint计划会议之后，创建sprint信息页面
在wiki上创建dashboard指向做创建页面的链接
把页面打印出来，贴在通过你们团队工作区域之外的墙上，让经过的人可以看到
（2）给每个人发邮件，声明sprint已经启动。邮件中包括目标和指向sprint信息页面的链接。
（3）更新sprint数据文件，加入估算生产率、团队大小、sprint长度等等
每一天：
（1）确保每日站会可以按时开始和结束
（2）为了保证sprint可以如期完成，适当的增删故事
确保po了解这些变化
（3）确保团队可以及时得知sprint backlog和燃尽图的最新状况
（4）确保存在的问题和障碍否能被解决，并报告给po以及或者开发主管。
在sprint结束时：
（1）进行开放式的sprint演示
（2）在演示的前一两天，就要通知到每个人
（3）与整个团队以及产品负责人一起开sprint回顾会议。开发主管也应该受邀参加，他可以把你们的经验教训大范围传播开来
（4）更新sprint数据文档，加入实际生产率和回顾会议总结出的关键点