在傳統瀑布式開發中, 最被人家詬病的地方, 就是反應太慢. 因為他要經過點子發想, 需求分析, 架構設計, 程式撰寫, 測試, 才能交付到客戶手頭上, 因此整個過程的回饋要拖得很久.
那要怎麼處理這個問題呢? 那我們來看看 agile 用哪些招式, 來減輕這個狀況.
1. 測試完後, 快速回饋給程式撰寫
為了做到這件事情, 提出了測試先行(Test First)的觀念, 先寫測試, 然後才寫程式. 所以當程式寫完了, 測試就會立即給你回饋, 看看程式是否運作正常.
2. 程式撰寫完後, 快速回饋給架構設計
當程式撰寫完, 需要再進一步思考, 架構要怎麼修改, 才能讓原有的架構更好維護, 幫助之後可以開發更快. 這時候便導入TDD 的做法. 也就是當程式通過事先寫好的測試後, 接下來透過 refactor, 來逐步調整程式的架構. 因為有測試這個安全網, 所以在做架構修改時, 開發人員比較不會這麼害怕.
3. 架構設計完後, 快速回饋給需求分析
做完架構的調整後, 我們想要知道是否照原先規劃的功能來實作, 因此我們藉由 spec by example 的做法, 利用 test cases 定義好何謂這個需求是做完. 所以只要當程式能夠讓這些 test cases 都通過, 就代表這個需求已經被實作完.
如果要再加功能, 就要先加 test cases, 才再修改程式. 程式一寫完, 也會利用自動化測試, 立馬回饋是否正確.
4. 需求分析完後, 快速回饋給點子發想
在這裡 lean startup 的想法, 不需要做很多, 但是提早驗證想法是否正確, 所以 Pretotype 的做法, Kanban WIP 的方式, 都在希望你早點確認你功能的假設是否正確, 而不是傻傻的一直做下去
寫了半天, 這些招式我們大多都沒用, 哭哭 …. 我們還是在 run agile 嗎? 我們好像只會用半套 agile - Scrum (誤) XDDD
留言列表
