【落叶98】“老兵聊测试”之性价比最高的敏捷落地方案
文/秋之川
这是《落叶》文集里第 98 片落叶，希望你能喜欢，不为别的，只为这份坚持。
Scrum 什么时候才能成熟到广泛应用？
这是我在2010年左右开始接触 Scrum 时问自己的一个问题，我当时的判断是：
或许这个时间点始终都不会到来，也许 Scrum 也不会成为主流的研发模型。因为企业的行业领域、价值观、现状和事业环境因素的本质差异，决定了就不会有一个像 Scrum 这样被“精确定义”的方法能普遍适用。相反，极有可能出现类似过去 XP 的情况：Scrum 及其它方法中的各种实践会被打散，不是简单地重新编排一下顺序，而是被企业零散地选择性采纳，最终形成“四不像”的研发过程。
在这个过程中，对企业现状的熟悉、对方法论的深入理解以及灵活应用的高级管理人才将有着非常重要的作用。
当初公司引入Scrum 之后，我认为最大的变化并不是每个版本的发布速度提升了多少，发布的东西多了多少，变化最大的其实是团队整体对质量的信心和工作效率提升了很多，产品、开发和测试的合作更紧密了，有效沟通时间比之前翻了好几番。
基于这个最大的变化，下面所遇到的一些问题就都不是不可克服的问题了。
1. 我们很迷茫，我们也很害怕改变！
1.1 原有的项目开发周期也是一个月，其实版本迭代已经很频繁了，为什么还要引入敏捷呢？
2.2 开发过程是比较快了，但原有瀑布流程里的沟通不多，整个团队还是按照职能一个里程碑一个里程碑的线性工作，应用敏捷之后，大家觉得沟通多了，对质量有了更多的信心。
2. Scrum 和现有流程该怎么并行和融合呢？
2.1 PRD，SPEC 和 Test Plan 等相关文档还需要保留，为了保持产品的一个延续性，这个会增加团队成员的工作量，需要在 Sprint Plan 里把工作量计算进去，同时因为 Scrum 是从一个不完善的或者说不确定的需求开始的，因为这种持续改进的特性，这些文档也应该是协同持续更新的。
2.2 一些原有里程碑，因为管理层的需要所以需要保留，这个其实冲突不大，只要在前期计划和过程监控中控制好，都不会有太多影响，再将整个 Sprint 里的某些时间节点对应到原有的里程碑上即可。
2.3 让大家看到工具的使用会有助于他们在 Sprint 中很容易地掌握自己的进度，计划自己的时间，执行完成后很容易统计自己的工作量和检查自己的效率和能力提升；
2.4 在工具使用的学习阶段，可以把这部分工作量算进计划当中，因为在敏捷团队的 Capacity 计算中，是可以包含学习量的；
3. 团队成员能力参差不齐怎么办？
3.1 自主学习，由近到远地按规划做技术储备；
3.2 结对开发，以老带新，思维互补，查漏补缺；
3.3 代码审查，黑白结合；
4. 管理层从人力资源利用效率角度要求 Scrum 团队不能固定怎么办？
4.1 铁打的营盘流水的兵和佣兵团，孰强孰弱？
4.2 团队是需要时间磨合的，一个默契度、熟悉度和认可度都很高的的团队，会有着非常高的工作效率和很强的战斗力，而且随着时间的推移，这种战斗力会呈几何级增长；
5. 项目范围总是不可避免的变化怎么应对？
5.1 Sprint Plan 的时候，预留 20% 的 Buffer，用于应对项目进行中的需求变化；
5.2 每个 User Story 都需要有相对准确的故事点评估和清晰的优先级，在做 Plan 时，不要只选同一优先级的 User Story，要选择不同优先级的 User Story，当发生范围变更风险的时候，就可以用低优先级的 User Story 去冲抵；
上面那些问题的解决方案里，不管是预留的学习时间、还是评估里的 Buffer，还是佣兵团的培养，都是不容忽视的潜在成本，甚至于有的就是沉没成本，所以对于一个公司来说，不论是初创的，还是成熟的，都不能只从单方面去研究敏捷是否适用与它，而应该从项目类型、人员结构、成本效益以及管理层的决心等多方面入手，这就不是简简单单地找个老师来给大家集体培训一下什么是敏捷，或者是找个咨询公司入场咨询个一两个月就能着手开始的事情。
时至今日，我依然坚持我的观念：是否需要引入敏捷研发，应该由问题驱动（Problem Driven）：
1. 首先要知道为什么当前的研发模式不能满足现有需求，找出真正的原因，如果组织或团队中不存在需要改进的问题，那么就没有必要一定得引入敏捷；
2、针对已知问题，一个一个地找到解决方案，再结合敏捷的思想、具体模型、方法和工具，去对现有流程做一个性价比最高的补充或改进；
3、管理层要对自己的公司/企业/组织/团队的现状和存在的问题有一个清醒的认识；
4、下面一些问题可以用于自测，仅供参考：
我们企业现在存在哪些问题？
Scrum 是否可以解决这些问题？
Scrum 是否与我们公司的管理制度和企业文化相匹配？
如果不匹配，需要我们作出多大程度的改变，是否在我们的可承受范围？
如果 Scrum 不是适合我们企业的最佳实践，那么是否可以采用混合的敏捷实践？单个方法不行，复方的行不行？西式的做法不行，中式的行不行？...
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
