At Group L, Stoffel oversees six first-rate programmers, a managerial challenge roughly comparable to herding cats.
— The Washington Post Magazine, June 9, 1985
核心概念#
本書到目前為止都在討論幫助個人成為更好的程式設計師的務實技巧。這些方法能否同樣適用於團隊？答案是響亮的「是」。成為務實個人有其優勢，但如果個人是在一個務實的團隊中工作，這些優勢會被成倍地放大。
團隊在作者的觀念中，是一個小型、大多穩定的獨立實體。五十個人不是一個團隊，那是一群人。成員不斷被抽調到其他任務、彼此不認識的組合也不是團隊——他們只是在雨中暫時共用一個公車站的陌生人。
Tip 84 - Maintain Small, Stable Teams（維持小而穩定的團隊）
務實的團隊人數不多，不超過 10-12 人。成員很少更換，大家彼此熟悉、互相信任、互相依靠。
不要容忍破窗#
品質是團隊的議題。最勤勉的開發者如果被放在一個不在乎品質的團隊中，會發現很難維持修復問題的熱忱。如果團隊積極阻止開發者花時間修復這些問題，情況會更糟。
團隊整體不應容忍破窗——那些沒人修的小瑕疵。團隊必須為產品的品質負責，支持那些理解「不要容忍破窗」哲學的開發者，並鼓勵那些尚未發現它的人。
有些團隊方法論設有「品質官」——專門負責交付品質的人。這顯然荒謬：品質只能來自所有團隊成員的個人貢獻。品質是內建的，不是外加的。
煮青蛙#
團隊比個人更容易被煮熟。人們會假設有其他人在處理某個問題，或者團隊領導已經批准了使用者要求的變更。即使是最好的團隊也可能對專案中的重大變化視而不見。
要對抗這一點：鼓勵每個人積極監控環境的變化。保持警覺，注意範圍增加、時間縮短、新增功能、新環境——任何不在原始理解中的事物。追蹤新需求的指標。團隊不需要拒絕變更，只需要意識到變更正在發生。
安排你的知識組合#
如果你的團隊認真看待改進和創新，就需要將其排入時程。不要把工作清單只留給新功能開發。團隊做的不只是新功能。一些可能的例子包括：
| 活動類型 | 說明 |
|---|---|
| 舊系統維護 | 不要把維護工作推到角落裡 |
| 流程反思與改進 | 花時間回顧什麼有效、什麼無效，然後做出改變（參見 Topic 48，The Essence of Agility） |
| 新技術實驗 | 不要只因為「大家都在用」就採用新技術。刻意用原型來評估候選技術 |
| 學習與技能提升 | 規劃團隊範圍的學習，無論是非正式的便當午餐分享還是正式的培訓 |
Tip 85 - Schedule It to Make It Happen（排入時程才能實現）
溝通團隊存在感#
團隊作為一個實體，在組織內部需要有存在感，需要清楚地與外界溝通。
優秀的專案團隊擁有獨特的個性。人們期待與他們開會，因為他們知道會看到一場準備充分的演出。他們產出的文件清晰、準確且一致。團隊用同一個聲音說話。他們甚至可能有幽默感。
為你的專案起一個有趣的名字，設計一個古怪的 logo。用它來建立團隊認同感，也給外界一個容易記住且聯想到你們工作的東西。
不要重複你自己#
在 Topic 9 DRY 中，我們討論了消除團隊成員之間重複工作的困難。這種重複會導致浪費的努力和維護的噩夢。好的溝通是避免這些問題的關鍵。所謂的「好」，是指即時和無摩擦。
你應該能夠向團隊成員提問並幾乎立即得到回覆。維持覺察以保持 DRY。
團隊曳光彈#
一個專案團隊必須在專案的不同領域完成許多不同的任務，觸及許多不同的技術。但常見的誤解是這些活動和任務可以分別、孤立地進行。它們不能。
有些方法論倡導各種不同的角色和頭銜，或建立獨立的專業團隊。但這種做法引入了關卡（gates）和交接（handoffs），而非流暢的工作流程。Lean 的人們稱這為浪費（waste），並努力消除它。
使用 Topic 12 Tracer Bullets 的方法，開發小型但端到端的功能，涵蓋前端、伺服器、DBA、QA 等所有技能。這讓你能快速獲得團隊溝通和交付能力的即時回饋。
Tip 86 - Organize Fully Functional Teams（組織功能完整的團隊）
建立團隊使你可以端到端地、增量地、迭代地建構程式碼。
自動化#
確保一致性和準確性的最好方法是自動化團隊做的一切。為什麼在編輯器或 IDE 可以自動幫你格式化時還要糾結程式碼格式標準？為什麼在持續建構可以自動跑測試時還要手動測試？為什麼在自動化可以每次都以相同方式、可重複且可靠地部署時還要手動部署？
自動化是每個專案團隊的必要組成部分。確保團隊有工具建構（tool building）的技能，來建構和部署自動化開發和生產部署的工具。
知道何時停止塗漆#
記住團隊是由個人組成的。給每個成員能力以自己的方式發光。給他們剛好足夠的結構來支持他們並確保專案交付價值。然後，就像 Topic 5 Good-Enough Software 中的畫家一樣，抵抗添加更多油漆的誘惑。
相關章節#
- Topic 2，貓吃了我的原始碼
- Topic 7，溝通
- Topic 12，曳光彈
- Topic 19，版本控制
- Topic 50，不要切開椰子
- Topic 51，務實的上手工具