第十四章 我们怎么进行
测试
测试实际上是软件中最困难的一个环节。能影响测试的环节太多了，质量要求，流程规范，性能指标，时间，类型，资源等等都会对测试产生极大的影响。
看看作者认可的一种方法：
1. 理想化的Scrum中，每个sprint都有一个可测试的版本发布出来，实际情况是：不
2. 所以验收测试是必须的，不能跳过
3. 那么要做的是减少验收测试的消耗
1）提高开发的代码交付质量（我的团队是多做
单元测试，而且集成测试时开发人员要执行测试人员书写的很多手工
测试用例）
2）提高效率。要么是用最好的人（经验丰富，能力强，但是成本高），或是用各种工具（依赖性强，成本高，覆盖率有限）
3）测试人员参与到Scrum团队中（现在测试人员究竟是全部独立，还是全部在团队中，还是混合方式，都是有优缺点的，只能根据你团队的具体情况进行选择）
4）减少每个sprint的故事数量（很多时候都是硬塞新的，不可能为了保证质量减少数量，所以更有效的方法是回归实用自动化工具，新功能还是手工）
5）加强代码审核和互测机制，结对编程也有助于提高质量
测试是负责验收的，产品验收反而流于形式。
测试基本上充当了做Demo的主力。
没东西可测试的时候，测试的
工作是要做很多测试准备，比如测试用例编写，审核，测试环境搭建，测试数据准备。如果还没事干，不妨试试，让测试人员和开发人员结对，讨论开发人员实现的代码。
实际上测试人员不单单是个点点点的人，他有很多非本职觉得事情可以做：
1.测试环境的搭建
2.去和产品负责人明确需求
3.与运营部门讨论部署的具体细节
4.编写各种文档
5.协调资源
6.改进流程和规范
7.将故事拆分为场景，从而促生出合理的任务集
8.收集开发人员的问题，并协助解决
听起来，测试人员成了“测试驱动开发”的完美实践者，甚至起了担当了部分团队管理者的角色
其实，如果你能足够的强势，在每个sprint里做合理量的任务，才是最终解决测试质量的问题
验收测试到底包含在当前sprint中不？
（这是一个争论已久的话题，有些团队喜欢包含，有些团队不喜欢包含。甚至我的团队会专门有个测试的sprint存在。）
大部分团队不喜欢包含的原因是：
1）sprint有时间限制，但是测试未必能严格按照时间完成，因为缺陷不等人。
2）很多sprint没有可交付测试的内容
3）有很多产品是多个sprint团队进行并发开发，需要都开发完后，集成完毕才能开始测试
所以大家喜欢在当前sprint里添加新的需求，同时修改上个sprint出现的问题，那么意味着，产品不能立刻发布，需要延迟发布。
我们是有一个专门的团队进行验收sprint，里面包含了开发和测试。但是成本很高。
有些是几个开发sprint，然后跟一个专门进行缺陷修复的sprint，集中解决，这取决于你的交付计划是不是允许。
最糟糕的情况是，你的团队不得不始终去关注新功能，而无暇进行缺陷修复，这个时候，就只能要求代码质量控制的很好才行，否则就是一个千疮百孔的垃圾产品
所以既然是一个团队，就需要考虑一下如下的可能：
1. 安排一些测试任务给开发人员
2. 简化一下测试的流程
3. 减少测试反复的次数
4. 开发一些测试工具来提高效率
5. 增多更多的自动化脚本
6. 自动化的覆盖度和深度更强
7. 延长sprint的长度
8. 定义个专门测试的sprint
9. 雇佣更多的测试人员，设置个资源池，然后各个团队复用
第十五章 怎么管理多个sprint团队
团队越多，管理越复杂，scrum不可能简单的将管理弄的轻易化。
那多少个团队合适，每个团队的人员怎么安排呢？
我的经验是，一个产品有一个大团队，然后设置一些虚拟组织（虚拟团队）
例如，产品，开发，UI，前端，测试，运维都属于一个产品团队。 其中产品虚拟团队，开发虚拟团队，测试虚拟团队等等都存在。 这样能解决一个人要听两个人的指挥，也能解决我没有个自己的圈子去协作。
至于实体团队和虚拟团队怎么分配，还是得看你自己的选择，你怎么能让他们有效的运转起来，就行。
那么很多时候超过20个人的大团队也必须分配成几个实体小团队。每个小团队的人数最好不要低于3个，不要超过10个。
我喜欢3个一组的小unit，一个中级的带两个初级的，很有效率。 每个团队都是由这一个个小unit组成。
而且团队也不是一成不变的，要随时拆分，随时合并，当然是根据情况而来。
同时进行多个sprint也可以，但是前提是相互之间没有干扰。
而且，同步开发的时候，要保证2，3个sprint后你有机会进行一次团队重组。
每个团队，要有一个负责人，但是不是管理者，确切的说是沟通者，这个领导代表整个团队跟其他团队沟通。
我们的做法是设置了一个委员会，其实就是各个团队的负责人坐在一起协调资源。
是否有保持一个特定的团队，也需要斟酌，比如专门做服务器后台的团队。稳定和高效，以及轮换和机遇永远是个针锋相对的话题。
可能的情况是：一个固定模块的团队；一个跨多个模块，但是固定组件的团队。
还有一种可能是，你会有个一些人在多个团队里做兼职。
甚至，你还需要准备一个救火团队以备不时只需。
多个团队的话，还涉及到联席会议，可以像我们一样弄个委员会，也有可能是一个更高级别的管理团队。
如果你要自己控制多个团队，那么交错的开会是必须滴。
多个团队的时候，是否拆分backlog。在一个大的产品的情况下，这是很正常的，拆与不拆，还得取决于你的团队设置。如果你还保留了一个专门的产品团队，那么一个产品负责人和这个产品团队沟通就行，不用拆。
如果需要设置多个产品负责人，最好还是拆吧。
一个产品负责人如果负责多个产品backlog，那么我觉得你应该合并产品。
多个团队对代码分支的要求也比较严格一些：
1. 主分支永远要保持稳定
2. 每个版本都有tag
3. 只有必要的时候才创建分支，使用完毕后要合并
4. 分支用于区分不同的产品生命周期
5. 要经常同步
多团队的回顾更是有必要。
