敏捷開發與OOAD（上）

Dec. 29 12:55~14:21

 

Teddy當年念書的時候，在學校修OOAD（物件導向分析與設計）課程，主要教科書是Craig Larman所寫的《Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development》，附帶一本指定參考書籍《The Unified Software Development Process》。後來Teddy當了這門課的助教，有一年老師將參考書籍改成《Object-Oriented Modeling and Design with UML, 2nd》這本書，為了跟上修課學生的進度，也把這本書讀了一下。換句話說，Teddy當年學過三本不同教科書所教授的OOAD方法。

 

今天不是要標榜自己多厲害，而是想討論一個問題：「傳統OOAD所教的那套軟體開發方法，到了敏捷開發世界中變成了怎麼樣子？」

***

不知到鄉民們是否學過所謂「正規的物件導向分析與設計方法」？在學校修這門課之前，Teddy已經有8年多實際開發商業軟體的經驗，也自學看過GoF Design Patterns、RUP與UML。但是，關於需求分析、物件產生、介面設計的方法，大體還是依靠所謂的「經驗」，並沒有一套特別清晰的流程框架。修了這門課之後，主要依據Larman在書中所介紹的方式（UP；Unified Process），對於OOAD心中總算有了一種參考模型。

後來Teddy畢業之後第一個參與的Scrum專案，一開始Teddy就是混用之前所學的OOAD方法，加上Scrum框架來進行開發。在Scrum專案開始之前，需要花一點時間準備product backlog。這段時間所要進行的活動在Scrum框架中並沒有特別著墨，反正Scrum只要求有product backlog便可開工，至於如何產生product backlog，是否需要一個軟體架構來支援後續開發活動，則並沒有規範。

後來Teddy借用UP的方法，把這段時間視為inception階段，用來釐清專案最重要10%~20%的story，以便產生初始的product backlog。之後，便可開始第1個sprint。

 

UP的四個階段，節錄自《The Unified Software Development Process》。

***

這個專案的特性，需要一個具有擴充性的軟體架構，以變應付日後各種不同的軟硬體設備。但是Scrum與敏捷開發都說，軟體架構是「長出來的」，不能像waterfall時代保留好幾個月什麼事都不做，專門用來設計軟體架構。怎麼辦？不知道，Scrum沒教。不過沒關係，回到UP的框架中，基本軟體架構是在elaboration階段所建立起來的。看到這邊鄉民們不要以為elaboration階段是waterfall方法中的「分析」或「架構設計」階段，而是借用完成一個個end-to-end story（或use case，UP稱此種開發方式為use case driven）的過程中，逐一「長出」架構的雛形。所以這樣的架構是「可執行的軟體架構」，而不是一個沒有任何功能的空架子。

因此，依據敏捷開發value-driven的精神，在初期的sprint中，先挑選對使用者價值高，同時對於軟體架構成長有決定性影響的story出來開發。在elaboration階段結束之後，軟體架構的基本雛形也就完成了。

在inception與elaboration初期，Teddy曾經開過幾次分析會議，用來和團隊成員討論架構設計的問題。先確定一些想法的大方向大家是否同意，然後就透過完成幾個簡單的story來驗證這些觀念，這些story有幾個特性，首先當然需要具備end-to-end的特性，這一點很重要。其次，為了快速驗證架構設計的可行性，story可以沒有GUI，而是透過文字介面來操作。

***

看到這邊Teddy先做兩點結論：

• 敏捷開發建議不要做Big Up-Front Design，但這一點並不是說不要做任何的Up-Front Design。常常有人誤會敏捷開發不需要做任何的事前設計，這是錯誤的。至於怎樣的Up-Front Design是剛剛好，不至於走回傳統的Big Up-Front Design，這個界線的拿捏，就需要一點功力。
• 如何將傳統OOAD方法融入到敏捷開發之中？如果是Larman所介紹的UP方法，因為該方法本身就是iterative與incremental，理論上應該是可以「無縫接軌」的在敏捷開發中直接套用。但實際上還是有需要調整的地方，例如Larman的方法採用Use Case撰寫需求，而主流的敏捷開發採用user story，這兩者的顆粒大小不一樣（後者比較小）。在一個需求粒度小很多的開發周期中，要套用OOAD那套建立use case model、概念模型（conceptual model）、設計模型（design model）的步驟，這中間存在著不小的缺口（gap）

***

以上兩個問題有一個很簡單的解法，就是Teddy在本篇提到的，套用UP的觀點把專案開發看成4個不同階段（phase），然後在inception與elaboration初期從主要的user story中嘗試建立起可執行的軟體架構雛形。為了達到這個目的，在專案初期分析、設計活動所佔比例或稍微高一點，但是這些活動的產出物不是傳統的分析、設計文件，而是透過實作一個個user story而「長出來」的可執行軟體，以及支援這個可執行軟體的架構雛形。

***

友藏內心獨白：這一篇要花一點腦筋。