書評－敏捷開發－以人為本，擁抱改變

規劃極致軟體製程 　Kent Beck、Martin Fowler/著， 　王錦裕/譯 　培生教育集團出版 　售價：380元

英諺有云：「補鞋匠的孩子沒鞋穿」（Cobbler's children go shoeless），這句話用在軟體從業人員身上還真貼切。我們專門幫各行各業自動化，提升工作品質，增加專案效率。但自身如何建構一個可控管、有效率、高品質的軟體開發流程卻一直是個令人頭大的問題。

由於軟體專案的重複性較低，不管是客戶需求、使用技術、團隊成員養成、專案成本等面向，在每個案子間都存在著相當大的差異。一般在其他工程界，如製造、建築等，行之有年而較成熟的專案管理理論拿到軟體界來，通常都難以適用。

軟體工程的大師們一直在找尋著能降低軟體專案不確定性的方法。例如分析設計上的結構化、物件導向，軟體生命週期的瀑布模型或漩渦式開發，乃至於整體流程的CMMI或Agile。然而，我們大多數依然活在經費超支、時程延宕、軟體品質不穩，功能不足的夢魘中。

就筆者觀察，在週遭的工作環境中存在一個有趣的現象，非軟體相關科系的從業人員多過正規教育出身的人。不知其他工程，例如建築、製造、塑化、生技等領域是否也如此。但就自身的感覺，我們這些黑手出身的，在進入到工作崗位上，一開始想的都是如何寫程式幫使用者立刻解決眼前的問題，不會深思所寫出來的東西是否經得起時間錘鍊，我們不會思考成員們如何合作，僅以最會寫程式的人當意見領袖。總要專案陷入困頓後，才抬起頭來找尋出路。

筆者遊走於各大企業，與各產業內的工程師交換著黑手技術的經驗，這些跨國大企業、金融集團、通訊、製造、醫療等龍頭，它們的事業都是如此的成功，但其內部的IT 狀況卻是差不多的。這種存在的實質現象，總讓筆者迷惑。僅針對企業體內的軟體開發團隊與使用者而言，「能用」的彈性真大。

敏捷開發與極致軟體製程
就筆者自身的感覺，當下最負盛名，也較適合企業內專案開發的精神是敏捷開發（Agile）。

它的發展史如下：2001年2月，在美國猶他州的一個滑雪場，17位軟體開發方法論的專家，包括Kent Beck、Martine Fowler（其方法論為 Extreme Programming）、Alistair Cockburn（其方法論為 Crystal Methodologies）、Jim Highsmith（其方法論為Adaptive Software Development）等，共同發布了「敏捷開發宣言（The Manifesto for Agile Software Development）」。你可以在agilemanifesto的網站上看到宣言的全文，筆者妄加翻譯如下：

開發者以及彼此的互動重於流程和工具（Individuals and interactions over processes and tools）

作軟體重於細緻文件（Working software over comprehensive documentation）

客戶參與開發重於訂約（Customer collaboration over contract negotiation）

應變重於墨守成規（Responding to change over following a plan）

在上述敏捷開發宣言下，有著諸多的方法論，其中極致軟體製程XP（Extreme Programming）最為著名且完整，其核心強調4大價值：溝通（Communication）、簡單（Simplicity）、回饋（Feedback）和勇氣（Courage）。並針對軟體生命週期中的設計、測試、開發、上線等環節提出十多種作法建議（Practice）。

XP的特色在於由下而上（Value Up）快速循環，一般建議以2週左右為一個單位，迅速作一次設計、測試、開發、交付的動作，而後檢討修正，再開始下一個進度單位。在客戶與使用者的參與下，一次次地修正，直到到達目的地為止。

與其他Agile精神下的方法論相比，XP較強調測試的重要性，每個開發人員不僅要寫程式碼，同時也必須寫相對應的測試案例（Test Case）程式碼。經由持續的構建和集成（Continuous Build & Integration）。並在一次次的遞迴週期中，完成局部的產品功能。每次週期結束時，搭配重構（Refactoring）的規則，修正不好的程式碼，在通過先前累積的測試案例後，接著進入下一階段遞迴，以此為下一步的開發提供了較穩定的基礎。

如同Martin Fowler在其文章《The New Methodology》中強調：「敏捷強調修正，而非預測。重量級方法花費大量的人力物力，試圖制訂詳細計畫來指導長期的工作。而一旦發生變化，計畫就不再適用。」因此，本質上，重量級方法是抵制變化的；而敏捷方法則強調適應變化。其次，敏捷方法以人為中心，而非以流程為中心。敏捷方法強調順乎本性（Work with People's Nature），軟體開發應帶來樂趣。

在此介紹一本關於XP的好書：《規劃極致軟體製程》（Planning Extreme Programming），此書2位作者在軟體開發流程的方法論界極富盛名，也就是前面提到的Agile宣言發起者Kent Beck和Martin Fowler。

在本書中，他們風趣幽默地將理念納於短文中。書雖小，但富含智慧。筆者在此列舉書中一些有趣的觀點：

我們將開發軟體比喻為開車，開車並非讓車子朝向一個方向前進並保持它即可，開車必須進行許多微小的路線修正。

在軟體開發計畫中，業務決定結案日期（Dates）、功能範圍（Scopes）、優先順序（Priority）以及技術人員估算（Estimates）。

顧客必須是開發團隊的一部份，這個角色太重要而不能是局外人，假如顧客無法參與，任何XP專案將失敗…當顧客水準不夠，就算擁有世界上最佳的才能、技術與程序，仍終將失敗。

對顧客而言，XP最棘手的就是習慣規律的交付（Delivery）…顧客必須時時刻刻問自己：「下次擁有什麼功能是最有價值的？」

加班不是一個好主意…即使程式設計人員願意加班，也不是一個好主意。長時間的工作會令人感到疲累，疲累的人容易犯錯，而錯誤需要花更長的時間來找尋與修正。

軟體專案的四個變數中：成本（Cost）、品質（Quality）、時間（Time）和規模（Scope），時間和規模是較好控制的…必須讓時間成為可見的。

假設明天所能作的，將會和今天實際上已完成的一樣多。

每日需要簡潔的會議…整個會議過程中，每個人都必須站立著，以提醒簡短發言。

每次遞迴完成某項功能後，由顧客操作示範與解說，並由顧客將牆上待完成表內之該項目劃掉。

可信賴的業務或顧客，其人格特質需要：經驗（Experience）、交際（Contacts）、遠見（Vision）、勇氣（Courage）。

顧客必須作決策，但不必忠於決策，改變心意是他們的權力，但是決策必須由某個基於企業觀點的人產生。

自己炒的菜，再難吃，自己也會捧場
最近，筆者碰到一個開發模式局部採用XP的案子，開發團隊5人，產出的系統有600人使用，總共花了5個月的時間來完成。

開發期間，主事者以一週為單位，當作循環週期。經歷了初期的練習後，小組團隊較能切割一個星期能達交的工作內容。由於達交時間短，讓開發者不能鬆懈。因為即便兩次都展示同樣的半成品，也總得交代時間花在什麼地方。

在開發初期，一個星期的遞迴時間在遇到比較難的技術問題時，可能根本看不到成果，主事者因此取消過一、兩次的專案會議，可是團隊就鬆懈下來了。這也驗證了本書兩位作者強調遞迴時間固定的重要性。

另外，由於一個星期內，大家專注開發同一功能，因此開發團隊的成員可以彈性調度支援。不會有兩三個月，大家各自開發專屬功能的模組，而其後將發生無法互相支援的窘境。

過程中，使用者每個星期都參與成果測試，並分析下一個遞迴的需求。等於使用者本身就是分析、測試人員，由這樣的會議交談，讓整個團隊對領域知識了解更深刻。也由於參與度足夠，且開發時間短，所以需要相對修正的內容也會比較少。又因為有多少就給使用者測多少，可以在早期發現錯誤，就算全部推翻重寫，也不過推翻了一、兩星期的時間。這次的嘗試雖比預估時間晚了一個月才完成系統，但最令人興奮的是，上線後少有人抱怨。

主事者目前覺得有問題的是時程掌控不易，這不是開發者的問題，而是因為一直在修正。如果有完美主義者參與，他們老覺得這裡要加一點那裡要加一點。

閱讀建議
本書輕薄短小，很有敏捷風格，章節很多（27章），文字很少。讀來輕快有成就感。所以，建議你就一口氣讀完吧。

相關閱讀
●《Software Engineering with Microsoft Visual Studio Team System》
Sam Guckenheimer/著；Addison Wesley出版。這依然是一本解釋Visual Studio Team System所為何來的書，因為作者在Team System團隊中就代表使用者。書中並沒有如何操作的步驟，但能夠讓你了解為何Team System要實作這些功能。

● MSDN網站
當然，微軟技術的大本營不可不去。

《作者簡介》胡百敬
現任職恆逸資訊教育訓練處資深講師，聯合報系、睿智資訊與臺灣微軟技術顧問。著有《SQL Server 2005資料庫開發聖經》等書，並為專欄作家。