管制也要带来成长

一提到管制不知道大家会想到什麽，也许是国家法规、公司规章，又或是规模小一点的上下班出勤规定、工时的规定、内外部网路存取限制、通讯设备管制等，各行各业与公司都可能不同。但今天想要谈的「管制」并不是单纯的限制，更希望它是一种萌生於团队之中，用来带动成长的制度。

自我管理

Scrum Guide 2020 版将之前谈了一段时间自我组织(Self-Organizing) 更改为自我管理 (Self-Managing)，除了自我组织的可选择共事者(choosing who)、可决定如何做事(how to do work)，扩展到自我管理，多了「做什麽事 (what to work on)」。

单看这点可能有点抽象，我们可以再从 2020 版本更细致的变化说起，强调了一个 Scrum Team，没有子团队，也没有阶级，当下全员专注在一个产品目标上。

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

这个定议提醒了我们，不要将 Developers、Product Owner 与 Scrum Master 视为三个个体，从而避免推委与不对等。为了一致向着目标(Goal) 前进，除了决定人选、如何做事，更会需要决定「做什麽事」来实现目标。

此外，「当下全员专注在一个产品目标上」这个概念也需要注意。我的看法是，这可以展现更高的团队凝聚力、维持路径一致、沟通更为通透、加速知识的传播与减少浪费等。对於小团队而言是个不错的提醒，但对於拥有多个 Scrum Teams 的组织而言，或同时有多个产品 / 专案在执行的团队而言，可能产生一些混乱，甚至难以跟进。

自我组织

虽然已提高到「自我管理」这样更大的范筹，但在过去「自我组织」方面的概念仍然可以给我们一些启示。

敏捷原则第十一条，点出了敏捷对自我组织的重视与期待：

最佳的架构、需求与设计皆来自於能自我组织的团队。

在《Scrum 精髓：敏捷转型指南》一书中 (p.231) 是这麽说的：

团队成员自组织决定实现冲刺目标的最佳方式。没有项目经理或者其他经理告诉团队怎样开展工作 (ScrumMaster 也不该冒昧这样做)。自组织是系统自下而上、自发的属性－－没有外部的统治力量采用传统的自上而下、命令与控制的管理方式。

由於书籍是简体中文版，为保留原始样貌，部分用词请读者转换一下。自我组织强调团队使用自己的方式去实现目标，而非由管理人员介入安排，同时也不是一种放任式、无上限的自由。我们相信团队成员能够发挥所常，互补出最佳方案。

如同之前分享的文章「当责：实践篇」提到，当责应该早早展现在敏捷团队当中，自我组织亦是。作为简单的观察，我们是被动接收工作，还是主动接下来任务？在发生问题时，团队自发做了哪些应对？

管制的方向

团队多少会展现自我组织的倾向，这可能得利於 Scrum 设计的各项活动，若我们可以顺水推舟，共同塑造一个团队可以安心自主的空间，则事半功倍。

对於管理者而言，这可能包含：赋权、组织合适人员、扩大敏捷思维至其他部门/团队，以及经费预算投入等。优先确保团队是否对齐目标(Goal)，而不宜花费大量的心力监督成员的工作时间、采用什麽方法、使用什麽技术等。

为了避免误会，还是得提醒这些论述都不是非黑即白，并不是完全的二元论，而是一种倾向。

程序码审查

程序码审查 (Code Review) 是有意义的活动，但也有它的局限(後面谈)，除了站在管制的角度它可以排除品质不合格的程序码，更可以站在教育的角度，让它促进专业知识与技能的流通。

审查标准可以来自团队成员凝聚出来，或推派团队内具有公信力的成员进行定义，也可以参考网路上其他团队公开的审查标准，加以调整为适合团队的版本，但重点仍是团队成员必须认可这份标准，并且有能力执行它。

透过各程序码管理平台，如 Github / Gitlab 都对审查提供了不错的支援，建议还没有这麽做的团队赶紧尝试看看。

那麽局限在哪？在於 Code Review 是发生在程序码已经被开发人员写完了，这表示大多数的时间已投入，想法已被转换为程序码，这时候做审查就会发展出几条故事线，第一是皆大欢喜，程序写法符合团队要求，合并！第二写得不合规、有缺陷、有问题，退件！第三，有问题但时间来不及，还过得去对吧，先合并再说。

完成的定义

接触 Scrum 的朋友应该不陌生，为了消除沟通落差，统一团队成员对完成的认知，团队会定义一份「完成的定义」，它的内容可能是：

• 程序码撰写完成
• 程序码已推送至 Gitlab
• 程序码必须通过 CI 检查，通过所有自动化测试
• 所有变更已通过审查
• 已部署至测试环境
• 与变更相关的文件更新已准备完成
• ……

每个团队视自己的「现况」定义出最适合的规章即可，若目前的技能尚不能支持理想的完成，可以选择退後几步，找到平衡点。

一旦这麽做，在沟通上就容易有个基准，不会再被单纯的「完成」两字带着走。前面所提的审查标准也与完成的定义有一定程度上的关联，例如要撰写相应的自动化测试、测试覆盖率的基本规范、必须以团队认可的 Coding Style 进行撰写等。

而当完成的定义再次扩充时，通常意谓着团队已经更有能力，更有自信能够在所有的开发活动实现更高规格的要求，本身也是一种成长的表现，反过来说，我们也可以用它作为起点，定期反思现况，定义成长目标。

强化自我管理

无论是程序码审查，还是完成的定义，这些制度与自主之间又会有相互扶持的关系。

而自主不是有与没有，而是程度上的差别，管理者除了发挥自己的职权，帮助团队突破困难并争取更多的资源之外，还有没有可以加强的方法呢？

我思考了一阵子，也正在尝试，分享给大家：

1. 描绘团队自我管理的理想样貌，并对照现况找出落差。
2. 与团队讨论落差，并阐述自我管理的期望。
3. 与团队约定自主的边界。
4. 赋权 (Empowerment)。
5. 过程中以教育训练、引导补足落差。
6. 以身作则。