管制也要帶來成長

一提到管制不知道大家會想到什麼，也許是國家法規、公司規章，又或是規模小一點的上下班出勤規定、工時的規定、內外部網路存取限制、通訊設備管制等，各行各業與公司都可能不同。但今天想要談的「管制」並不是單純的限制，更希望它是一種萌生於團隊之中，用來帶動成長的制度。

自我管理

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. 以身作則。