搞笑談軟工

2016年12月24日星期六

2016大阪姬路神戶考察之旅Day8-B夙川公園賞櫻

Dec. 23 16:05~17:05

▼今天要離開神戶前往大阪，離開神戶前還有最後一站先到夙川公園賞櫻。從神戶三宮買了前往夙川驛的電車票。

▼一下電車在車站內就可以看到夙川公園盛開的櫻花，雖然已經過了滿開的最高點，還是很漂亮。

▼拖著兩個行李逛公園太累了，還好車站有行李櫃可以寄放，只是身體輕鬆卻瘦了荷包。

▼看這個地圖櫻花開放的區域還滿大一片的。

▼有一群幼兒園的小朋友也出來賞櫻，第一次看到這麼大台的「兒童推車」。

▼櫻花。

▼不知不覺走到下一個車站，準備回頭。

▼除了櫻花以外沿途有ㄧ些步道兩旁種滿大樹，走起路來也很舒服。

▼另一組可愛的小朋友，人數比較少推車也比較迷你。

▼更多櫻花。

▼櫻花寶座。

橫向生長的松樹居然還如此茂盛，好特別。

▼離開夙川驛前往大阪。

***

友藏內心獨白：看完收工。

2016年12月21日星期三

很多跑敏捷開發的朋友對於在敏捷開發中如何設計軟體架構一直有不少疑問。廣義地說，無論是跑什麼開發流程，軟體架構設計本身都是一個傷腦筋的議題，只不過在傳統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)」一日課程，歡迎對這個主題有興趣的朋友一起學習、成長。

***

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