溫伯格的軟體管理學 第4卷: 擁抱變革 | 誠品線上

Quality Software Management Vol.4: Anticipating Change

內容簡介

內容簡介 專案為何會落後一年？……因為每次落後一天。－《人月神話》要有高品質的軟體，就要有高品質的管理。－《溫伯格的軟體管理學》《溫伯格的軟體管理學》一套四冊，主題分別是：一、 系統化思考（Systems Thinking）、二、 第一級評量（First-Order Measurement）、三、 關照全局的管理作為（Congruent Action）、四、 擁抱變革（Anticipating Change）。本書是這個系列的第四本，要談的主題是：如何創造一個有利於軟體工程進行的環境。前三本書已談過為了創造高品質的軟體，如何進行高品質的管理；而這本書是說明如何創造出實踐必要的變革所需之環境，在這種環境下，專案的品質與生產力都會有大幅的進步。變革聽起來很偉大，其實就是改變，無論是組織引進一項新工具、改善流程、或是來了一個新主管，或是在個人層次的改善，都是一種變革。為了能夠成功變革，個人和組織都必須學習，能夠成長。然而軟體這個行業，由於一直以來未能創造出一個有利於軟體工程的環境，使得軟體產業在實踐品質與生產力方面，大多數都以失敗收場。為了改善糟糕的情況，大多數的經理人將錢花在工具、方法論、外包、訓練、套裝應用軟體上，而沒有用心去改善、或撤換掉那些造成這種後果的始作俑者－－經理人。在本系列的前三卷已談到，想要在軟體工程的管理上獲得高品質的成果，需要具備以下三種能力：1. 具有了解複雜情況的能力，讓你能夠為專案做好事前的規畫，從而進行觀察並採取行動，使專案能依計畫進行，或適時修正原計畫。（第1卷）2. 具有觀察事態如何發展的能力，並且有能力從你所採取的因應行動是否有效，來判斷你觀察的方向是否正確。（第2卷）3. 在複雜的人際關係中，即使你會感到迷惘、憤怒、或是非常害怕，甚至害怕到想要一走了之並躲起來，但你仍然有能力採取合宜的行動。（第3卷）本書所談的組織變革，就是要讓經理人運用前三卷的觀念和工具來進行管理，讓你的組織不僅現在能了解和實踐優良的軟體工程觀念，未來也可以。這樣的組織稱為「防範未然型」（Anticipating）的組織，它讓組織變革成為一種明確的、普遍性的功能。「防範未然型」的文化具有四個特性：1. 它具有有效的模型，以協助人們在理智與情感上了解組織與個人的改變。2. 組織裡的員工（不光是經理人）有相當高的比例是擁有技能的變革能手（change artist），他們獲得組織實務上的支持，能夠使變革順利進行。3. 「防範未然型」組織總是前瞻未來，並且為變革做好規畫。在變革能手的協助下，這種文化知道如何堅持到底執行計畫。4. 「防範未然型」文化讓有計畫的變革立足於健全軟體工程實務的基礎上，使評量和預測得以進行。本書的主題包括：常見的變革模型、薩提爾變革模型、外來成分（foreign element）、變革才能（change artistry）、變革能手（change artist）、個人對於變革的反應、設計債務、維護債務、統合規畫（meta-planning）、戰術性變革規畫、變革專案vs.軟體專案、流程原則與模型、為什麼專案會失敗、流程的三種含義、流程改善的三種層次、需求流程與管理、測試vs.竄改程式、正確地啟動專案、正確地維持專案、適當地終止專案、保護資訊資產、技術移轉的法則、以及六個附錄幫助複習本系列所運用到的觀念模型。組織需要成長，個人也需要不斷學習，以因應變化，為未來做好準備。本書將幫助您成為傑出的軟體工程經理人，並有能力帶領整個組織進行轉型。也讓您的組織能夠邁向永續學習、持續改善。

作者介紹

作者介紹 傑拉爾德‧溫伯格是美國軟體工程界大師級的人物。在40多年的軟體業生涯中，他曾任職於IBM、Ethnotech、水星計畫（美國第一個載人太空計畫），並曾任教於多所大學。他更是傑出的軟體專業作家和軟體管理思想家，因對技術問題與人性問題所提出的創新思考法而為世人所推崇。1997年，溫伯格因其在軟體領域的傑出貢獻，入選為美國計算機博物館的「計算機名人堂」成員。他也榮獲J.-D. Warnier獎項中的「資訊科學類卓越獎」，此獎每年一度頒發給在資訊科學領域對理論與實際應用有傑出貢獻的人士。溫伯格共寫了30幾本書，包括《顧問成功的祕密》、《真正的問題是什麼？你想通了嗎？》、《領導者，該想什麼？》、《從需求到設計》（以上由經濟新潮社出版）、《程式設計的心理學》、一共四冊的《溫伯格的軟體管理學》等等，這些著作主要涵蓋兩個主題：人與技術的結合；人的思維模式、思維習慣與解決問題的方法。在西方國家，溫伯格擁有大量的忠實讀者。溫伯格現為Weinberg and Weinberg顧問公司的負責人，他的網站是http: www.geraldmweinberg.com何霖美國賓州州立大學MBA，兼職從事財經企管類書籍翻譯工作，譯有《PMP專案管理認證指南》（三版）、《比率管理全書》、《軟體專案管理》、《公司裡最難說的4種話》 、《管理工具黑皮書》等書。

產品目錄

產品目錄 致台灣讀者 傑拉爾德．溫伯格 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：MBTI與氣質 模型註解法則、定律與原理一覽表人名索引名詞索引

商品規格

最佳賣點

最佳賣點 : 專案為何會落後一年？……因為每次落後一天。——《人月神話》
要有高品質的軟體，就要有高品質的管理。——《溫伯格的軟體管理學》

試閱文字

推薦序 :

〔推薦序〕

期望改變又不想受傷害的軟工思維

        王克明

　　《溫伯格的軟體管理學》這一系列共出版了四冊，每一冊看來都很厚，好像閱讀起來也吃力，但其實如果能抓出作者的假設點，就能掌握出閱讀的目標與方向。若是問我這四冊各用一個字詞來表達主題，那就是：整體、觀察、溝通、實踐。這四項因子，也正是軟體專案開發成功與否的主要關鍵。

　　我們並無法完全移植其他成熟產業（如建築、硬體製造業）的成功經驗到軟體這個領域來，原因就在於「變動（Change）」這個最根本的因素。因為變，所以無法事前規劃精密的藍圖再據此施工；也更因為善變，軟體專案無法採用代工業的IPO（Input-Process-Output）亦即瀑布式（waterfall）的管理模式。

　　不是要抑制變動，而是要能順應變化；對軟體專案唯一需要保持的信念，就是要不斷做出改變。

　　當面對軟體專案多變複雜的特質，第一步就是要能掌握住整體，這也是溫伯格在第一冊《系統化思考》開宗明義所提及，我們所需要的正是「正確的思考」，也就是系統化的思考，因為唯有如此，我們才能「明白自己在做什麼」。系統化思考就是一種架構觀（architecture view），而架構並非單指IT系統如三層式（3-tier），我寧願稱呼這為實作面的分層結構框架。

　　誰需要對軟體專案有全貌認知的系統化思考？個人以為兩種角色是必要的：專案經理（project manager, PM）與架構師（architect）。這兩種角色都是在做調和的工作，專案經理調和的是人，架構師調和的是技術。

　　人包括了客戶、利益關係人（stakeholder）、團隊開發人員等各類角色。PM講究的是領導統御的能力，而非去精通某種管理工具、技術、方法論等，那些都是次要的。「人」才是PM首要解決的課題，如此才有機會在成本、時程、系統開發規模等找出適切的平衡點。至於品質，那則是架構師的責任了。架構師也是在做調和，只是他調和的是技術，而技術不單是指實作面，也涵蓋了需求分析、結構設計等其他兩個面向，個人擔任軟體顧問多年來的經驗，最常碰到的問題就是這三種面向的不一致與衝突。

　　這邊就舉我擔任軟體架構顧問多年來的實務經驗談，簡述關於調和需求、結構、實作三個構面的觀念。

　　實作技術人員常指望需求不要頻繁變動，但請記得，需求必然就是會變動，所以我常指導技術人員要具備的心態就是預期所交付的需求都是錯的──但這樣也能開發下去。似乎很神奇？其實需求分析就是抓住參與者（actor）使用系統背後所隱含的意圖，每一個意圖可以視為是一個功能性的目標框架，而後所有相關該功能的細節，包括欄位明細、企業邏輯等，就可以在該目標框架內透過循環（iteration）、漸進（increment）的開發模式，逐步琢磨出精確的細節。

　　一開始建立功能目標框架，並可順暢地轉移到實作階段，同樣也是建立程式碼的骨架（skeleton），而細節就是被封裝（encapsulate）在框架之內。請記得，封裝可是軟體設計的第一原則，但普遍軟體開發人員均不自知，幾乎都以資料導向的思維開發系統，如此過早揭露出太多雜質不確定的細節，當然就難以開發維護了。

　　再則，共用性的結構設計反而可以延遲開發，待個別功能逐一的實現，再來才去挖掘出這些功能的共用性需求。所以，應付短線時程的專案首重是需求的實現，而當爾後上線系統能提升其再利用性價值，再來才去談及結構面的重整，也就是重構（re-factoring）的功夫了。當然，即使是短線重視個別功能實現的專案，也必須要事先規劃並建立可被延展的框架才能應付重構，例如MVC（mode-view-control）樣式的設計，這些就是較深入技術面的議題了。

　　（PS：為何不一開始就專注在共用性的結構設計上？因為那會耗費相當多的開發成本與時程，而這往往都是短線專案最缺乏的。再則，事前的結構設計需要有相當的軟實力功夫，這類人才其實鳳毛鱗角。）

　　系統化思考就是在做調和的工作，包括人與技術面等議題。調和的過程中，必然會衍生出諸多的問題──包括技能、技術與溝通（甚至還有政治）等風險，而風險當然及早揭露、及早解決才好。第二冊《第一級評量》談及的就是如何觀察、發現問題的本質，並進而找出解決方案；而第三冊《關照全局的管理作為》則單對溝通議題，進而討論性格分析並找出因應的管理措施（很有意思，軟體工程也需涉獵到心理學這個領域）。

　　專案管理者經常喜好找尋工具、方法論來抑制或預防開發過程中所發生的上述問題，但往往導入這些高度儀式化的工具與方法並沒有實際解決問題，反而衍生了更多的問題。問題是不斷在過程當中發生的，所以並沒有固定的方法或工具可以事先預防解決，反而應該要懂得從過程當中觀察再觀察，發現問題的核心，思索應對的策略，動態找出方法來實際解決。

　　溫伯格就曾在書中一針見血地提到：專案經理經常對發生的狀況視而不見，甚至已經是麻木不仁了。為何如此？人們總害怕揭露問題反而會損及自己的權益，甚至會造成更多的問題發生。如何解決？整體性的系統思考、學習型的組織、密切的溝通互動，盡量拋開成見與政治面（這點最難）利害關係，才能有機會鼓勵專案開發過程中懂得觀察與發現問題，並進而協同找出應對的解決方案。

　　相較於技術衍生的問題，開發過程有更多更需克服的問題是源自於溝通的議題上，所以溫伯格在第三冊專書介紹以「人」為本的職場管理學，甚而還探究性格分析的心理層面。專案管理者需要了解團隊成員的人格類型與心理狀況，甚至更需要的是如何自我覺察，了解自己與他人，改善人際關係，才能轉化為「關照全局」的學習型組織。

　　個人是覺得，軟體人員最好真的要先認清自己適合擔任何種角色。這也可以透過PDP統計學的動物性格分析來了解自己與他人的性格傾向。共分為五種：有魄力威權的老虎、活潑愛表現的孔雀、注重細節的貓頭鷹、任勞任怨的無尾熊，以及具多重性格、視環境而轉換的變色龍。舉例來說，就個人多年來的觀察心得，與客戶往來溝通或做需求訪談等需要人際關係的工作，由孔雀性格的人來擔任最適合；寫程式碼，喜愛與技術為伍者由貓頭鷹或無尾熊性格的人來做，產能會最高；領導統御如專案經理的工作，當然就是老虎性格最適切了；至於變色龍性格，嗯，最適合擔任顧問或者軟體架構師了。（這裏僅是簡單的列舉，當然現實上多數人的性格更是複雜錯綜。）

　　了解管理者應具備的素養，包括系統性的思考、敏銳的觀察力、關照全局的溝通能力，當然就要在現實的環境中來實踐之，而這也是最後這一本《擁抱變革》所論及的主題──預期軟體專案變動的常態，並進而建構能因應變革的組織，確實有效改善軟體工程的環境。

　　沒有絕對的方法可以有效應付變動，但卻有一致性的原則：將變動侷限在可控制的範圍之內。所以溫伯格特別強調了其中的要訣：「動作要早，動作要小，是保持軟體過程都在控制之中的關鍵。」。另外在《顧問成功的祕密》一書中，他也強調了變革應該是：「既可以改變，又不用受傷害。」

　　這很有意思，管理者想要改善環境，提升軟體工程的品質，可能有兩種方式：一為革命（revolution），一為革新（evolution）。革命是要抱著不成功便成仁的決心，成效雖快，但也很容易失敗更會受傷害；而革新是採漸進的做法，一次只改一點點，有了一些成效後再往前推進，雖然緩慢但也比較不會受傷害。

　　綜合許多軟體大家的成功實務經驗，包括溫伯格本人，建議的做法會比較傾向是革新的漸進式做法。

　　所以，現今主流的開發方法論，包括UP（unified process）、Agile、Scrum等，雖然各自實踐的方法不一樣，但對應變動的核心本質卻都是一致的──採用快速循環漸進（iteration & increment, I&I）的開發模式。

　　I&I的做法對一個功能單位的實現，至少會切分兩個以上的循環（iteration），第一個循環先建立出包括程式碼的骨架，並確實打通技術關節；第二個循環則著重在於對精細度的要求，包括如資料欄位、企業邏輯（business logic）的正確性，以及對於例外事件的處理（exception handling）。每一次的循環係以「週」為開發單位，在1~2個星期內涵蓋了需求分析、結構設計、程式碼實作（乃至於測試）。如此循環漸增，早一些取得回饋（feedback），早一點揭露風險，如此才有機會應付軟體專案的變動，並且比較不容易受傷害。

　　組織要能順應I&I的做法，必然需要經過某種程度的變革，才能讓軟體團隊可以忍受模糊與不確定性。透過本書提供的實踐方法，讓傑出的管理者可以帶領組織預期改變，並進而擁抱改變。「兵無常勢，水無常形，能因敵之變化而致勝者，謂之神。」期待管理者可以成為本書所稱謂的「變革能手（change artist）」。

本文作者王克明（Kenming Wang）：

●    現職：HSDc軟體架構師（Software Architect）、資深講師、顧問。

●    曾任：系統工程師、Oracle DBA、IT部門副理、講師、顧問、軟體架構師。《iThome》、《北京程序員》等平面雜誌專欄作者。

●    精通軟體設計本質、物件導向觀念、UML、RUP/XP、軟體架構規劃與設計等。

●    多年來極為豐富之教學經驗，擅長傳授軟體設計本質給學員。

●    Novell CNI/CNI, Microsoft MCSE, Oracle DBA, Java SCJP, UML OCUP等多張專業認證執照。

●    熱愛閱讀，享受學習，擅長觀察與思考，同時亦為圍棋業餘五段棋癡。