Scrum 转型过程中的常见误区总结

Posted 2021-04-25 江湖菜籽

开篇入题，越来越多的互联网科技公司在执行 Scrum 敏捷开发流程，或者正在进行敏捷转型，旨在：

• 增强应对需求变更的能力（要求雄厚的技术支持，实现最小化架构设计并不断演进）；

• 提高团队的交付效率（明确团队交付速率，对用户交付敏捷）；

• 提升项目的可视化程度（提供量化指标进行度量和跟踪）；

1 Scrum 执行问题

我本人以及团队也在尝试，不过执行过程始终摆脱不了“瀑布式”的影子，具体表现就是“船货膜拜”：

1.1 产品 Backlog

1. 团队在敏捷转型过程中很容易将敏捷定位为绩效考核的工具，团队成员纯粹为了 Backlog 里面的用户故事和任务而产出，却不探究 Backlog 背后的用户目的，团队成了狭隘的“任务机器”；

2. 产品 Backlog 定义未达到“就绪”要求，频繁在 Sprint 过程中“创造变化”，这就需要对 Backlog 定义 DoR 检查项，包括：

• 已经明确并文档化用户故事；

• 用户故事已经具备技术可行性；

• 用户故事满足 INVERT 原则（独立的、可协商的、对用户有价值的、可估算的、小粒度的、可测试的）；

• 用户故事的优先级已经排好；

• 用户故事已经具备参考文档并且被团队所熟悉；

• 用户故事里有对接受条件的描述；

• 已经明确了依赖关系；

• 已经估算了用户故事点数，并且大小在一个 Sprint 完成；

1.2 站会

每天召开站会，但是没有进行密切协作和自组织。

僵化的站会团队成员依次陈述“我昨天做了什么”“我今天要做什么”以及“我遇到了什么障碍”，俨然成为汇报工作的流程；

切记站会的目的是沟通问题并解决障碍，建议改为“我今天要做什么”“我遇到了什么障碍”以及“我的任务有什么风险”。

1.3 计划会

每个迭代都有计划会，但是仍然存在连续多个 Sprint 都在同一个用户故事上投入人力的情况，一方面是 Backlog 定义沟通问题，另一方面是团队执行力完成的问题。

再次强调计划会议步骤：

- 产品负责人要陈述 Sprint 目标，讲清用户故事的 WHO、WHAT、WHY、HOW、ACCEPT 等要素；
- 产品负责人澄清产品需求，团队对用户故事达成一致的理解；
- 团队估算完成用户故事所需故事点数；
- 团队选取 Sprint Backlog，调整 Sprint 目标；
- 拆分任务，粒度控制在一天内可完成；
- 判断 Sprint Backlog 是否达到产能上限；
- 承诺目标，团队必须对目标清晰并且有信心；

1.4 评审会

每个迭代都有评审会，但是没有可交付的产品增量；

这就要求团队协商定义清晰“完成”的标准，比如 DoD 检查项，包括：

- 完成需求设计评审
- 通过代码评审
- 完成单元测试
- 完成集成测试
- 通过功能测试
- 通过自动化回归测试
- 通过产品负责人验收
- 更新用户帮助手册等文档

1.4 回顾会

1. 每个迭代都有回顾会，但是团队的流程、效率增量、协作等都没有得到实质性的改进；

2. 回顾会不是“反思会”，不是来吐槽说问题的会议，这样会给团队造成一个负面的场域；

3. 回顾会不是“总结会”，不是给领导汇报工作的总结；

4. 回顾会是对 Sprint 过程中团队、对外关系、过程和工具等方面的检视；

5. 回顾会可以罗列 Sprint 里发生过的事件， 找到做的好的地方和需要改进的地方，并决定改进措施，以便团队持续改进，可以通过 SSCC 框架进行改进意见管理，Start、Stop、Continue、Change；

6. 回顾会可以收集客观的度量数据，比如团队的速率、Sprint 燃尽图走势以及版本燃尽图趋势等；

1.5 其他问题

• 积极进行各种工程性实践，但多属于应付差事，没有起到实质性作用；

• 还是存在所谓的“负责人”指挥团队怎么工作，选什么方案，甚至用什么技术；

• “领导”依旧问团队要周报、日报这种旧的度量体系来衡量团队的工作进度；

2 拥抱变化

团队要认识到敏捷是积极的拥抱变化，不是完美的执行计划之后发现是一个“完美的失败”，拥抱变化需要提升：

2.1 高效的沟通

2. 其次，敏捷不要求文档，但是团队要记住“软件工程是一门文档的艺术”，所以不要拿敏捷当做你放飞自我的挡箭牌；

2.2 良好的设计

敏捷的过程要求可持续的开发，基础是团队坚持不懈的追求技术卓越和良好设计，响应变化如果等同于重构，那将是灾难性的产出；

2.3 组织文化支持

1. 团队内部配置教练型领导，而不是命令控制型领导；

2. 敏捷是以人为中心的，控制型管理将碰到更多的摩擦。管理人员常见的误区比如“我的要求是”，“什么都要经过我的同意”，“技术栈必须要统一”等；

3. 团队组织文化以人为中心，相应的面向现实的为协作型文化，面向未来的为培养型文化，既要脚踏实地，又要放眼未来；

3 敏捷的进阶

第一阶段为团队级别的敏捷，第二阶段为产品级敏捷，最后才是文化级敏捷，对于转型的企业首先做好团队和产品级就足够，我们可以做一个最佳实践检查项，正在执行的团队可以对号入座：

•  Scrum 或者看板；

•  持续集成；

•  涌现式架构设计；

•  领域驱动开发 DDD；

•  行为驱动开发 BDD；

•  自动化测试；

•  结对编程；

•  测试驱动开发 TDD；

•  微服务；

•  持续交付流水线；

•  自动化运维；

•  价值流映射

•  精益看板方法

•  投资组合规划和管理

•  ART 的组织架构及其流程

•  Scrum of Scrums。

4 选择产品负责人

对于如何选择产品负责人问题，产品负责人不仅负责把产品送上市，还要管理产品的整个生命周期，同样提供责任检查项供参考：

•  建立产品愿景；

•  与内部和外部利益干系人、团队一起规划产品发布；

•  在Scrum 团队代表内部和外部利益干系人的声音；

•  管理产品的待办事项列表，不仅要清晰的表述，还要进行优先级排序，并确保团队深入了解；