Gelis 技術隨筆-部落格

前言 前一篇文章中『 從使用者需求、談架構設計 』，筆者以一個房貸線上申請系統的例子，關於一個從使用者需求、來談架構設計的一個比較實際的例子，當時，筆者以 UML／OOAD 常見的循環星型分析法，帶著各位由系統分析開始、如何串聯到系統設計、並解釋因為從系統設計開始，便可牽涉到 Platform/OS/Framework/程式語言 等等，而在 UML 這裡也有模型驅動架構 MDA (Model Driven Architecture) 可以補助，課程中，我也利用的這樣的概念，將 Domain Class Diagram 帶入細部 Class Diagram 分析時，拆解為兩塊，一個是 BO (Business Objects) 另一個是 VO (View Objects)，接著，並實際的撰寫程式，並實作出最小可行性產品。 在今天的這一篇文章裡，我將利用在 Clean Architecture 書中的一個整潔的軟體架構的概念，將我三年前所設計的 EasyArchitect Framework 來做一個應證，從頭來探討軟體開發、從需求面開始、你的需求大方向的掌握度其實會決定你的架構設計的方向性是否恰當、符合所需、不是過度設計的架構。好，我們接著往下看。 需求掌握度 圖（一）、Impacts Mapping to User Story Mapping 圖片來源： https://www.slideshare.net/chassa/2014-0618srdimpact-mapsstorymapsen 為什麼談需求的掌握度？訪間，許多軟體開發方法告訴你的大部分是，何時該做什麼、那些角色該關注什麼？有哪些會議？什麼時候招開？該注意什麼？以敏捷創建使用者故事地圖（User Story Mapping）來說，它敏捷需求規劃中的一個流行方法。用戶故事地圖可以將你的 Backlog 變成一張二維地圖，而不是傳統的簡單列表。用戶故事地圖可以讓你更容易看清 Backlog 的全貌。這概念真的非常好，因為它幫助你有更好的進行疊代的增量式開發，同時確保早期的發布，可以驗證整體架構和解決方案，為傳統的開發計劃提供了一個更好的替代工具。 且創建 User Story Mapping 可以有七～八個步驟，因為篇幅關係我不在這一一說明，第一個步驟是招集 3-5 對產品熟悉的人一起討論，並讓每個人在便簽紙

前言 在最近這幾年，『敏捷』一詞，幾乎成為軟體開發領域的罩門，企業內部軟體發部門成功的例子不少，但是失敗的例子幾乎也是隨處可以聽到，真的只是就像人家說的，因為『成功經驗』無法被複製？所以，有些人無法成功，但….？真的只是這樣嗎？ 混亂的年代 在最近這幾年，您是否也有感覺到幾件事情，在軟體技術蓬勃發展的現代，各種流程開發的方法如雨後春筍般不斷湧現，從早期的 Waterfall 還有 SDLC/RUP/AUP/XP，或是近代的 Agile／Scrum／Kanban／LeSS 等等…每天都有新的框架 Framework 出現（尤其前端更是如此），軟體工程師不斷地追求新技術，似乎，不持續的學新技術，就會跟不上這個世界，某種程度來說，不能說不對，但是若陷入工具的迴圈裏面，那可能會浪費許多寶貴的時間。在專案裡面使用不適當的套件，可能會埋入一些隱憂，未來可能生成其他的技術債，浪費團隊的時間。 在軟體技術市場、需求、市場多變現代，我們在為我們的產品、與團隊選擇一個符合市場需求、使用者需求、團隊 Skills、客戶環境、考量未來乘載量、甚至需要搭配設計面、使用哪一種軟體架構的設計方法，這些都會是考量因子， 敏捷不是沒有門檻 『軟體開發沒有銀彈』這件事，我已經在各個不同的企業端提過數次，以我自身的經驗也深深地認為，其實敏捷是有門檻的，怎麼說呢？在國外，真的導入敏捷成功的團隊，其實，團隊成員本身都已經沒技術上的問題，或者，應該這樣說，就是本身對於軟體開發架構、實作技術、Design Pattern，甚至舉凡包括版本控制系統 Version Control 的使用（延伸閱讀： 關於團隊使用 VSTS/TFS 原始碼控管的 - 三兩事 ）、個人的工作管理、各種 Work Items 的 Tracing Tool，專案管理工具的使用等，更不要說團隊開發共同規範其實都已經以一定的水準了，而他們推行敏捷，純粹只是要解決『人』的問題而已。 而所謂的『人』的問題，不外乎就是，『溝通』、如何有效的溝通？團隊間的協同工作，各成員主動的管理風險、彼此之間的信任、並且團隊成員有一定的靈活度，這得從文化著手， 當你團隊的技術到達某一定的門檻之後、再談敏捷 由上圖（一）所示，企業或開發團隊要進行敏捷時的軟體架構 與 人之間的關係，圖中所要表達的是，當你要進行敏捷（文化）時，您得在基礎架構規範、也就是，即便團隊之間