軟體架構勒？

Dec. 21 16:12~17:17

 

很多跑敏捷開發的朋友對於在敏捷開發中如何設計軟體架構一直有不少疑問。廣義地說，無論是跑什麼開發流程，軟體架構設計本身都是一個傷腦筋的議題，只不過在傳統Waterfall流程當中，因為有專屬的「軟體架構設計」階段，所以讓人產生一種「在Waterfall中軟體架構設計非常明確」的 錯覺 感覺。實際上，跑Waterfall流程的確可以產生一份非常明確的軟體架構設計，只不過這份軟體架構的實用性經常被開發人員打上一個大問號，和最後開發人員實作出來的軟體系統之間存在很大的差異性，可能「連他爸爸（架構師）都認不出來這是他的親生架構」。

今天聽Erica提到有許多人在上完「使用者故事對照工作坊 (User Story Mapping Workshop)」之後跑來問他，當完成使用者故事對照（用戶故事地圖）之後，要如何將銜接軟體架構的設計。如何設計軟體架構這個問題，Teddy在跑Scrum以及學習User Story Mapping的時候也遇到，以下是Teddy的做法：

• 套用物件導向設計與分析的做法：Teddy曾經在〈在領域模型上講故事〉文章中提到相關做法，如果把「使用者故事對照」這張地圖類比成UML裡面的Use Case Model，就可以從中找出重要的概念，並使用這些概念建立起軟體系統的「領域模型」。有了這份領域模型，就可以開始施考採用哪種軟體架構風格（software architecture style），例如MVC、Layered、Client-Server、Plug-ins、Microservice等，來「容納」這些重要的概念。
• 向RUP（Rational Unified Process）學習：RUP也是一種疊代與增量開發方法，除了疊代（iteraion）以外，在RUP當中還將軟體專案分成四個階段：Inception、Elabration、Construction、Transition，每個階段可以包含若干的疊代。第一個階段用來驗證專案的可行性，通常很短，有點類似某些敏捷開發做法所說的「Iteration 0」的味道。第二個階段Elabration結束之後，大概會完成20%的 use case實作（RUP使用use case撰寫需求），主要的專案風險已經被釐清，並且產生「software architecture baseline」。換句話說這個階段結束之後產生軟體架構雛形，這個雛形可以支撐後續Construction階段的主要開發工作。

如果你的專案需求相對比較明確一些，則可以套用RUP的做法，首先透過User Story Map上規劃產品釋出計畫（release plan），或是規畫好幾個「最小可行性產品（MVP）」的學習計畫。把每個release plan開發週期視為一個RUP專案，然後朝向當完成20%最重要的user story的時候，能夠讓軟體架構成型，設計「足夠的軟體架構」來支持這些產品釋出或學習計畫。在每一個疊代週期挑選user story的時候，除了考量user story對客戶的價值以外，有時也要考慮挑選對軟體架構風險比較高的user story優先開發。

• 重構：敏捷開發的主要目的之一就是要對付複雜的軟體開發專案，也就是要避免「計畫趕不上變化」的情況。所有原本可行的事物，都可能因為「發生改變」而導致失敗。這時候只能藉助重構的力量，讓軟體架構可以重新回到正軌。要讓重構可行，除了需要了解重構的技巧，還必須有足夠的測試案例以及持續整合來驗證重構沒有讓系統「越補越大洞」。

***

接下來打個廣告，泰迪軟體在2017年1月8日舉辦「使用者故事對照工作坊 (User Story Mapping Workshop)」一日課程，歡迎對這個主題有興趣的朋友一起學習、成長。

***

友藏內心獨白：關關難過關關過。