軟體專案成功的管理之道《Ship it! A Practical Guide to Successful Software Projects》

軟體專案要成功已經是IT專業人員渴望的目標，難道做一個成功的軟體專案真的這麼難嗎？前一陣子也有雜誌媒體用心良苦，遠從國外請了許多號稱大師級人物來 臺演講，將其在國外著名軟體公司的豐富軟體專案經驗與國內的專業同好們分享，從該研討會的與會盛況看來，開發人員一直被軟體專案凌虐，已是長久以來不可磨 滅的事實。

相信大家對許多軟體工程方法論也耳熟能詳，但仍然有絕大多數的專案開發者，對於如何將這些理論落實在專案進行中，一直無法掌握到其精華，這也是很 多人至令仍尚未接納這些方法論的原因。而本書作者有鑑於此，排除大家常見的理論灌水篇幅，而改以在實際專案運作的建議做為主要內容。作者本身也是開發人員 出身，所撰寫的內容均為經過多個專案的實戰經驗得出的寶貴結論，以做為讀者的建議。

基礎建設、管理技術與開發流程三者環環相扣

在本書開宗明義即勾勒出軟體專案管理的藍圖，從該圖你便可清楚體會軟體專案需要成功，一些基本元素是無可避免的。它分成基礎建設 （Infrastructure）、管理技術（Technique）、開發流程（Process）三大領域，彼此環環相扣缺一不可。有了這完整的規畫，可 以提升專案團隊的執行力，清楚且明確地將客戶的需求完成並及時交付。

只要是軟體專案，一些基本機制是必備的，即在軟體工程理論中所談到的組態管理（Configuration Management），像是版本控管、自動及連續建構腳本程式、測試程式撰寫、錯誤及問題追蹤等，這些機制可讓軟體專案在建構階段具備較高的可管理性， 節省無謂的時間，讓你的專案團隊效率更高。

本書也介紹了一些搭配上述機制的工具，通常是各位耳熟能詳的開放源碼軟體，但重要的是在使用這些工具時，作者歸納了不少在實務上需要考慮的要點，以及建議的實作步驟和可能避免的錯誤，讓你在使用時更能發揮該工具的優點，有效提升工作效能。

在藍圖中，專案管理技術亦是不可忽視的範圍，在這裡作者列出了幾項較為實用的建議方法，像是利用一些管理表格來進行團隊管理，如：待辦事項、任務 及功能完成度等，藉以有效掌控專案內容；另外作者也強調技術經理角色（Tech Lead）的重要性，每日適當利用會議針對特定要項進行有效溝通、針對每個開發成員撰寫的程式碼進行審查（Code Review）、發布程式碼變更通告讓每個成員知道等。當然這些管理技術亦可輔以一些已經發展成熟的工具，讓管理不會因為這些繁瑣事項而模糊焦點。

曳光彈式開發著重於前期骨架的搭建

軟體專案中，開發流程的選擇常常是決定專案成敗的重要因素之一，有別於過往各位常聽到的RUP、XP等製程方法，作者提出了曳光彈開發方式 （Track Bullet Development，TBD），基本精神與Java創始企業Sun所提出的AM（Architecture Methodology）類似，強調開發流程先以快速建構雛型系統的方式，搭配Mock Object及介面設計的使用，在專案初期便確保軟體架構面上的風險降到最低，再進行後續各功能項目的開發工作。

在筆者認為相當精彩的第五章，作者歸納了18個在軟體專案進行中常見的問題，每個問題都針針見血，你會發現這些建議並不是先前常常讀到，又臭又長 的理論式解答，而是作者自己親身經驗後所提出的想法，內容相當吸引人。你在閱讀本章時，必然會回想到自己曾經遭遇的類似經驗而發出會心一笑。像是接手別人 寫的程式碼還要增加新功能時，你該如何快速上手？當客戶看到你日以繼夜完成的嘔心瀝血之作，卻仍覺得不甚滿意時，你要如何面對？當沒有專責的測試人員時， 好的測試程序應該如何進行？

而附錄章節則提供了關於專案進行時常會使用到的工具及相關技術，做為實作時的參考，像是自動構建腳本的撰寫、原始程式碼管理機制等。本書適合專案 經理、技術經理、開發人員等不同角色閱讀，以多維角度來思考成功軟體專案的必備條件。不同於其他專案管理書籍的設計，本書重實務而非拘泥於枯燥理論，加上 篇幅不多，相信你可以得到不錯的閱讀經驗。

其他軟體專案管理相關之中文書籍

• 溫伯格的軟體管理學：系統化思考（第1卷)(Quality Software Management, Volume 1: Systems Thinking), 經濟新潮社, 2006年9月
• 人月神話：軟體專案管理之道（20週年紀念版）, 經濟新潮社, 2004年4月
• 專案管理黑皮書, 碁峰, 2007年1月
• 最後期限：專案管理101個成功法則, 經濟新潮社, 2003年11月

 

《Effective Project Management》讓專案管理更有效率的3種方法

Effective Project Management

「如何有效地管理專案？」像這樣的問題一直被大家討論著，然而影響專案成功的因素實在太多、太廣，從對內的資源的有效控管，時程與成本的精算，到對外與客戶之間的關係聯繫，專案需求的明確定義等，只要其中一個環節沒有顧好，專案常常會流於失敗，甚至嚴重關係到公司的信譽。

傳統的專案管理方法，是將作業內容及工具標準化，讓專案管理人員可以有效地透過系統化的方法妥善管理。然而在面臨不同性質的專案時，一樣的標準化方式也能 一併套用嗎？軟體開發流程也有重量級（像RUP）與輕量級（像XP、Agile）的差別，所以專案管理是不是也可以因應不同的需求而有不同的方法呢？

多樣化專案管理方式，讓專案也能對症下藥
《Effective Project Management》一書介紹了3種不同的專案管理方式：傳統式（Tranditional）、適應式（Adaptive）、及極限式 （Extreme）。光就第一部分介紹傳統式專案管理的內容就值回票價了，其他兩種方式更是可以讓讀者以不同的思考角度，看待專案管理的問題，了解不同方 法之間的差異。會有後面兩種方式也是基於傳統方式的缺點而改良，在觀念及方法上都是比較創新的。

兩位作者Robert K. Wysocki與Rudd McGary加起來將近70年的專案管理經驗讓內容更具參考價值，本書也受到PMI（Project Management Institute，美國專案管理學會）的加持，成為專案管理類之推薦書籍。

本書內容便是依這三種不同的管理方式分別闡述，第一部分包括12個章節，主要介紹傳統專案管理（Traditional Project Management, TPM），從專案的定義開始談起，如何界定專案的範圍（Scoping）、明確定義專案活動（Activity）、預估時程及所需資源成本、組織管理專案 團隊、監控專案進度，到最後的驗收結案。

而極限式專案管理（Extreme Project Management, xPM）主要是針對在專案初期目標尚未明確，且無法有效定義專案範圍，或是針對需求時常變更的專案，甚至連專案結束的方式都毫無章法可言。故xPM強調透 過4個相當短的階段（Initiate、Speculate、Incubate、Review）快速地反覆進行，在每個階段結束時，同時規劃下個階段的方 向及執行內容，減低因為不確定性的影響。

客戶常會以「花錢的是老大」的心態，需求變更次數的頻繁，讓整個專案的需求及範圍無止境的延伸。本書的第二部分以7個章節來說明，針對TPM及 xPM不足之處提出折衷的新方法：適應式專案管理框架（Adaptive Project Framework）。適應式的專案管理方式主要在於流程反覆進行，不斷與用戶互動以確保專案方向的正確性。包含定義版本範疇（Version Scope）、擬定循環計畫（Cycle Plan）、進行循環建置（Cycle Build）、實施用戶查核（Client Checkpoint），以及事後審查（Post-Version Review）等五大步驟。

第三部分則探討企業在進行專案時所應考慮的兩大議題，一個是在多個專案同時進行時，所需要進行的專案組合管理（Project Portfolio Management），在資源有限之下做到最大運用；另外是如何發揮專案支援辦公室（Project Support Office）的效用，提供專案在進行過程中最完善的支援任務。

清楚描述專案管理，紮實讀者的理論基礎
相較於兩年前的版本（第二版）單純包含傳統式專案管理的內容，在這個版本新增了適應式與極限式兩種不同的方法論點。作者的用意便是因應環境多變的 需求，希望以提供多樣化的管理方式來解決不同性質的專案難題，可以讓讀者以不同的思考角度來看待專案管理的問題，了解不同方法之間的差異。

就本書的廣度而言，是十分完整介紹專案管理方法的書，適合用來教學或當成工具書，但較少介紹實務經驗及案例分析建議，是美中不足之處。而就深度而 言，如何讓專案管理更為有效（Effective），就讀者而言會希望看到較具體明確的建議，若是需要針對某些議題再深入研究，就需要再參考作者列在附錄 中的參考文獻。

 

《Prefactoring》避開重蹈覆轍的陷阱

refactoring

早從1999年Martin Fowler的著作至今，重構（Refactoring）似乎已經成為提昇軟體品質的重要觀念，但軟體專案常常會因為時程壓力及人力不足的現實問題，在專 案執行的過程中進行Refactoring是很難被允許的。以專案管理的觀念看來，這是需要花費時間與金錢的。故在架構設計及程式撰寫上，這樣的觀念就相 對地不被重視，程式開發人員也都以「只要將功能開發出來」的想法來運作。

重構的實現較易在軟體產品研發上，落實在版本更新的規劃中，不過產品規劃的時程也不見得允許重構，因為Refactoring不會改變任何外部功能；而依客戶需求量身訂做的客製化軟體專案，甚至涉及到系統整合的案例，則更難以將重構落實在專案中。

累積預防經驗有助於日後專案發展

有鑑於Refactoring不易落實，所以一個適應性的做法－Prefactoring（預構）也許是個另類的解決方式。作者Ken Pugh提出這樣的觀念，根據自己或他人多年的軟體開發經驗，整理成開發專案時的指導方針，以利於未來專案啟始時做為遵循的準則。它與重構的差別主要在於 執行的時間點，Prefactoring是在專案開始前就先行思考，並非在專案執行期間才發生。

這裡的指導方針有絕大部份跟一般基本的設計原則（像是OOAD的特性）相符，而其他的方針則主要圍繞在分析抽象化（Extreme Abstraction），設計分離（Extreme Separation），提供可讀性（Extreme Readability），以及介面設計（Interface）幾個重點上。

抽象化設計其實已經是物件導件分析設計中的重要觀念，強調「做什麼（What）」而非「如何去做（How）」。所以在這個過程中，很難意會到實作 時的細節，容易造成分析階段到設計階段時實現（Realization）的落差。針對這個問題，本書建議在抽象化設計時搭配雛型系統 （Prototype）的使用，而在設計過程中使用與特定式語言與無關的的方式，採OOAD之標準原則（像是Class、Interface、 Exception等）來進行設計。

分離設計最常見的方式，便是將操作畫面的呈現與商業邏輯，以不同的元件各司其職。在日後需求變動時，不會牽一髮而動全身；而為了日後維護容易，寫出來的程式碼不僅是給電腦看，也要讓人能輕易地看得懂。本書建議最理想的程式是連您的客戶都看得懂。

預構強調軟體開發流程與方法

本書的內容共分成十七個章節，作者以開發一套CD出租店系統的虛擬故事為主軸，說明在進行一項軟體專案時會面臨到的課題。開宗明義不免俗地簡介 Prefactoring的觀念以及其基本方針，接下來便從與老板Sam聊起他理想中的系統應該長什麼樣子開始，文中不時穿插主角與客戶之間的對話，活生 生地如同您在與客戶之間的溝通互動。

為了精確掌握使用者在想什麼，首先釐清字詞明確的描述（光CDTitle、CDRelease、CDDisc的定義就引起一番爭論），再將相關的 字詞分類歸納，轉化成物件的方式來設計。這裡頭像是一些常見物件設計原則就會被討論到，像是多形（Polymorphism）、抽象化資料型態 （Abstract Data Type）等等，甚至直接用一個雛型系統（Prototype）來與使用者確認需求內容的正確性。

雖然設計必須奉行理論，但還是有無法被落實的狀況發生。起因可能是與使用者想法的不一致，對事物解讀的誤解。但這些軟體開發的準則並不是標準答 案，就像是開車一樣，每個人都有自己的風格，重要的是讓自己面臨類似問題時能快速且有效地解決。而且每個準則都有適用的使用時機，而非一條鞭式地適用於任 何狀況。

就本書的內容看來，還是在強調軟體開發流程與方法的重要性。在每個章節中作者以座右銘的方式提醒需要強調的重點，並在書末的附錄中整理了所有的原 則。如果了解物件導向分析設計的重要，同時亦希望用省時省錢的方法來進行專案，本書也許可以提供一些想法，雖然無法保證從此不需要 Refactoring，但次數的減少是可以肯定的。

 

精通物件導向技術必讀聖經《Applying UML and Patterns》

只要接觸到物件導向分析與設計的課題，熟悉UML工具及設計樣式（Design Patterns）是不可避免的，想當年剛開始接觸UML時，公司的前輩便丟給我《UML Distilled》這本書，其實，對於一個已經被傳統瀑布式開發流程荼毒許久的我來說，K完這本書之後完全不知其所云(可能是資質太差，無法感受到其精 髓)，更別說是上手了。後來也是不斷地收集網路上UML相關討論，才零零碎碎，片片斷斷地搞清楚UML在做什麼，慢慢地與實務面結合起來。

坊間不乏探討UML及Design Patterns的書籍，有些內容只是枯燥地逐一介紹UML每個圖例及符號的使用方法，有些書籍完全不提專案實務上的運用，而有些書籍只舉出無關痛癢的例 子（像是車子與輪胎的老掉牙故事），對於複雜的現實需求毫無助益，讀者看了這些書也很難將理論應用上手（筆者便是其中的一位）。當筆者接觸到 《Applying UML and Patterns》時，翻開封面看到內頁的流程圖（Sample Unified Process Artifact Relationships）和GRASP原則，深深覺得相見恨晚，許多我對UML塵封已久的疑慮都可以從這本書中找到。

結合作者多年實務經驗，內容詳細完整

本書在架構設計上依開發流程分成四大部份，從第一部份Inception階段探討如何定義及分類需求，如何利用使用案例圖（Use Case Diagram）及活動圖（Activity Diagram）將需求具體化。到第二部份Elaboration階段初期，討論如何將需求建構出領域模型（Domain Model），分門別類地規劃出物件及其間的關係，運用Class Diagram進行需求分析。第三部份Elaboration階段中期，則討論如何加入Patterns來進行物件設計，不斷改良上個階段的設計內容。而 第四部份Elaboration階段後期則包括軟體架構（Architecture）及框架（Framework）設計。

對於學習UML的讀者來說，UML符號及其代表意義的問題都不大，比較大的問題會是在每個UML圖的使用時機，以及如何將抽象的轉化成UML方式 來表現。光這個觀念筆者也是花了不少時間才建立起來。本書值得推薦的是，作者依開發流程分別說明每個階段會用到的UML圖有那些，詳細描述每個UML圖在 引用時需要，並說明與前後階段的關連性，讓讀者能對UML的用意更有深刻體會。

而設計樣式（Design Patterns）相信也是許多開發人員難以消化的課題。本書針對四人幫所著之《Design Patterns》一書中常用Patterns的運用也有專章說明，除了介紹Patterns本身的用法之外，同時亦提到在設計及實作階段時運用這些 Pattern時應該留意的重點，並搭配程式碼讓讀者更了解最終透過UML工具產生的程式內容。

光介紹UML是不夠的，結合實務及流程才重要

案例研究也是本書的另一個值得推薦的優點。許多UML書籍不是過度著墨在標記（Notations）的使用方式，就是很少與軟體開發流程結合，所 以讀者常會有知道一大堆的UML圖，但卻說不出來那個階段該套用什麼樣的工具。作者以實例方式貫穿本書，讓讀者可以從需求階段開始，循序漸進地思考如何流 暢地利用UML工具套用到開發流程的每個階段中。

本書目前為第三版，與前個版本內容的差別主要在於本書以UML第二版標準來介紹，增加了一個大家都十分熟悉的「大富翁遊戲」當做案例研究，在反覆 及演進式開發過程中歸納出更多的使用技巧。同時在這個版本中加入敏捷（Agile Modeling）理論、重構（Refactoring）、以及測試導向開發(Test-Driven Development)的討論，亦說明如何套用UML於此輕量級的開發流程中。另外改良原有內容，加入更多的圖片及學習小技巧來輔助說明，並再加入一些 業界較受歡迎的方法論進來，讓讀者更容易閱讀而且更實用。

 

《Agile and Iterative Development: A Manager’s Guide》

Agile and Iterative Development: A Manager's Guide

要客戶在開發期間不會變更需求幾乎是不可能的，短期專案還好，那種一年半載的專案更是嚴重，如此惡性循環，專案結案日遙遙無期，需求變更永無止境。

在傳統的軟體開發流程中，瀑布式（Waterfall）仍是目前採用比例最高，且造成問題最多的開發方式之一。軟體就如同新產品研發一樣，開發時程的長短 與風險有相對的關係。所以敏捷觀念的出現，希望能透過反覆式的開發方法，配合自動化的開發工具，以多個較短的開發時程（Iteration），反覆地因應 不同階段的專案需求，如此才能外在環境及需求變化日益頻繁的狀況下，解決因為開發時程過長，而不能及時反應客戶需求變更的問題。

屬管理類書籍，融入專案管理及
開發流程新觀念

在軟體工程及物件導向領域中，本書作者Craig Larman堪稱大師級人物，其經典作品《Applying UML with Patterns》已成為研習OOAD及UML之必讀聖經。光從本書的副標您就可以知道，這本書是寫給長官們看的，書中內容說明敏捷與反覆式開發的基本原 則、使用的動機及時機，並提到其他相關的開發流程概念。由於新觀念的落實必須要有管理者的支持，讓管理者了解這些觀念的價值所在，才會提昇成功導入的機 率。同時，也有利於管理者與工程人員以此方式進行專案開發時，以共通的語言及想法來進行溝通。

本書一開始以兩個章節的篇幅，整理了反覆式、漸進式及敏捷式法則的重要觀念，對這些法則的特性以簡短的內容說明，幫助讀者（尤其是管理者）快速建立基本觀念。

有什麼動機非得要採用敏捷理論不可呢？本書第五章透過一些研究報告的結果，列出以往專案需求變更的常見原因，同時讓讀者了解瀑布式流程所造成的問 題，並歸納出採用敏捷理論的關鍵性因素。當然，再好的理論沒有實務的驗證，還是很難讓人採信，本書第六章作者採用類似研究報告的寫法，收集了許多參考文獻 與統計數據來說明敏捷理論的實用價值，而不是單純作者的自吹自擂。

接下來便針對四個值得注意的敏捷發展理論中的基本觀念及理論原則，包括Scrum、極限製程Extreme Programming（XP）、Unified Process（UP），以及Evo。對於這些理論未曾涉獵的讀者，在此分別以獨立的章節介紹，明確的結構讓讀者易於理解及比較有助於觀念的建立。其中包 括每個理論的概念介紹、生命週期（Lifecycle）、相關參與的角色、文件產出、施行要領、以最佳實踐法則（Best Practices）、常犯的錯誤及誤解、與其他理論的比較，並列出過去曾以這些理論實作的成功專案等。

提供實務施行準則，提高專案成功機率
最後精彩的第十一章，描述實際導入需要注意的技巧，讓敏捷理論更能成功順利地落實，包括在專案管理、環境配置、需求管理，及測試程序等層面。若您 有軟體專案外包的需求，本章提到在面對多個研發團隊（Multiteam）時的Iteration規劃及管理方式，以及在設計Iteration需要注意 的重點為何。同時在專案過程中所需的環境配置，包括軟硬體環境該如何搭配。另外本章也提供一些協助需求管理的管理技術及方法，像是願景（Vision）、 使用案例（Use Case）、心智圖（Mind Maps）等等。

一些保守的企業，不願意冒著變革的風險，對敏捷理論躊躇不前，對於外在環境迅速變化的因應程度相對較低，所以本書內容收集了相關的研究報告，及一些大型專案之案例分析，可以提供你實現理論之有力佐證，踏出變革的第一步。

最後，本書強調人的因素仍然是關鍵。其對整個專案的影響程度重要性遠大於流程本身。成員之間不斷地溝通，團隊協同運作，一直是敏捷方法中所強調的重點。所以，管理者也不能忽視這個環節。