本章涵蓋誓言中與團隊合作相關的承諾：互相補位、誠實估算、尊重同儕、以及永不停止學習。

Work as a Team（團隊合作）#

Promise 7. I will continuously ensure that others can cover for me and that I can cover for them.

將知識隔離在**孤島（Silos）**中對團隊和組織極其有害：

• 失去一個人可能意味著失去整個知識區塊，癱瘓團隊與組織
• 孤島中的成員缺乏足夠的上下文來理解彼此，經常雞同鴨講
• 解藥是在團隊中散播知識——確保每位成員都了解其他成員正在做的工作
• 最佳方式：一起工作——結對（Pair）或群組（Mob）程式設計

提升團隊生產力最有效的方式之一就是實踐協作程式設計。一個了解工作之間深層關聯的團隊，必然比一群孤島更有生產力。

Open / Virtual Office（開放/虛擬辦公室）#

團隊成員需要頻繁地看見彼此並互動：

• 實體團隊室：作者在 2000 年代初經營 Agile 顧問公司時，要求客戶重新安排辦公空間。有時光是把團隊放在同一個房間，生產力就已經明顯提升
• 遠端工作：遠端工作永遠無法像同一房間工作那樣有效率，但現代協作工具已經相當成熟。遠端團隊應該：
  • 建立虛擬團隊室，保持每個人的畫面可見、音訊通道盡可能開放
  • 盡量維持相同的工作時段——至少確保每天有六小時的共同在線時間
  • 保持團隊內的時區差異盡可能小

擋風玻璃效應（Windshield Effect）：

• 開車時很容易對其他駕駛發火——隔著擋風玻璃看人，容易將他們去人性化
• 同樣的效應在電腦螢幕後也會發生（程度較輕）
• 解決方法：團隊每年應實體聚會數次，作者建議每季一週。與兩週前一起吃過午飯、一起寫過程式碼的人，很難落入擋風玻璃陷阱

Estimate Honestly and Fairly（誠實公正地估算）#

Promise 8. I will produce estimates that are honest in both magnitude and precision. I will not make promises without reasonable certainty.

估算是每個軟體開發者的基本技能，但大多數人都做得很差。估算能力不足已導致程式設計師與業務端之間幾乎災難性的信任崩塌。

Lies（謊言）#

大多數估算是謊言，因為它們是從已知的截止日期倒推出來的：

• HealthCare.gov 的案例：美國總統簽署法案，以法律規定系統上線日期。沒有人被詢問估算——他們只是被告知截止日期
• 在這種環境下，估算只是支持計畫的謊言

Honesty, Accuracy, Precision（誠實、準確、精確）#

估算最重要的面向是誠實。最誠實的估算是什麼？——「我不知道。」但這不夠準確或精確。挑戰在於量化你知道和不知道的部分。

• 準確（Accurate）：給出一個你有信心的日期範圍，而非單一日期
• 精確（Precise）：將範圍縮小到你的信心水準
• 兩者都需要殘酷的誠實

兩個故事說明估算的巨大誤差範圍#

故事 1：Vectors

• 1978 年，作者在 Teradyne 為 COLT（一種電話公司的測試設備）開發韌體
• 處理器是 Intel 8085，32K RAM + 32K ROM（32 顆 1K 的 ROM 晶片）
• 每次修改一行程式碼就要重新燒錄全部 32 顆晶片，並寄送給全球的維修人員
• 老闆要求讓每顆晶片可獨立部署
• 作者估算 2 週，實際花了 12 週——偏差 6 倍

故事 2：pCCU

• 1980 年代初，公司承諾客戶交付 CCU-CMU 產品，預估需要一人年
• 突然有一個小客戶需要在一個月內交付
• 因為該客戶的配置極其簡單，消除了幾乎所有複雜性
• 結果作者在 2 週內完成——只用了預期的 二十分之一 時間

這兩個故事說明了估算可能的巨大範圍：一方面可能低估 6 倍，另一方面可能在預期時間的二十分之一內完成。這就是為什麼估算是一項如此困難的挑戰。

Accuracy（準確性）#

估算不是日期，估算是範圍，估算是機率分佈。

• 使用 Work Breakdown Structure（WBS，工作分解結構）：將大任務拆解為子任務，遞迴地估算每個子任務的平均完成時間
• 問題：我們不擅長識別所有的子任務——通常會遺漏約一半
• 補償方式：將總和乘以 2 到 4 倍的修正係數（Fudge Factor）
• 管理者會要求你降低修正係數，你可以透過更詳細的 WBS 來改善，但要警告他們：完整 WBS 的成本等同於完成專案本身
• 葉節點的估算通常靠直覺——與已完成的類似任務比較

Precision（精確性）#

每個估算都是錯的——否則它就不是估算，而是事實。重點在於估算「估算有多錯」：

這三個數字構成一個常態分佈（機率分佈）——這才是你的真正估算。

如果你的估算是一個日期，你其實是在做承諾（Commitment），而非估算。如果你做了承諾，你必須成功。除非你確定能做到，否則絕不要給出一個日期——改為提供帶有機率的日期範圍。

Aggregation（聚合）#

使用 PERT（Program Evaluation and Review Technique）——1950 年代末為管理北極星飛彈計畫而發明的估算技術：

flowchart TD
    A["拆解任務為子任務"] --> B["對每個子任務估算 B / N / W 三個值"]
    B --> C["計算每個子任務的 μ 和 σ"]
    C --> D["聚合：Σμ 和 √Σσ²"]
    D --> E["得到專案級估算（帶機率分布）"]

Honesty（回到誠實）#

• 這種估算方法本質上是誠實的——它向需要知道的人傳達你的不確定性程度
• 客戶和管理者會要求你更確定，但增加確定性的唯一方法是實際執行部分專案
• 有時管理者會要求你承諾——這是他們試圖將風險轉嫁給你
• 如果合理且有可能做到，就答應；如果不確定，就必須說「不」，並描述你的不確定性

當老闆問「你能不能至少試試？（Will you at least try?）」——正確的回應是：不。我已經在盡最大努力了。 如果你說「好，我會試試」卻沒有任何改變行為的計畫，那就是在說謊。

• 願意討論選項和替代方案，願意尋找說「是」的方法
• 但絕不讓人霸凌你說「是」
• 你被雇用的價值之一就是你知道何時該說「不」的能力

Respect（尊重）#

Promise 9. I will respect my fellow programmers for their ethics, standards, disciplines, and skill. No other attribute or characteristic will be a factor in my regard for my fellow programmers.

軟體專業社群由各種背景的人組成——不同性別、種族、政治立場、宗教信仰。這是一個互相尊重的社群。

• 加入社群並獲得尊重的唯一資格是：技能、紀律、標準與倫理
• 不容許基於任何其他基礎的歧視

Never Stop Learning（永不停止學習）#

Promise 10. I will never stop learning and improving my craft.

程式設計師永遠不會停止學習。作者提出以下建議：

語言與技術#

• 每年學習一種新語言，一位好的程式設計師應該認識十幾種語言
• 不只是同一語系的變體（如 C、C++、Java、C#），而是來自不同家族的語言：
  • 靜態型別語言（Java/C#）
  • 程序式語言（C/Pascal）
  • 邏輯語言（Prolog）
  • 堆疊語言（Forth）
  • 動態型別語言（Ruby）
  • 函數式語言（Clojure/Haskell）
• 同樣應接觸多種框架、設計方法論和開發流程

持續學習的態度#

• 持續閱讀書籍和部落格、觀看影片、參加研討會和使用者群組、參加培訓課程
• 重視過去的經典著作——1960-80 年代的書籍是洞見和資訊的寶庫。業界中真正過時的東西並不多
• 不要認為培訓是雇主的責任——這是你的職業生涯，你必須為它負責
• 你欠雇主每週 35-40 小時，你欠你的職業生涯另外 10-20 小時

專業人士投入時間來培養和維護自己的職業生涯。這意味著你每週應該工作 50-60 小時——大部分在工作中，但很多時間也在家中。