硝烟中的Scrum和XP-我们如何实施Scrum 14)测试 15)多团队 Part 1/2
14 怎样做测试
这是最困难的部分; 在不同组织的各种开发活动中, 测试可能是差异最大的; 它依赖于你有多少个测试人员, 系统类型(服务器+web应用 vs 交付完整的软件), 发布周期的长短, 软件的重要性(博客服务器 vs 飞行控制系统)等等;
验收测试阶段
在理想化的Scrum世界中, 每个sprint最终会产生一个可部署的系统版本; 但一般都无法达到, bug的出现会影响质量, 应该进行验收测试;
团队外的专职测试人员会用测试来攻击系统, 这些测试要么是Scrum团队考虑不到, 要么没有时间完成, 或是限于硬件条件无法完成; 测试人员会采取和终端用户一样的方式来操作系统, 进行手工测试;
测试团队会发现bug, Scrum团队就得发布针对bug修复的版本, 或早或晚为终端用户发布修复bug的1.0.1版本, 而不是问题很多的1.0.0版本;[看质量情况而定, 越早越好]
验收测试结对是指整个测试, 调试, 重新发布阶段, 直到得到可以用来做产品发布的版本为止; [release~~]
把验收测试阶段缩到最短
验收测试阶段让人觉得不太敏捷[是因为测试太烦人了么...]; 我们不能逃避这个阶段, 但可以想办法缩短时间;
把需要花在验收测试阶段的时间减少:
- 全力提高Scrum团队交付的代码质量;
- 全力提高人工测试工作的效率(最好的测试人员, 最好的工具, 确保他们上报那些耗费时间却能被自动化完成的工作)
提高Scrum团队交付代码的质量:
- 把测试人员放到Scrum团队中;
- 每个sprint少做点工作;
把测试人员放到Scrum团队来提高质量
对立意见:
- Scrum团队应该是跨职能的;
- Scrum团队应该是没有角色的, 不能把只做测试的人放到里面;
这里的测试人员指的是"主要技能是测试的人", 不是"只做测试的人"; 开发人员常常是差劲的测试人员, 尤其是测试自己代码的时候;
测试人员就是"验收的家伙"
除了是个团队成员以外, 测试人员有个重要的工作--负责验收; 测试没说完成, 就不能算完成;
开发人员常常说一些工作已经完成了, 但事实并非如此; 即使你有一个很明确的对"Done"的定义, 开发人员也会经常忘掉; 编程人员一心想着尽快去做下一个任务时 , 可能就缺乏耐心;
测试人员怎么知道事情已经完成: 首先, 他们要做测试; 经常发现, 开发人员认为完成的工作, 根本无法测试; 原因包括代码没提交, 没有部署到测试服务器等等; 一旦QA开始测试这个特性, 它就应该和开发一起浏览一遍"Done"检查列表; e.g. 在"Done"的定义中写着要有版本说明, 那QA就要去检查; 如果有正式的规范说明, 就要按照规范检查;
角色 这样团队中就有了这样的人选, 适合担当组织sprint演示的职责;
如果还没有任何事情需要测试, 测试人员应该做什么?
经常出现的情况是目前还没有或者已经没有东西需要测试, 例如团队需要一周才能完成第一个US, 那这段时间测试应该做什么?
为测试做准备; 包括编写测试规范, 准备测试环境等等; 开发人员有开发完的功能可供测试以后, 就可以立刻开始测试;
如果团队在做TDD, 从第一天开始大家都会花时间来编写测试代码, 测试人员应该跟编写测试代码的开发人员一起结对编程, 即使测试不懂编程, 也可以和开发结对, 好的测试人员常常能想出多种不同类型的测试, 给Dev提供互补 [有时候QA不具备或不适合这个模式, 把test case给DEV就可以了];
如果团队没有实施TDD, 或者没有足够的测试用例需要编写, 那测试人员可以去随意做一些能够帮助团队达成sprint目标的事情; 如果测试会编程, 那样最好, 如果不会, 就找出sprint中需要完成的,不用编程的工作; [记忆中sprint里有这样的事情, 但大多是scrum master或PO来cover, 比如需求确认, 和PD或客户讨论需求, 确定spec; QA能参与的应该是细节层面的, 在task进行时会遇到]
在sprint计划会仪中, 进行到拆分故事阶段, 团队会把注意力放在编程性的任务上, 但一般在sprint中会有很多非编程性任务需要完成; 如果sprint计划阶段花上一些时间来找出非编程性任务, 测试就有机会在不会编程, 没有测试任务的情况下做出大量贡献[对team的合作要求比较高];
e.g. sprint中需要完成的非编程性任务:
- 搭建测试环境;
- 明确需求;
- 与运营部门讨论部署的操作细节;
- 编写部署文档(版本说明, RFC, requset for comments需求修正意见书, 或者任何在组织中要写的东西)
- 与外界的资源进行联系 (例如GUI设计师)
- 改进构建脚本;
- 将故事进一步拆分成任务;
- 标识出来自开发人员的核心问题, 并帮助解决这些问题;
从另一个角度来看, 如果测试成了瓶颈该怎么办? 假设在sprint最后一天突然完成了很多工作, 测试没有时间测试完所有的事情该怎么办? 可以把团队中的所有人都分配给测试当作助手; 他决定哪些事情自己来做, 把一些烦人的测试交给团队中的其他人来做; 这就是跨职能团队完成的事情; [这是不良sprint的补救措施, 从源头来看应该避免这种情况, 尽量将高优先级的US在sprint中期完成,在planning时候就预计哪些US要尽量在sprint中早些完成]
测试确实在团队中有一个特定的角色, 不过他仍然可以做其他工作, 团队其他成员也可以帮助做他的工作;
在每个sprint中少做工作来提高质量
回到sprint计划会议上; 简单来说, 被把太多US都放到sprint里面; 如果碰到质量问题, 或者验收测试周期太长, 干脆就每个sprint少干点; 这会自动带来质量提升, 验收测试周期缩短, 影响终端用户的bug减少, 并且在短期内得到更高的生产力; 因为团队可以始终关注于新的东西, 而不是不断修复出现问题的旧功能; [前提是团队成员的自觉性或者sprint工作安排的合理性]
相对于构建大量功能, 然后不得不在惊慌失措的状态下做HotFix来说, 少构建一些功能, 做的稳定强健些更合算;
验收测试应该作为sprint的一部分么?
有些团队没有把验收测试当作sprint的一部分, 有些没有, 原因有2点:
- sprint是有时间盒限制的; 验收测试(包括调试和再次发布)的时间很难固定; 如果时间用完, 还有严重的bug该怎么办? 带着严重bug交付上线, 还是等到下个sprint? 大多数情况下, 这两种方案都是不可接受的; 所以会把人工验收测试排除在外;
- 如果有多个团队开发同一个产品, 就要等到所有团队的工作成果合并以后, 在进行人工验收测试; 如果每个团队都在sprint中进行人工验收测试, 最好还是要有一个团队测试最终版本, 这个版本集成了全部团队的工作;
不算完美的解决方案, 但可以满足大多数情况的需要; [把测试放到sprint外面并不是积极的做法, 但对于复杂的产品线, 可能是比较简单的解决方案]
Sprint周期 vs 验收测试周期
在完美的Scrum世界中, 不需要验收测试阶段, 因为每个Scrum团队在每个sprint结束以后, 都会发布一个新的可供产品化的版本;
符合实际的情况是:
在sprint1之后, 得到了满是bug的1.0.0版本; 在sprint2中, bug报告开始涌入, 团队花了大部分的时间来进行调试, 被迫在sprint的中期发布了修复bug的1.0.1版本; 到了sprint2末尾, 发布1.1.0版本提供一些新特性; 但是bug的数量有增无减, 因为从上一个版本发布就一直被bug困扰, 能够用来保证代码质量的时间就更少, 变成恶心循环;
sprint2中的红色斜线表示出了混乱的存在;
即使有验收测试团队, 问题仍然存在; 区别在于, 后者的大多数bug报告来自测试团队, 而不是生气的用户; 从商业视角来看二者有很大差别, 对开发而言却没多少不同; 只是测试人员通常没有用户那么强势; [会强势的和Dev说bug, 口气好像用户的一定是新QA]
没有完美的解决方案, 重点还是提高Scrum团队发布的代码质量; 在sprint中级早发现并修复bug, 要比sprint结束后再这样做代价小得多;
实际情况中, 无论如何减少bug数量, 在sprint结束后还是会有bug被报告出来, 解决的方法:
方式1 在旧版本可以产品化之前, 不构建新特性
如果这样做的话, 就要在sprint之间添加一个无时间限制的发布阶段, 这个时期内只能进行测试和调试, 知道可以做出产品发布为止;
这样会破坏sprint的节奏, [Scrum团队之间也无法做到同步], 它也没法根除问题, 即使有发布阶段, 依然会出现紧急的bug报告, 团队依然要时刻做好准备;
方式2 开始构建新东西, 但要给'将旧功能产品化'分配高优先级
一般完成一个sprint后就会开始下一个; 但是我们会在接下来的sprint中花时间解决过往sprint留下的bug; 如果修复bug占用太多时间, 导致接下去的sprint遭到破坏, 就需要分析问题产生的原因, 讨论如何提高质量; 确保sprint的长度, 使之足以完成对上个sprint中一定数量bug的修复; [高优先级bug]
随着时间推移, 修复上个sprint遗留bug所用的时间会减少[对于安排合理的sprint来说, 反之会变多]; 当bug发生, 牵涉的人相对变少, 不会总是干扰整个团队; [系统级别的bug变少, 功能级别的由不同的US分类] 这个做法得到更多人认同;
sprint计划会议上, 考虑到会花时间修复上个sprint的bug, 可以把投入程度设低; 经过一段时间实践, 团队在估算方面应该比较准确; 生产率也会起到帮助作用;
糟糕的方式--只关注构建新东西
"只关注构建新东西, 没有把旧的产品化" [和任务压力有关, 产出和质量的平衡]
很多经理都不能真正理解: 即使所有的编程活动都已经完成, 距离产品发布还有很遥远的距离(复杂的系统); 所以经理或PO要求团队继续增加新特性, 而手中那些"差不多可以发布"的代码会越来越多, 整个工作的速度会因此变慢;
别把最慢的一环逼得太紧
假设验收测试是最慢的一环, 因为测试人员稀缺, 或者低劣的代码质量造成过长的验收测试周期;
假设验收测试团队每周最多测试3个feature(不要拿"每周测试的特性数量"来度量, 这里只是举例), 而开发每周能开发6个feature; 经理或PO(甚至团队)会觉得可以安排每周开发6个特性;
实际上, 应该安排每周只完成3个特性, 多余时间用来攻克测试瓶颈 e.g.
1) 让一些开发人员做测试人员的工作 (他们会因此爱你的...) [脑残么? DEV才不要做测试里的重复性工作]
2) 实现一些工具或脚本, 用来简化测试工作 [这才是DEV或QA该尽快做的]
3) 增加个更多的自动化测试代码;
4) 延长sprint长度, 把验收测试放到sprint里面来; [除非是个独立团队, 否则上层领导为了统一管理才不会同意]
5) 把一些sprint定义为"测试sprint", 整个团队都作为验收测试团队进行工作;
6) 雇佣更多测试人员 (意味着减少开发人员)
最好的长期解决方案是2) 3), 更好的工具和脚本, 测试自动化; retrospective meeting可以帮助识别出最慢的环节;
回到现实
理想的方式是: 所有的Scrum团队都有测试人员[或足够的测试], 每个产品都有大规模的验收测试团队, 每个sprint结束之后都会有发布...;
---测试 End---
15 怎样管理多个Scrum团队
多个Scrum团队开发同一个产品的状况下, 很多事情都会变得复杂棘手; 这个问题普遍存在, 和Scrum没多大关系: 更多开发=更多复杂情况; [最明显的是dependence]
核心问题是: - 要创建多少个团队; - 如何把人员分配到各个团队中;
创建多少个团队
为什么不把所有人放到一个团队中?
e.g. 曾经单个Scrum团队包括11个人, 大家一起工作但是效果不好; daily meeting会超过15分钟; 每个人都不是完全清楚其他人在做什么, 整个状态有些乱; SM很难保证每个人都在向同一个目标努力, 也没有时间来解决发现的所有问题;
如果是把大团队分成两个团队, 这样做情况未必好转:
如果这个团队在实施Scrum方面很有经验, 习惯这种做法, 而且能够以符合其内在逻辑的方式切分产品, 把它分成两个独立的部分, 保证各自的源代码不会重叠, 那分割团队是一个好主意; 否则反而造成很多问题; 宁可团队数量少, 人数多, 比起一大堆互相干扰的小团队的模式要强;
Note 要拆分团队, 必须确保他们之间不会产生互相干扰;
虚拟团队
在"大团队"和"多团队"之间权衡利弊之后, 做出决策, 但如何知道决策是否正确? e.g.
1) 选择"大团队"; 观察sprint中的交流方式, 事实上大团队可能自动会分成两个子团队;
2) 选择使用3个小团队; 观察sprint中的交流方式, 可能会发现团队1和团队2一直有交流, 而团队3比较孤立;
如果虚拟团队一直以这样的形式保持着, 那可能是决策错误了; 如果只是暂时的, 那没问题;
如果1)中两个虚拟的子团队一直变化(大家在虚拟团队中轮换位置), 那他们作为一个团队没有问题; 如果两个虚拟团队在sprint中保持分割的状态, 那下个sprint需要考虑把他们真正分成两个Scrum团队;
如果2)中的团队1和团队2在sprint中一直聊来聊去(团队3被晾在一边), 那下个sprint就需要考虑把团队1和团队2合并成一个Scrum团队; 如果团队1在sprint开始时和团队2一直交流, 在后半段又和团队3聊得起劲, 那合并或者保持原样都可以考虑; 可以在回顾会议上提出问题, 让团队自己决定;
在Scrum中, 团队分割确实很难; 不用花太大精力做这方面优化; 先做实验, 观察虚拟团队, 然后确保在回顾会议上有足够的时间来讨论这些问题; 最后找到针对所在环境适合的解决方案; 重点是, 必须要让团队对所处的环境感到舒适, 不会互相干扰;
最佳的团队尺寸
5-9人是公认最佳的团队构成人数; (3-8也许也挺好) [根据所开发的项目类型而定] (假设有一个10人的Scrum团队, 考虑一下把最差的两个移出去)
假设有两个不同的产品, 每个产品由一个3人团队负责, 进度很慢; 也许可以合并成6人团队, 同事负责两个产品, 把其中一个PO移出(或者担当顾问之类的角色)
假设团队有12个人, 因为代码库很差, 所以两个团队无法独立在上面工作; 应该认真投入时间, 精力修复代码库(而不是引入新特性), 直到适合拆分团队为止; 这样的投资很快将得到回报; [之后的工作效率]
是否同步多个Sprint
假设有3个Scrum团队开发同一个产品, 他们的sprint应该同步还是交叉覆盖?
交叉覆盖:
看上去不错; 但是在任何一个给定的时间点上, 都有一个进行中的sprint接近结束, 新的sprint即将开始; PO的工作负担会随着时间推移逐步摊开; [APO area product owner] 各个版本realease, 每周都有演示...
同步进行:
优点:
- 可以利用sprint之间的时间来重新组织团队, 如果是重叠的sprint团队, 就必须打断或影响其他sprint的进程;
- 所有团队在一个sprint中向同一个目标努力, 可以有更好的协作;
- 更小的管理压力, 更少的sprint计划会议, sprint演示和发布; [Planning应该区别不大, 都需要各自安排, 但对于APO的调度有帮助]
---TBC---
