流程, 敏捷实践 (框架), 团队成员的三边关系

前言:

流程是轨道, 敏捷实践 (框架) 是行驶在这轨道上的火车, 团队成员便乘著这列火车, 迈向版本交付的终点◦

本文:

企业内推行敏捷变革时, 往往将敏捷中的实践 (框架); 如: 站立会议, 回顾会议等, 以制订流程的方式, 在团队中规范站立会议, 回顾会议的责任人, 责任人应负责的工作, 预期的结果◦

这样的思维与作法, 使企业内的产品团队成员, 往往将敏捷中的实践 (框架) 当成是企业内制式的流程活动, 而使敏捷在团队中流于形式◦丧失了团队可经由敏捷实践(框架), 提升团队成员的自我任务管理, 自我不断改善效率与质量的本意与功能◦

然而在大型企业内, 假如缺乏了流程的规范, 各产品团队即使执行了种种的敏捷实践  (框架), 企业内也无法保证团队最终版本交付的质量◦ 因为, 各产品团队执行的都是 “团队自定义” 的敏捷实践 (框架); 各产品团队执行的往往都是 “便宜行事” 的敏捷实践 (框架); 各产品团队执行的往往都是“裸奔”; 只有交付的 “效率”, 却丝毫看不到交付的 “质量” 与 “品味”◦

所以, 企业内该如何制订流程? 而使流程既能兼顾 “规范”, 又不致扼杀了敏捷实践 (框架) 的本意与功能?

黄金的规则是:

“企业内的流程应专注于产品开发过程的规范,而不是专注在敏捷的实践 (框架)上◦”

产品开发的过程包含:

• 产品级的特性识别
• 产品级的架构设计
• 版本级的需求分析
• 版本级的软件设计
• 开发
• 测试
• 发布
• 运维
• 项目管理
• 变更管理
• 配置管理

企业内的流程应只专注于上述的产品开发的过程, 制订明确的目标, 责任人, 各过程的进入条件, 离开条件; 但真正的重点是:

企业内的流程不应包含产品开发过程内的 “活动”◦

产品开发过程内的 “活动”,应由产品团队的 ScrumMaster,依照项目版本的背景, 团队成员的现况,选定适合的敏捷实践 (框架)所构成◦

敏捷实践 (框架) 可包含:

• Scrum
• LeSS
• SAFe
• Kanban
• 测试驱动开发
• 行为驱动开发
• 验收测试驱动开发
• 领域驱动设计
•  探索性测试
•  敏捷测试
•  演进式架构……. 等等◦

所以, 产品团队便会在各产品开发的过程, 执行能提升团队成员的自我任务管理, 自我不断改善效率与质量的敏捷实践 (框架), 并确保产品团队在产品开发的过程中可符合企业内流程的规范; 符合各产品开发过程的目标, 责任人, 各过程的进入条件, 离开条件上的要求◦

结论:

将企业内的流程与产品团队开发的实践隔离, 将使企业内的流程更能适配各种不同的敏捷实践 (框架), 而产品团队在执行适合自身的敏捷实践 (框架) 的同时, 亦能确保产品团队的版本开发过程与产出均能符合企业内部的流程规范◦