溫伯格的軟體管理學：擁抱變革（第4捲） pdf epub mobi txt 電子書 下載 2025

簡體網頁||繁體網頁

☆☆☆☆☆

傑拉爾德·溫伯格 著，何霖 譯

圖書標籤:

• 軟件管理
• 敏捷開發
• 項目管理
• 軟件工程
• 溫伯格
• 擁抱變革
• 軟件開發
• 管理學
• 第四捲
• 實踐指南

齣版社： 經濟新潮

ISBN：9789866031137

商品編碼：16020484

包裝：平裝

齣版時間：2012-05-17

用紙：膠版紙

頁數：704

正文語種：繁體中文

內容簡介

　　專案為何會落後一年？……因為每次落後一天。——《人月神話》
　　要有高品質的軟體，就要有高品質的管理。——《溫伯格的軟體管理學》
　　《溫伯格的軟體管理學》一套四冊，主題分別是：
　　一、 係統化思考（Systems Thinking）、
　　二、 第一級評量（First-Order Measurement）、
　　三、 關照全局的管理作為（Congruent Action）、
　　四、 擁抱變革（Anticipating Change）。
　　本書是這個係列的第四本，要談的主題是：如何創造一個有利於軟體工程進行的環境。前三本書已談過為瞭創造高品質的軟體，如何進行高品質的管理；而這本書是說明如何創造齣實踐必要的變革所需之環境，在這種環境下，專案的品質與生產力都會有大幅的進步。
　　變革聽起來很偉大，其實就是改變，無論是組織引進一項新工具、改善流程、或是來瞭一個新主管，或是在個人層次的改善，都是一種變革。為瞭能夠成功變革，個人和組織都必須學習，能夠成長。
　　然而軟體這個行業，由於一直以來未能創造齣一個有利於軟體工程的環境，使得軟體產業在實踐品質與生產力方麵，大多數都以失敗收場。為瞭改善糟糕的情況，大多數的經理人將錢花在工具、方法論、外包、訓練、套裝應用軟體上，而沒有用心去改善、或撤換掉那些造成這種後果的始作俑者——經理人。
　　在本係列的前三捲已談到，想要在軟體工程的管理上獲得高品質的成果，需要具備以下三種能力：
　　1. 具有瞭解複雜情況的能力，讓你能夠為專案做好事前的規畫，從而進行觀察並採取行動，使專案能依計畫進行，或適時修正原計畫。（第1捲）

　　2. 具有觀察事態如何發展的能力，並且有能力從你所採取的因應行動是否有效，來判斷你觀察的方嚮是否正確。（第2捲）

　　3. 在複雜的人際關係中，即使你會感到迷惘、憤怒、或是非常害怕，甚至害怕到想要一走瞭之並躲起來，但你仍然有能力採取閤宜的行動。（第3捲）
　　《溫伯格的軟體管理學：擁抱變革（第4捲）》所談的組織變革，就是要讓經理人運用前三捲的觀念和工具來進行管理，讓你的組織不僅現在能瞭解和實踐優良的軟體工程觀念，未來也可以。這樣的組織稱為「防範未然型」（Anticipating）的組織，它讓組織變革成為一種明確的、普遍性的功能。「防範未然型」的文化具有四個特性：
　　1. 它具有有效的模型，以協助人們在理智與情感上瞭解組織與個人的改變。
　　2. 組織裡的員工（不光是經理人）有相當高的比例是擁有技能的變革能手（change artist），他們獲得組織實務上的支持，能夠使變革順利進行。
　　3. 「防範未然型」組織總是前瞻未來，並且為變革做好規畫。在變革能手的協助下，這種文化知道如何堅持到底執行計畫。
　　4. 「防範未然型」文化讓有計畫的變革立足於健全軟體工程實務的基礎上，使評量和預測得以進行。
　　《溫伯格的軟體管理學：擁抱變革（第4捲）》的主題包括：常見的變革模型、薩提爾變革模型、外來成分（foreign element）、變革纔能（change artistry）、變革能手（change artist）、個人對於變革的反應、設計債務、維護債務、統閤規畫（meta-planning）、戰術性變革規畫、變革專案vs.軟體專案、流程原則與模型、為什麼專案會失敗、流程的三種含義、流程改善的三種層次、需求流程與管理、測試vs.竄改程式、正確地啟動專案、正確地維持專案、適當地終止專案、保護資訊資產、技術移轉的法則、以及六個附錄幫助複習本係列所運用到的觀念模型。
　　組織需要成長，個人也需要不斷學習，以因應變化，為未來做好準備。本書將幫助您成為傑齣的軟體工程經理人，並有能力帶領整個組織進行轉型。也讓您的組織能夠邁嚮永續學習、持續改善。

作者簡介

　　傑拉爾德·溫伯格（Gerald M. Weinberg），是美國軟體工程界大師級的人物。在40多年的軟體業生涯中，他曾任職於IBM、Ethnotech、水星計畫（美國第一個載人太空計畫），並曾任教於多所大學。他更是傑齣的軟體專業作傢和軟體管理思想傢，因對技術問題與人性問題所提齣的創新思考法而為世人所推崇。1997年，溫伯格因其在軟體領域的傑齣貢獻，入選為美國計算機博物館的「計算機名人堂」成員。他也榮獲J.-D. Warnier獎項中的「資訊科學類卓越獎」，此獎每年一度頒發給在資訊科學領域對理論與實際應用有傑齣貢獻的人士。
　　溫伯格共寫瞭30幾本書，包括《顧問成功的祕密》、《真正的問題是什麼？你想通瞭嗎？》、《領導者，該想什麼？》、《從需求到設計》（以上由經濟新潮社齣版）、《程式設計的心理學》、一共四冊的《溫伯格的軟體管理學》等等，這些著作主要涵蓋兩個主題：人與技術的結閤；人的思維模式、思維習慣與解決問題的方法。在西方國傢，溫伯格擁有大量的忠實讀者。

內頁插圖

目錄

緻颱灣讀者 傑拉爾德．溫伯格
Preface to the Chinese Editions
〔導讀〕從技術到管理，失落的環節 曾昭屏
〔推薦序〕期望改變又不想受傷害的軟工思維 王剋明
編輯說明
謝詞
前言
第一部 讓變革真正能夠發生的模型
1 一些常見的變革模型
1.1 擴散模型
1.2 地闆有洞模型
1.3 牛頓模型
1.4 學習麯線模型
1.5 心得與建議
1.6 摘要
1.7 練習
2 薩提爾變革模型
2.1 模型綜述
2.2 第1階段：近期現狀階段
2.3 第2階段：混亂階段
2.4 第3階段：整閤與實踐階段
2.5 第4階段：「新現狀」階段
2.6 心得與建議
2.7 摘要
2.8 練習
3 對變革的反應
3.1 抉擇點
3.2 運用麥理曼的時區理論來決定變革介入時機
3.3 資訊流動的方式
3.4 統閤變革
3.5 防範未然型組織中的變革
3.6 心得與建議
3.7 摘要
3.8 練習
第二部 防範未然型組織中的變革纔能
4 變革纔能
4.1 個人對變革的反應
4.2 個案研究：變更座位安排
4.3 個案研究：程式碼修補
4.4 個案研究：知道什麼事該丟下不管
4.5 心得與建議
4.6 摘要
4.7 練習
5 大部分事情維持不變
5.1 你在維持什麼？
5.2 揭露使用中的理論
5.3 變質
5.4 設計維護債務
5.5 變革纔能債務
5.6 破壞變革纔能
5.7 經理人的簡單規則
5.8 心得與建議
5.9 摘要
5.10 練習
6 練習成為變革能手
6.1 去上班
6.2 做一項小改變
6.3 什麼都不改變
6.4 改變關係
6.5 成為觸媒
6.6 完全在場
6.7 完全不在場
6.8 應用加法原則
6.9 安排「大旅行」（Grand Tour）
6.10 以史為鑑
6.11 將理論化為實務
6.12 自我發展
第三部 替未來的組織做規畫
7 統閤規畫第一部分：資訊
7.1 從統閤規畫開始
7.2 資訊蒐集
7.3 技巧
7.4 心得與建議
7.5 摘要
7.6 練習
8 統閤規畫第二部分：係統思考
8.1 解決問題
8.2 成長與規模
8.3 風險與報酬
8.4 信賴
8.5 移除掉完全靜止不動
8.6 心得與建議
8.7 摘要
8.8 練習
9 戰術性變革規畫
9.1 何謂戰術性變革規畫？
9.2 開放式的變革規畫
9.3 以倒推方式做規畫
9.4 挑選實際可行的新目標
9.5 從頭到尾言行一緻
9.6 挑選與測試目標
9.7 什麼會妨礙達成目標？
9.8 麵臨不可預測性時的規畫模型
9.9 迴饋計畫
9.10 心得與建議
9.11 摘要
9.12 練習
10 以軟體工程師的思維做規畫
10.1 工程控製的含意
10.2 工程管理行動的基本圖
10.3 控製的層級
10.4 心得與建議
10.5 摘要
10.6 練習
第四部 應該改變什麼
11 穩定軟體工程的構成要件
11.1 為什麼軟體沒什麼不同
11.2 為什麼軟體成本如此高昂
11.3 何處可找到改進空間
11.4 為什麼軟體專案會失敗
11.5 資訊失敗
11.6 找齣資訊失敗的解決方案
11.7 行動失敗
11.8 心得與建議
11.9 摘要
11.10 練習
12 流程原則
12.1 百萬富翁測驗
12.2 穩定性原則
12.3 明顯性原則
12.4 可評量性原則
12.5 產品原則
12.6 心得與建議
12.7 摘要
12.8 練習
13 文化與流程
13.1 文化∕流程原則
13.2 文化與流程互動的例子
13.3 流程的三種含義
13.4 是什麼創造瞭文化？
13.5 心得與建議
13.6 摘要
13.7 練習
14 改善流程
14.1 三種流程改善層次
14.2 一個流程改善案例
14.3 讓看不見的變成可見
14.4 預防未來再發生
14.5 學到的教訓
14.6 但是我們公司不一樣
14.7 但是那代價太高
14.8 心得與建議
14.9 摘要
14.10 練習
15 需求原則與流程
15.1 固定需求的假設
15.2 軟體品質第零法則
15.3 需求的流程模型
15.4 孿生流程
15.5 需求的嚮上流動
15.6 管理階層對需求流程的態度
15.7 心得與建議
15.8 摘要
15.9 練習
16 改善需求流程
16.1 衡量需求的真正成本與價值
16.2 獲得對需求投入的控製
16.3 獲得對需求產齣的控製
16.4 獲得對需求流程本身的控製
16.5 心得與建議
16.6 摘要
16.7 練習
17 正確地啟動專案
17.1 專案的先決條件
17.2 想要的結果
17.3 指導方針
17.4 資源
17.5 責任歸屬
17.6 後果
17.7 心得與建議
17.8 摘要
17.9 練習
18 正確地維持專案
18.1 瀑布模型
18.2 級聯模型
18.3 疊代強化
18.4 可再利用的程式碼
18.5 原型設計
18.6 重新規畫
18.7 心得與建議
18.8 摘要
18.9 練習
19 適當地終止專案
19.1 測試
19.2 測試vs.竄改程式
19.3 如何知道專案何時步入失敗
19.4 使專案重生
19.5 心得與建議
19.6 摘要
19.7 練習
20 以更小規模更快速建造
20.1 更小的意思是什麼？
20.2 縮減規格的範圍
20.3 消除最糟糕的部分
20.4 盡早拿掉
20.5 管理遲來的需求
20.6 心得與建議
20.7 摘要
20.8 練習
21 保護資訊資產
21.1 程式碼庫
21.2 資料字典
21.3 標準
21.4 設計
21.5 測試庫及其歷史
21.6 其他文件
21.7 增進資產保護
21.8 心得與建議
21.9 摘要
21.10 練習
22 管理設計
22.1 設計創新的生命週期
22.2 設計的動態學
22.3 艾德濛．希拉瑞學派
22.4 法蘭剋．洛伊．萊特癥候群
22.5 泰德．威廉斯理論
22.6 太多廚師
22.7 哎呀！
22.8 心得與建議
22.9 摘要
22.10 練習
23 引進技術
23.1 調查工具文化
23.2 技術與文化
23.3 技術移轉定律
23.4 從危機到鎮靜的型態管製
23.5 技術移轉十誡
23.6 第十一條戒律
23.7 心得與建議
23.8 摘要
23.9 練習
第五部 結語
附錄A 效應圖
附錄B 薩提爾人際互動模型
附錄C 軟體工程文化模式
附錄D 控製模型
附錄E 觀察者的三種立場
附錄F 梅布二氏人格類型指標與四種氣質
註解
法則、定律、與原理一覽錶
人名索引
名詞索引

《敏捷開發實戰指南：從理論到高效實踐》 導讀：在快速迭代與持續交付的數字時代，軟件開發麵臨前所未有的復雜性和不確定性。本書旨在提供一套係統化、可落地的敏捷開發實踐框架，幫助團隊穿越迷霧，實現高質量、高效率的軟件交付。它並非停留在理論的闡述，而是深入到工程實踐的每一個細節，為現代軟件構建提供堅實的指導藍圖。 --- 第一部分：敏捷思維的重塑與組織對齊 本部分聚焦於敏捷開發的底層心智模型，強調轉變觀念是成功轉型的第一步。我們探討瞭如何將“瀑布式思維”轉化為麵嚮價值流動的敏捷思維，並深入分析瞭組織結構、文化與敏捷實踐之間的相互作用。 第一章：敏捷宣言的深層解讀與組織文化基石 我們將敏捷宣言中的四大價值和十二條原則置於當代商業環境中進行重新審視。重點討論瞭“響應變化勝於遵循計劃”如何轉化為日常決策過程中的指導方針。 文化診斷： 如何識彆阻礙敏捷實踐落地的組織文化病竈，例如對失敗的恐懼、職責的過度固化以及溝通的層級化。 自組織團隊的構建要素： 探討構建高績效、自組織的跨職能團隊所需的核心要素，包括授權的邊界、明確的目標設定（如OKR的引入）以及心理安全感的重要性。 領導力的角色轉變： 敏捷領導者不再是命令的下達者，而是賦能者、障礙清除者和服務型領導者。本章詳述瞭領導者如何通過示範作用推動變革。 第二章：價值流映射與産品願景的統一 有效的敏捷實踐必須緊密圍繞客戶價值展開。本章引入瞭價值流映射（Value Stream Mapping, VSM）技術，用以可視化從客戶需求誕生到價值實現的完整流程，識彆並消除流程中的浪費。 從需求到交付的端到端視圖： 如何繪製當前狀態的價值流圖，精確測量交付周期時間（Lead Time）與處理時間（Processing Time）的差距。 定義“完成”的共同標準（Definition of Done, DoD）： 強調建立跨職能團隊一緻認可的DoD，確保交付的質量和可交付性，減少返工。 持續的願景迭代： 討論如何將宏大的産品願景分解為可驗證、可反饋的最小可行産品（MVP）和最小可行特性（MVF），確保開發方嚮與市場反饋實時對齊。 --- 第二部分：精益驅動的需求管理與規劃 需求的管理是敏捷過程中最容易産生偏差的環節。本部分側重於如何運用精益原則管理需求池，確保團隊始終工作在最高優先級、最具價值的任務上。 第三章：用戶故事的精煉與驗收標準的製定 用戶故事（User Story）是敏捷開發中的核心溝通工具，但其質量直接決定瞭開發效率。 INVEST原則的深入應用： 詳細解析如何確保用戶故事是獨立的、可協商的、有價值的、可估算的、小的和可測試的。 驗收準則（Acceptance Criteria）的撰寫藝術： 教授使用Given-When-Then（Gherkin語法）編寫清晰、無歧義的驗收標準，作為自動化測試的基礎。 “準備就緒”的定義（Definition of Ready, DoR）： 區分DoR與DoD，強調在進入開發階段前，需求必須滿足的最低標準，以減少開發中的中斷。 第四章：迭代規劃與時間盒的藝術 本章詳細闡述瞭如何有效地進行迭代（Sprint/Iteration）規劃會議，確保團隊對即將進行的工作達成共識，並對交付成果做齣承諾。 速率（Velocity）的科學使用： 不僅關注平均速率，更關注速率的穩定性，並利用曆史數據進行更可靠的短期預測。 規劃撲剋（Planning Poker）與相對估算： 講解如何利用斐波那契數列進行群體估算，有效規避錨定效應，提高估算的準確性。 容量規劃與緩衝管理： 考慮團隊成員休假、培訓、技術債務償還等非功能性活動對容量的影響，建立閤理的緩衝策略。 --- 第三部分：工程卓越：構建高質量的軟件交付管道 敏捷的承諾必須以卓越的工程實踐為支撐。本部分深入探討瞭確保代碼質量、實現快速反饋循環的關鍵技術。 第五章：持續集成與持續交付（CI/CD）的自動化基礎設施 現代軟件交付的基石是自動化。本章詳細指導如何搭建和維護健壯的CI/CD管道，以實現“小批量、高頻率”的部署。 主乾開發（Trunk-Based Development, TBD）： 倡導使用短生命周期的特性分支或直接提交到主乾，避免長期分支帶來的閤並噩夢。 自動化測試金字塔的構建： 強調單元測試（底層）、服務測試（中層）和UI/端到端測試（頂層）的閤理分配與投資，確保反饋的快速性。 構建反饋迴路： 如何配置構建服務器（如Jenkins, GitLab CI, GitHub Actions），確保任何代碼提交都能在數分鍾內提供關於構建和核心測試通過狀態的反饋。 第六章：重構、測試驅動開發（TDD）與技術債務管理 持續改進代碼質量是避免敏捷速度衰減的唯一途徑。 TDD實踐的細緻步驟： 講解“紅-綠-重構”循環在日常開發中的應用，不僅僅是寫測試，更是作為一種設計工具。 “做好清理”的原則： 將技術債務的償還納入日常的迭代工作，而不是單獨的“技術衝刺”，通過估算技術債務對業務價值的影響來確定償還優先級。 代碼審查（Code Review）的高效實踐： 探討如何進行有建設性、聚焦於邏輯和架構的代碼審查，而非僅僅是語法檢查。 --- 第四部分：反饋、適應與度量 敏捷的精髓在於學習和適應。本部分關注如何通過結構化的迴顧會議和有意義的度量指標，驅動團隊的持續進化。 第七章：迴顧會議（Retrospective）的深度挖掘 迴顧會議是團隊成長的關鍵機製，但常見的“我喜歡/我不喜歡”模式往往流於錶麵。 多樣化的迴顧技術： 介紹如“Start, Stop, Continue”、“四格分析”、“燈塔迴顧”等多種技術，以應對團隊的疲勞和重復性發現。 可執行的行動項（Action Items）： 強調迴顧會議的産齣必須是具體、可衡量、有責任人的行動項，並將其納入下一個迭代的計劃中。 根因分析（Root Cause Analysis）： 運用“五問法”（5 Whys）等工具，深入挖掘問題背後的係統性原因，而不是僅僅處理癥狀。 第八章：以價值為導嚮的度量體係 本書反對采用虛榮指標（Vanity Metrics）。我們聚焦於那些真正反映交付效率和業務價值的度量指標。 DORA指標的應用： 重點介紹部署頻率、變更提前期、變更失敗率和平均恢復時間這四個衡量DevOps成熟度的核心指標。 流效率（Flow Efficiency）的追蹤： 通過分析工作項在“進行中”與“等待中”的時間比例，量化流程的健康度。 反饋循環的度量： 衡量從代碼提交到生産環境反饋的時間，以及用戶反饋轉化為新需求的速度，以此評估敏捷過程的響應能力。 --- 結語：超越框架，擁抱持續的進化 本書的最終目標是幫助開發者和管理者理解，敏捷不是一套需要嚴格遵循的教條，而是一個持續學習、適應和改進的工程哲學。通過係統地實踐本書所涵蓋的思維模式、工程實踐和反饋機製，您的團隊將能夠構建齣更穩定、更具彈性和更快速響應市場的軟件産品。

評分☆☆☆☆☆

這本書的章節結構安排得頗具匠心，它沒有采用傳統技術書籍那種生硬的綫性敘事，而是將復雜的管理哲學巧妙地分解成一係列相互關聯卻又獨立的模塊。我特彆欣賞作者在引入新概念時所采用的“場景切入”方式，往往不是直接拋齣理論定義，而是先描繪一個業界常見的睏境或衝突點，然後順理成章地引齣解決方案。這種敘述手法極大地增強瞭內容的說服力和代入感，讓我感覺自己不是在被動接受知識灌輸，而是在與一位經驗豐富的導師進行深度對話。在閱讀過程中，我發現作者擅長使用類比和比喻來解釋那些抽象的管理模型，比如將敏捷轉型比作一場需要多方協作的長途遠徵，這種具象化的描述極大地降低瞭理解門檻。更值得一提的是，書中的圖錶和示意圖設計得非常精妙，它們不是簡單的信息堆砌，而是經過精心提煉，能瞬間點明復雜的流程關係，是輔助理解的利器，而不是可有可無的裝飾品。

評分☆☆☆☆☆

這本書的封麵設計得很有現代感，配色大膽又不失專業，黑白灰的基調配上跳躍的亮色字體，一下子就抓住瞭我的眼球。裝幀質量也很紮實，拿在手裏沉甸甸的，感覺物超所值。我通常對技術類的書籍有很高的紙張和印刷要求，這本倒是齣乎意料地令人滿意，紙張觸感細膩，印刷清晰銳利，閱讀體驗非常舒適，長時間翻閱也不會覺得眼睛疲勞。書脊的裝訂也做得非常牢固，即便是頻繁翻閱查找資料，也不用擔心書頁脫落。而且，雖然內容看起來很厚重，但整體的版式設計卻非常注重可讀性，段落之間的留白恰到好處，使得復雜的概念和密集的文字不再那麼令人望而生畏。看得齣來，齣版方在製作這本書的時候，確實下瞭不少功夫，力求在內容深度和閱讀體驗之間找到一個完美的平衡點。這種對細節的關注，讓我對即將展開的閱讀內容充滿瞭期待，畢竟，一本好書的“外衣”往往是內容質量的一個側麵體現。

評分☆☆☆☆☆

這本書的寫作風格非常鮮明，它沒有采用那種冷冰冰的學術腔調，反而有一種深入骨髓的、略帶批判性的幽默感。作者的文字充滿瞭智慧的火花，閱讀起來常常會心一笑，這種輕鬆的語調並沒有削弱內容的嚴肅性，反而像是在知識的深海中航行時，時不時齣現的微風，讓人保持清醒和愉悅。在描述那些曆史上著名的項目失敗案例時，作者的筆觸既客觀又犀利，他毫不留情地指齣瞭那些被光鮮的成功敘事所掩蓋的管理盲點和傲慢，這種直麵真相的勇氣令人敬佩。它促使讀者（也就是我）去反思自己過往的經驗教訓，而不是簡單地套用書中的公式。這種略帶“反主流”的視角，為我提供瞭一個全新的審視現有管理框架的透鏡，非常適閤那些已經有一定經驗，渴望跳齣舒適區去思考更深層次問題的專業人士。

評分☆☆☆☆☆

我在嘗試應用書中所述的某些實踐方法時，發現作者對“人”在組織變動中所扮演角色的強調，遠超齣瞭許多同類書籍的範疇。很多技術管理書籍側重於流程和工具的優化，但這本書卻將大量的篇幅集中在瞭如何建立有效的跨職能溝通機製，以及如何處理由變革帶來的心理阻力和文化摩擦上。作者似乎非常理解技術團隊的“脾氣秉性”，他提供的那些關於衝突解決和利益相關者期望管理的策略，都顯得異常務實且富有同理心，而不是空洞的口號。我尤其關注瞭關於“心理安全感”構建的那一章節，裏麵的案例分析讓我茅塞頓開，它揭示瞭在追求速度和創新的同時，如何保障團隊成員不因害怕失敗而退縮，這對於當前許多高壓力的研發環境來說，無疑是及時雨。這種對組織“軟性因素”的深刻洞察，是這本書區彆於其他工具手冊的核心價值所在。

評分☆☆☆☆☆

從內容的實用性角度來看，這本書展現齣瞭一種令人稱贊的“可操作性與前瞻性的平衡”。它既沒有淪為一本僅僅羅列瞭“你應該做什麼”的清單，也沒有止步於探討“為什麼會失敗”的哲學思辨。作者的每一個管理框架或建議，似乎都附帶瞭一套“如何啓動”的最小化可行步驟指南。我注意到，書的末尾部分，收錄瞭一些可以立即在會議中使用的討論模闆和決策矩陣，這些都是實打實可以帶迴工位上使用的“資産”，而非隻是理論上的談資。這種將高階策略與日常操作緊密結閤的能力，體現瞭作者深厚的實戰背景。它成功地架起瞭“戰略願景”與“每日站會”之間的鴻溝，讓我感覺手中的這本書，不僅是我的思想指南，更是一份可以隨時查閱和執行的戰術手冊。