像是最經典的例子，要開發某個系統的功能，團隊成員去跟客戶聊了以後，大概得知道是要做什麼功能，然後就列下了「功能清單」，有時候時間足夠的話或許還可以再補個驗證條件，或者一點點的業務流程說明，當然絕大多數的情況是這些內容都沒有提供的。
好吧，那怎麼著，事情總得做下去人總要往前走，於是軟體功能就變成需求蒐集者與系統功能實作的人不停的溝通細節與討論，然後就做下去，每當要做某一個功能，就針對單一的功能得下去討論細節，並且快速的與需求方進行交互討論，用以確保這樣的模式可以讓開發團隊正常運作~!!!
這看起來非常的敏捷，非常的結合了核心精神，重於溝通與用戶回饋，實在堪稱經典範例 !!
但...
如果把他的案例放大呢...
一個需求蒐集者 假設我們把它當BA/SA 來看，一對一的運作模式沒有問題!~
但當BA同時要own 2~n個以上的系統，並且同時對著多個開發人員在嗷嗷待哺這些「本來就該被捕上的需求細節」時，惡夢就開始產生了!
這裡第一時間被挑戰的就是人的記憶力，當你同時處裡非常多功能的需求的時候，即便這些內涵都是屬於同一個系統內的，但你毫無任何的紀錄與流程備註，你唯一能依賴的只有你的淺層記憶，還有那簡短的可憐的功能清單列表，我實在非常難相信能夠記得住!!
在這樣的開發流程當中，已經可以發現到 需求獲取以及功能實作的資訊揭露的嚴重失衡，到了要開發動手的階段才開始問需求，這是不切實際的，真正的敏捷是在動手開發的階段已經知道需求，並快速的開展架構規劃與雛型實作，在一個開發團隊中若先期沒有做需求蒐集品質的把關，我非常難相信任何的方法論可以拯救最終的產出，要馬作的痛苦萬分，要馬加班改到天荒地老。
除此之外，我更覺得有件事情更難被接受，在這樣的不清楚需求細節的情況下，就要去制定API，而且還需要兩種類型的API都得做，一個是業務終端聚合的API 定義 ( ex: web service interface) ，另一個是Domain class 的基於業務交互所需要的API !!
郎客棺阿，在這樣的需求獲取的品質之下，我想肯定終究會導致到以下的情況
- 只能定義非常不明確的API
- 只能定義很小眾的API來應付眼前大概最理解的需求
- 功能實作反饋後才發現需要大修
- 或者... 根本定不太出來API
敏捷一直在強調著 不要做大而全的規劃，但可也得給個小而精的準備阿，
否則一切都在變動中渡過，就連最初最小的樣貌也都渾然不知，然後要投入大量的資源時，
面對的困境與壓力實在不小，不強調做文件並不代表完全不做的阿 Orz ...
沒有留言:
張貼留言