-- NORMAL --

我對所謂的Agile的新理解

話說來到現在這公司已經一年半左右了，公司在軟體開發上一直在朝著往敏捷開發的路上走著，但我始終感覺到這個開展的路徑有點詭異，似乎有些走偏了...

像是最經典的例子，要開發某個系統的功能，團隊成員去跟客戶聊了以後，大概得知道是要做什麼功能，然後就列下了「功能清單」，有時候時間足夠的話或許還可以再補個驗證條件，或者一點點的業務流程說明，當然絕大多數的情況是這些內容都沒有提供的。

好吧，那怎麼著，事情總得做下去人總要往前走，於是軟體功能就變成需求蒐集者與系統功能實作的人不停的溝通細節與討論，然後就做下去，每當要做某一個功能，就針對單一的功能得下去討論細節，並且快速的與需求方進行交互討論，用以確保這樣的模式可以讓開發團隊正常運作~!!!

這看起來非常的敏捷，非常的結合了核心精神，重於溝通與用戶回饋，實在堪稱經典範例 !!

但...

如果把他的案例放大呢...

一個需求蒐集者 假設我們把它當BA/SA 來看，一對一的運作模式沒有問題!~

但當BA同時要own 2~n個以上的系統，並且同時對著多個開發人員在嗷嗷待哺這些「本來就該被捕上的需求細節」時，惡夢就開始產生了!

這裡第一時間被挑戰的就是人的記憶力，當你同時處裡非常多功能的需求的時候，即便這些內涵都是屬於同一個系統內的，但你毫無任何的紀錄與流程備註，你唯一能依賴的只有你的淺層記憶，還有那簡短的可憐的功能清單列表，我實在非常難相信能夠記得住!!

在這樣的開發流程當中，已經可以發現到 需求獲取以及功能實作的資訊揭露的嚴重失衡，到了要開發動手的階段才開始問需求，這是不切實際的，真正的敏捷是在動手開發的階段已經知道需求，並快速的開展架構規劃與雛型實作，在一個開發團隊中若先期沒有做需求蒐集品質的把關，我非常難相信任何的方法論可以拯救最終的產出，要馬作的痛苦萬分，要馬加班改到天荒地老。

除此之外，我更覺得有件事情更難被接受，在這樣的不清楚需求細節的情況下，就要去制定API，而且還需要兩種類型的API都得做，一個是業務終端聚合的API 定義 ( ex: web service interface) ，另一個是Domain class 的基於業務交互所需要的API !!

郎客棺阿，在這樣的需求獲取的品質之下，我想肯定終究會導致到以下的情況

1. 只能定義非常不明確的API
2. 只能定義很小眾的API來應付眼前大概最理解的需求
3. 功能實作反饋後才發現需要大修
4. 或者... 根本定不太出來API

敏捷一直在強調著 不要做大而全的規劃，但可也得給個小而精的準備阿，

否則一切都在變動中渡過，就連最初最小的樣貌也都渾然不知，然後要投入大量的資源時，

面對的困境與壓力實在不小，不強調做文件並不代表完全不做的阿 Orz ...

繪製Component diagram的時候的盲點

昨天才講到說繪製functional view 的時候該注意的事情，但後續又發生悲劇了
提到說要產製一個component diagram，但是我就直接的把functional view 的內容給放大開來往下開展，這樣的代價就是直接在一張圖上面，充斥陳列了超級多的資訊，讓人難以裡解，而且遇到Cross module的服務關聯操作時，會讓整張圖都給拆解崩潰，這樣不是個好辦法，話說以前唸書都知道，但真的工作去遇到時就是會沒去注意這些事情，這跟熟練度有關，也意味著作的太少，所以就會有這種盲點跟搖擺...

接下來應該要改變一下工作心態與策略，主管提出觀點與建議時我不能盲目的就往下走，還是得自己問問自己，現在當前的Context是什麼? 需要被納入追加的功能與資訊該用到什麼樣層級的資訊來揭露? 還有，每次都該重新審視檢閱產出，問問自己是否符合早前所學的知識，用以確保這樣的產出有沒有問題，然後找出理論與實作差異在哪，為什麼會有差異！！！

如何去捕捉你的functional view of architecture ?

今天工作的時候發生一件很阿呆的事情，目前進行中的新系統的規劃已經先跑過了一次Concurrent view 的構圖與討論，也已經即將完工了，然後即將接著進行的是functional view的架構描述，可是我一時之間卻啥也沒想到，只是很蠢蛋的看著concurrent view的內容，去硬轉並畫出functional view  concept，然後被打槍了XD

實際上這裡應該根本就是回歸源頭，function本身就是business requirements artifact，沒有需求就沒有function，雖然常常在跟人講說這是關鍵但自己卻也忘了這回事，這表示我真的作的太少了lol

這邊說到要回歸business requirement，就讓我想起勾勒不同的actors需要以及彼此對系統的交互行為，不自主的就想起UP的那一系列歸納的工作，use case diagram的景象油然而生，當然我今天還是沒有去畫出這些東西來，因為還太早了，都還在非常初期的需求捕捉階段，只是為了要能描述新的平台能否滿足所有的business concern...

系統整合的淺談

早期的系統整合方式，一開始是透過檔案，反正就大家都來排隊對同一份檔案或一群檔案作操作，就可以達成資訊傳遞共享的目的，雖然代價是檔案壞掉就壞掉了...

再來一陣子，稍微好一點的是用DB，但是彼此之間的資料交換變成是DB Schema owner 之間的dependency, owner 若改動了schema，若其他參考的應用程式沒跟著去更新，那這樣也會出問題...

好吧，後續的再高一點的選擇就是透過Model API 來封裝了存取的語意，用來統一存取溝通，這樣就沒有因為Schema改動而有的問題產生，可是這樣還是有個大問題，就是一旦Model成長的快速，提供的多面向的語意查詢開始紛雜混亂，變得甚至可能會讓原先的Method Signature都給打破了，這時候又該如何 ?

這時候可以考慮採用Message Queue了，Message 傳遞的資訊不是一個Conversational的語句片段，他強調傳遞的是一個完整的scenario，所以他可以指定發給誰，而Message Broker可以陸續去指派其他的接收者，甚至作反還重新執行的行為，此外，一旦遇到越來越多不同的呼叫訊息版本以後，可以透過Broker來傳遞穿透改以不同新版本的Message來處理，進而達成企業需求整合的目的，會用到這個地步的時候，往往是因為不同的需求來的太多太快，甚至已經是無法透過版本控制來解決業務需求了，透過這樣的Message Mechanism能解決相關的問題!!!