🎯 什麼情境該想到我
當團隊的反應方式出了問題——出事就找人背鍋、用 quick hack 敷衍、技術討論變成人身攻擊、看到問題不敢說——的時候。書的第 2 章把這四個習慣放在最前面，理由是：「如果态度不正确，那么所有的这些习惯都不管用。」
| 習慣 | 良策（書中的一句話） |
|---|---|
| 做事 | 指責不會修復 bug，把矛頭對準問題的解決辦法，而不是人 |
| 欲速則不達 | 不要墜入快速的簡單修復之中 |
| 對事不對人 | 讓我們驕傲的應該是解決了問題，而不是比較出誰的主意更好 |
| 排除萬難奮勇前進 | 做正確的事，要誠實，要有勇氣說出實情 |
章導言指出：傳統方法論有 35 種不同的角色，敏捷只需要一種——軟體開發者。「敏捷依赖人，而不是依赖于项目的甘特图和里程表。」
出處：Subramaniam & Hunt《高效程式設計師的 45 個習慣：敏捷開發修煉之道》（Practices of an Agile Developer）。站內的原書是掃描版 PDF，引文依 OCR 結果核對，保留原書簡體字。每個習慣在書中都有固定結構：魔鬼的誘惑（一句錯誤但誘人的想法）→ 良策（書中粗體的一句話建議）→ 內文 → 切身感受 → 平衡的藝術（別做過頭）。
⚙️ 怎麼用（逐項）
做事
Work for Outcome 什麼時候會冒出來：出事了大家開始互相指責／只想著撇清責任而不是修好／會議變成追究到底是誰的錯／想把焦點拉回讓專案成功
魔鬼的誘惑：「出了问题，第一重要的是确定元凶。找到那个白痴！」
良策：「指责不会修复bug。把矛头对准问题的解决办法，而不是人。」
書中重點：
- 出事時該問的是：「为了解决或缓解这个问题，我能够做些什么？」
- 和愛搬弄是非的人共事是最糟的工作——「不要从团队中走开——应该跑开」，至少把對話從指責遊戲引開。
- 側欄〈符合標準不是結果〉：你可以拿到 ISO-9001 認證，完全遵循流程，生產出「一件漂亮的铅线织就的救生衣」——然後所有使用者都淹死。「过程符合标准并不意味结果是正确的。敏捷团队重结果胜于重过程。」
切身感受：「勇于承认自己不知道答案，这会让人感觉放心。一个重大的错误应该被当作是一次学习而不是指责他人的机会。」
平衡的藝術：
- 「這不是我的錯」不對；「這都是你的錯」更不對。
- 如果你沒犯過任何錯誤，說明你可能沒有努力工作。
- 開發者和測試人員爭論「這是缺陷還是新功能」通常沒有意義，不如趕快修。
- 一個人誤解了需求或 API，其他人可能也誤解了——要確保全隊盡快消除誤解。
- 成員一再傷害團隊，就是不專業，必須請他離開這個專案（書中註明：不需要解雇，但不能留在這個專案）。
在今天的樣子：這個習慣後來被制度化成 工具-無指責事後檢討。書中的「救生衣」比喻，也是 DORA 指標強調結果（恢復時間、失敗率）而不是流程合規的原因（見 工具-部署管線與持續交付）。
欲速則不達
Quick Fixes Become Quicksand 什麼時候會冒出來：想先用一個臨時繞法擋過去再說／明知是治標卻趕著先交出去／同一個地方一直重複出問題／技術債越補洞越大
魔鬼的誘惑：「你不需要真正地理解那块代码，它只要能够工作就可以了……就把那几行代码加进去，它应该可以工作。」
良策：「不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。」（旁註：防微杜漸）
書中重點：
- 作者 Andy 的一個客戶：沒有任何開發者或架構師了解業務的底層資料模型，幾年下來，程式碼裡累積了「成千上万的+1和-1修正」。每次快速修復都沒有追究根源，最後形成吞噬專案的沼澤——有人會說「千万不能碰那个模块的代码。写代码那哥们儿已经不在这儿了」。
- 三個對策：不要孤立地寫程式（見 程式碼集體所有制）、做程式碼審查（見 做程式碼審查）、使用單元測試（見 守護天使）。
切身感受：「在项目中，代码应该是很亮堂的，不应该有黑暗死角……没有任何一块代码被警戒线或者“切勿入内”的标志隔离开。」
平衡的藝術：
- 必須理解程式碼如何運作，但不一定要成為專家。
- 如果有人說某段程式碼很難看懂，那就代表任何人（包括原作者）都很難維護它——讓它簡單一點。
- 不要急著修復沒真正理解的程式碼。「+1/-1 病症」一開始是看不見的。
- 大型系統沒有人能全懂；除了深入自己負責的部分，也要從更高層次了解各部分如何互動。
在今天的樣子：「+1 修正」就是 工具-區分修復與掩蓋症狀 所說的掩蓋症狀。「切勿入內」的模組，正是 工具-破窗理論與軟體熵 的起點。
對事不對人
Criticize Ideas, Not People 什麼時候會冒出來：技術討論快要變成人身攻擊／開會變成誰講話大聲誰就贏／想批評方案又怕傷到對方／意見不合場面開始僵掉
魔鬼的誘惑：「你在这个设计上投入了很多精力……你坚信它比其他任何人的设计都棒。别听他们的。」
良策：「对事不对人。让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。」（旁註：消極扼殺創新）
書中的例子——三種回應：同事提出一個新方案，你可以說：
- 「那样很蠢！」——否定個人能力。
- 「那样很蠢，你忘记考虑它要线程安全。」——指出缺點，但仍在否定。而且對方可能回你：「它只在那個模組裡用，本來就跑在自己的執行緒上」——讓你自己難堪。
- 「谢谢。但是我想知道，如果两个用户同时登录会发生什么情况？」——只有這種有效：提出具體的顧慮，而不是下結論。
讓討論保持對事的四個技巧（書中列出）：
- 設定最終期限：例如午餐前或當天結束前做出決定。沒有最好的答案，只有更合適的。
- 逆向思維：先看方案的優點，再努力從反面去認識它。
- 設立仲裁人：會議的主持者確保每個人都有發言機會，防止明星員工主導；仲裁人專注於調停，不發表自己的意見。
- 支持已經做出的決定：客戶不在乎是誰的主意，結果才重要。
側欄〈團體決策的駱駝〉：委員會要全票通過，想造一匹馬，結果可能造出駱駝。書中引亞里斯多德：「能容纳自己并不接受的想法，表明你的头脑足够有学识。」
切身感受：「你不会因为拒绝了有太多缺陷的方案而伤害别人，也不会因为采纳了某个不甚完美（但是更好的）解决方案而被人忌恨。」
平衡的藝術：
- 盡力貢獻想法，沒被採納也不需要生氣；不要為了表現自己而對好方案畫蛇添足。
- 「資料庫廠商可能會倒閉」這種說法不夠，必須評估發生的可能性；有時要先做原型。
- 找最佳方案前，先對「最好」的意思達成共識。
- 只有更好，沒有最好：不存在「最佳實踐」，只有特定條件下更好的實踐。
- 不帶情緒不等於盲目接受——用合適的詞和理由說明你為何不同意。
在今天的樣子：第三種回應就是好的 code review 意見的樣子。卡內基的 用提問代替命令 是同一個道理。即用版見 工具-對事不對人的協作。
排除萬難奮勇前進
Damn the Torpedoes, Go Ahead 什麼時候會冒出來：明知該做對的事卻怕得罪人／看到壞味道卻不敢說出口／該重構但沒有人願意先開口／想堅持正確做法又怕被討厭
魔鬼的誘惑：「如果你发现其他人的代码有问题，只要你自己心里知道就可以了……如果他是你的老板，更要格外谨慎。」
良策：「做正确的事。要诚实，要有勇气去说出实情。」
書中重點：
- 寓言〈誰去給貓繫鈴鐺〉：絕妙的計畫，因為沒有人有勇氣執行而失敗。
- 遇到爛程式碼，抱怨沒有用。「动手证明（不要只是嚷嚷）」——把爛程式碼放一邊重寫，並列出重寫的理由與前後比較。
- 發現自己的方法錯了，要站出來說：「我现在知道了，我过去使用的方法不对。」
- 作者 Venkat 的經驗：處理各種檔案的程式碼全是重複的，他一開始也複製了數百行、只改兩行。後來說服老闆重構，一週內完成——之後修改處理方式只需要改一個地方。
切身感受：「勇气会让人觉得有点不自在……但有些时候，它是扫除障碍的唯一途径。」
平衡的藝術：
- 你說天要塌了而隊友不同意——也許你是對的，但沒把理由說清楚；也許他們是對的，要認真考慮。
- 設計或程式碼有奇怪的地方，先花時間理解它為什麼這樣。還沒理解就輕易否定、重寫，「那不是勇气，而是鲁莽」。
- 對決策者要用他們聽得懂的話：「更清晰的程式碼」打動不了生意人；節省成本、更好的投資報酬、避免訴訟、增加使用者利益更有說服力。
- 在壓力下被要求犧牲品質時，可以指出：身為開發者，你沒有權力毀壞公司的資產（程式碼）。
在今天的樣子：
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 態度不能靠口號：這四個習慣都需要制度支撐——無指責的事後檢討、有 review 規範、有讓人安全說出問題的文化。只貼標語沒有用。
- 勇氣不是魯莽：書中明確區分——還沒理解就否定重寫是魯莽；理解之後、用對方聽得懂的方式提出，才是勇氣。
🔗 相關工具
- 工具-對事不對人的協作 —— 從本頁萃取的即用工具卡
- 化解對立的六種方法 —— 卡內基的版本：技術爭論變成對立時怎麼處理
- 高效程式設計師的45個習慣 —— 書卡