推薦序 期望改變又不想受傷害的軟工思維
《溫伯格的軟體管理學》這一系列共出版了四冊，每一冊看來都很厚，好像閱讀起來也吃力，但其實如果能抓出作者的假設點，就能掌握出閱讀的目標與方向。若是問我這四冊各用一個字詞來表達主題，那就是：整體、觀察、溝通、實踐。這四項因子，也正是軟體專案開發成功與否的主要關鍵。
我們並無法完全移植其他成熟產業（如建築、硬體製造業）的成功經驗到軟體這個領域來，原因就在於「變動（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等多張專業認證執照。
● 熱愛閱讀，享受學習，擅長觀察與思考，同時亦為圍棋業餘五段棋癡。
留言列表
