【前言】

此刻我們並不知道，這些「軟體流程改善」的結果是否為典型的結果。我們認為詮釋這些結果最好的方式，就是將這些結果當作是指標，看看它在受到支持的環境下，會有什麼事情發生。❶

── J. Herbsleb等人

這本書要談的是，如何創造一個有利於軟體工程進行的環境。在這樣的環境裏，你的組織將可實現軟體工程協會（SEI）和其他流程改善機構的一些客戶所宣稱的，在品質與生產力方面獲得令人印象深刻的進展。

　　本書是《溫伯格的軟體管理學》系列的第四本。前三本書告訴我們必須做些什麼，而這本書是說明如何創造出實踐必要的變革所需之環境。如果你尚未讀過其他三本，閱讀這本書應該會促使你回去讀那三本。你可以用任何順序來閱讀，但這本書應該留到最後才讀，即使那可能是你第二次讀它了。❷

　　由於沒有從一開始就創造出一個有利於軟體工程的環境，結果軟體工程的歷史在實現品質與生產力的進展上，大多數是以失敗收場。為了改善糟糕的情況，很多經理人將錢花在CASE工具、CAST（電腦輔助軟體測試）工具、CAD工具、方法論、外包、訓練、應用套裝軟體等方面，但是他們極少一開始就把力氣花在改善、或換掉那些造成這種後果的經理人。

　　我們這一行一直是個「尚未成功」的產業，而且除非我們能破除對於「特效藥」的迷思，真正去處理關於經理人的問題，不然我們將永遠是個未成功的產業。這種迷思有一部分是來自於只是將每項工作當作更高階工作之踏腳石的那些經理人。海軍上將瑞克瓦（Hyman Rickover）在談到這類經理人或工作者所犯的錯誤時說：

「當一個人從事某項工作時（任何工作都一樣），他必須認為他『擁有』那項工作，而他的所做所為，就好像他會永遠一直從事那項工作一樣。他必須負責盡職地關照他的工作，就好像看待自己的事業或自己的錢一樣……有太多人將整個的工作生涯花在尋找下一份工作上。當一個人覺得他擁有現在的工作，也依照這樣的態度來做事，那他根本不需要擔心他的下一份工作。」❸

身為經理人，我們承認有成長的需要，無論是人或組織都需要成長。請不要沮喪，因為我已經看過數百位經理人成功地成長，我知道我們辦得到。一旦經理人開始成長，我看過他們能成功地進行本書所介紹的許多美妙的軟體工程活動，相信你也做得到。

　　這些活動是什麼？《溫伯格的軟體管理學》系列的前三卷談到，想要在軟體工程的管理工作上獲致高品質的成果，你需要具備以下三種基本能力：

1.     具有了解複雜情況的能力，以便你能為專案做好事前的規畫，從而進行觀察並採取行動，使專案能依計畫進行，或適時修正原計畫。

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

3.     在複雜的人際關係中，即使你會感到迷惘、憤怒、或是非常害怕，甚至害怕到想要一走了之並躲起來，但你仍然有能力採取合宜的行動。

第四卷要處理組織變革的問題，並告訴我們如何運用前三卷所提到的工具來進行管理，將原本的組織改造成不僅現在能了解和實踐優良的軟體工程觀念，而且未來也能了解和實踐這些觀念。我們將這種組織稱作「防範未然型」（Anticipating）的組織。

　　所有的組織都會改變，但是「防範未然型」組織讓組織變革成為一種明確的、普遍性的功能。與前一階段的「把穩方向型」（模式3）的文化相比，「防範未然型」的文化具有四個特性：

1.     「防範未然型」文化具有有效的模型，以協助人們在理智與情感上了解組織與個人的改變。

2.     組織裏的員工（不僅是經理人）有相當高的比例是擁有技能的變革能手（change artist），他們獲得組織實務上的支持，而能夠使變革之輪平順運轉。

3.     「防範未然型」文化習慣前瞻未來，並為組織變革做好規畫。在變革能手的協助下，這種文化知道如何堅持到底地執行計畫。

4.     「防範未然型」文化讓有計畫的變革立足於健全軟體工程實務的穩定基礎上，使評量和預測得以進行。

本書的內容分成四部，分別涵蓋「防範未然型」組織的這四個特性，並說明如何讓組織具備這些特性。

　　軟體作家與研究者Capers Jones告訴我們，專案越大，失敗的機率也越高。❹他的觀察適用於軟體專案，但是，要改變你所在的組織的品質文化，其工作份量比起您的組織曾做過的任何軟體專案都要大得多。那正是為什麼我將「組織變革」這個主題單獨寫一本書的原因，也是為什麼它是系列中最後一冊的原因。因為若要獲得成功，你必須從前三冊開始所有的練習。

　　為了帶領組織文化的變革，你必須變成一位傑出的軟體工程經理人，而光是閱讀這四卷書是不夠的。這四卷書中大多數的章節都有建議延伸閱讀，而你應該遵循這些建議進行。此外，大多數章節的結尾都有「練習」這一節，讓你在學習的最高潮時檢驗學習的效果。

　　談完所有這些之後，你可能發現至少要閱讀四十本書（不是要你立刻讀完！），而這四本書僅僅是個導引，你還需要花幾千個小時練習你所學到的。然而，相較於你為了要成為傑出的軟體工程師，已讀過多少書練習了多少小時，這個負擔似乎還算合理。如果你能這樣努力下去，你必定能達成你的新目標，也就是至少成為一位傑出的軟體工程經理人，能帶領整個組織進行轉型。

　　祝你一路順風！

【目次】

致台灣讀者　　傑拉爾德‧溫伯格　　7

Preface to the Chinese Editions　　10

〔導讀〕從技術到管理，失落的環節　　曾昭屏　　13

〔推薦序〕期望改變又不想受傷害的軟工思維　　王克明　　17

編輯說明　　24

謝詞　　35

前言　　39

第一部　讓變革真正能夠發生的模型

1         一些常見的變革模型    45

1.1  擴散模型　　46

1.2  地板有洞模型　　48

1.3  牛頓模型　　53

1.4  學習曲線模型　　57

1.5  心得與建議　　59

1.6  摘要　　60

1.7  練習　　62

2         薩提爾變革模型  65

2.1  模型綜述　　65

2.2  第1階段：近期現狀階段　　67

2.3  第2階段：混亂階段　　72

2.4  第3階段：整合與實踐階段　　74

2.5  第4階段：「新現狀」階段　　77

2.6  心得與建議　　79

2.7  摘要　　82

2.8  練習　　84

3         對變革的反應      87

3.1  抉擇點　　88

3.2  運用麥理曼的時區理論來決定變革介入時機　　94

3.3  資訊流動的方式　　97

3.4  統合變革　　100

3.5  防範未然型組織中的變革　　102

3.6  心得與建議　　104

3.7  摘要　　106

3.8  練習　　109

第二部　防範未然型組織中的變革才能

4         變革才能    115

4.1  個人對變革的反應　　116

4.2  個案研究：變更座位安排　　121

4.3  個案研究：程式碼修補　　123

4.4  個案研究：知道什麼事該丟下不管　　125

4.5  心得與建議　　127

4.6  摘要　　128

4.7  練習　　131

5         大部分事情維持不變    133

5.1  你在維持什麼？　　134

5.2  揭露使用中的理論　　138

5.3  變質　　140

5.4  設計維護債務　　141

5.5  變革才能債務　　144

5.6  破壞變革才能　　145

5.7  經理人的簡單規則　　148

5.8  心得與建議　　149

5.9  摘要　　150

5.10  練習　　153

6         練習成為變革能手        155

6.1  去上班　　155

6.2  做一項小改變　　157

6.3  什麼都不改變　　160

6.4  改變關係　　162

6.5  成為觸媒　　165

6.6  完全在場　　167

6.7  完全不在場　　170

6.8  應用加法原則　　172

6.9  安排「大旅行」（Grand Tour）　　174

6.10  以史為鑑　　176

6.11  將理論化為實務　　178

6.12  自我發展　　180

第三部　替未來的組織做規畫

7         統合規畫第一部分：資訊      183

7.1  從統合規畫開始　　184

7.2  資訊蒐集　　188

7.3  技巧　　201

7.4  心得與建議　　203

7.5  摘要　　205

7.6  練習　　207

8         統合規畫第二部分：系統思考        211

8.1  解決問題　　212

8.2  成長與規模　　215

8.3  風險與報酬　　222

8.4  信賴　　227

8.5  移除掉完全靜止不動　　230

8.6  心得與建議　　234

8.7  摘要　　236

8.8  練習　　240

9         戰術性變革規畫  243

9.1  何謂戰術性變革規畫？　　244

9.2  開放式的變革規畫　　245

9.3  以倒推方式做規畫　　247

9.4  挑選實際可行的新目標　　250

9.5  從頭到尾言行一致　　253

9.6  挑選與測試目標　　255

9.7  什麼會妨礙達成目標？　　260

9.8  面臨不可預測性時的規畫模型　　261

9.9  回饋計畫　　268

9.10  心得與建議　　270

9.11  摘要　　271

9.12  練習　　273

10       以軟體工程師的思維做規畫 275

10.1  工程控制的含意　　276

10.2  工程管理行動的基本圖　　285

10.3  控制的層級　　286

10.4  心得與建議　　292

10.5  摘要　　295

10.6  練習　　296

第四部　應該改變什麼

11       穩定軟體工程的構成要件      301

11.1  為什麼軟體沒什麼不同　　302

11.2  為什麼軟體成本如此高昂　　304

11.3  何處可找到改進空間　　307

11.4  為什麼軟體專案會失敗　　309

11.5  資訊失敗　　310

11.6  找出資訊失敗的解決方案　　314

11.7  行動失敗　　317

11.8  心得與建議　　319

11.9  摘要　　320

11.10  練習　　321

12       流程原則    323

12.1  百萬富翁測驗　　324

12.2  穩定性原則　　326

12.3  明顯性原則　　330

12.4  可評量性原則　　334

12.5  產品原則　　337

12.6  心得與建議　　340

12.7  摘要　　341

12.8  練習　　343

13       文化與流程          345

13.1  文化／流程原則　　346

13.2  文化與流程互動的例子　　347

13.3  流程的三種含義　　353

13.4  是什麼創造了文化？　　358

13.5  心得與建議　　360

13.6  摘要　　362

13.7  練習　　364

14       改善流程    369

14.1  三種流程改善層次　　370

14.2  一個流程改善案例　　371

14.3  讓看不見的變成可見　　376

14.4  預防未來再發生　　377

14.5  學到的教訓　　378

14.6  但是我們公司不一樣　　379

14.7  但是那代價太高　　382

14.8  心得與建議　　385

14.9  摘要　　386

14.10  練習　　388

15       需求原則與流程  389

15.1  固定需求的假設　　390

15.2  軟體品質第零法則　　392

15.3  需求的流程模型　　395

15.4  孿生流程　　397

15.5  需求的向上流動　　399

15.6  管理階層對需求流程的態度　　401

15.7  心得與建議　　403

15.8  摘要　　404

15.9  練習　　407

16       改善需求流程      409

16.1  衡量需求的真正成本與價值　　410

16.2  獲得對需求投入的控制　　414

16.3  獲得對需求產出的控制　　421

16.4  獲得對需求流程本身的控制　　425

16.5  心得與建議　　429

16.6  摘要　　431

16.7  練習　　434

17       正確地啟動專案  437

17.1  專案的先決條件　　438

17.2  想要的結果　　442

17.3  指導方針　　444

17.4  資源　　446

17.5  責任歸屬　　448

17.6  後果　　451

17.7  心得與建議　　455

17.8  摘要　　458

17.9  練習　　462

18       正確地維持專案  463

18.1  瀑布模型　　464

18.2  級聯模型　　466

18.3  疊代強化　　468

18.4  可再利用的程式碼　　469

18.5  原型設計　　471

18.6  重新規畫　　474

18.7  心得與建議　　479

18.8  摘要　　482

18.9  練習　　486

19       適當地終止專案  487

19.1  測試　　488

19.2  測試vs.竄改程式　　492

19.3  如何知道專案何時步入失敗　　499

19.4  使專案重生　　504

19.5  心得與建議　　506

19.6  摘要　　509

19.7  練習　　512

20       以更小規模更快速建造          515

20.1  更小的意思是什麼？　　516

20.2  縮減規格的範圍　　519

20.3  消除最糟糕的部分　　520

20.4  盡早拿掉　　525

20.5  管理遲來的需求　　528

20.6  心得與建議　　533

20.7  摘要　　535

20.8  練習　　538

21       保護資訊資產      539

21.1  程式碼庫　　542

21.2  資料字典　　543

21.3  標準　　546

21.4  設計　　547

21.5  測試庫及其歷史　　549

21.6  其他文件　　551

21.7  增進資產保護　　551

21.8  心得與建議　　555

21.9  摘要　　557

21.10  練習　　560

22       管理設計    561

22.1  設計創新的生命週期　　562

22.2  設計的動態學　　564

22.3  艾德蒙．希拉瑞學派　　570

22.4  法蘭克．洛伊．萊特症候群　　571

22.5  泰德．威廉斯理論　　573

22.6  太多廚師　　577

22.7  哎呀！　　577

22.8  心得與建議　　579

22.9  摘要　　579

22.10  練習　　583

23       引進技術    585

23.1  調查工具文化　　586

23.2  技術與文化　　588

23.3  技術移轉定律　　593

23.4  從危機到鎮靜的型態管制　　596

23.5  技術移轉十誡　　600

23.6  第十一條戒律　　606

23.7  心得與建議　　607

23.8  摘要　　609

23.9  練習　　612

第五部　結語

附錄A　效應圖　　619

附錄B　薩提爾人際互動模型　　623

附錄C　軟體工程文化模式　　625

附錄D　控制模型　　633

附錄E　觀察者的三種立場　　641

附錄F　梅布二氏人格類型指標與四種氣質　　643

註解　　651

法則、定律、與原理一覽表　　673

人名索引　　679

名詞索引　　683