我的推文講的很亂.故改PO文來回 ><
※ 引述《abadcafe (abadcafe)》之銘言：
: 首先, 這個世界上並沒有一個"大陸版快速迭代waterfall".
: 全世界只要講到"快速迭代模式", 基本上就都是指的我所描述的那種快速迭代模式. 無論
: 是在北美還是在歐洲都一樣. 這並不是大陸的特產. 歐美業界提出並實行這個模式很多年
: 了. 詳見: https://en.wikipedia.org/wiki/Iterative_and_incremental_development
: 而快速迭代與waterfall的分別, 你需要注意其前提: 分而治之. 如果沒有需求的分解, 不
: 管你怎樣爆肝, 也不可能把waterfall壓縮到很短的週期.
: 傳統的waterfall並沒有這個步驟, 他們會在整個系統設計完成之後才開始coding, 整個系
: 統coding完成之後才開始testing. 這才是waterfall被詬病的地方.
: 這裏我要再強調一次, 在快速迭代模式中, 每一個迭代過程你既可以使用waterfall, 也可
: 以使用TDD或者別的什麼, 這並不衝突. CI也是一樣.
: 另外, 關於敏捷我要多說一句, 敏捷不是銀彈. 真的在大項目中實行一遍TDD, 你就知道
: TDD的問題在哪裏了: 1. 工作量暴增. 2. 面對頻繁變化的需求, 你會很快厭倦編寫那麼多
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^
: 測試代碼然後又看着這些代碼作廢. 這都是人力的浪費. 你看看前幾年TDD有多火, 近幾年
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
不好意思.以下恕刪 @@
(以下敏捷性開發 以SCRUM來論)
首先 TDD(測試先行) 絕對會讓工作增加(以產品週期初期來看的話)
(如果以都是會寫TEST的角度來看的話.其實工作量差異應該很有限才對)
但其所帶來的品質有辦法對應其工作量增加的"成本" (人力/時間/錢/資源 等等)
再者.敏捷性開發的需求不是可以無限量改的.
因為敏捷性開發強調"成本固定".
在成本固定的情況下.在每次哩程碑會議驗收完成後可以提出需求變更.
但需求變更也是要算成本的.例如:
原本總成本是 N 然後消費完成會變成 K 個功能.
而假設提出需求變更的對象內容需要成本是 N/10 那相對的
就需要進行捨棄未完成功能的 K/10..換句話說 總成本是固定的.
(這也我認為RD/QA推廣敏捷性開發的主要好處之一)
簡單來說.無限凹RD/QA加班.這種做法就已經失去敏捷性開發的主要意義之一.
另外回到TDD. 這部份除了可以應用在工程師自身的開發流程外.
如果團隊使用敏捷性開發.那TDD就可以應用在整個產品/專案.
(因為在會議上就會進行功能規格定義所以 RD/QA 可以同時作業...)
而大量使用TDD的好處.在 專案/產品 部份可以提高 哩程/全部 的驗收品質外.
更可以減少因為RD無限壓線.而造成凹QA無限加班的情況 =_= (畢竟不能產出屍體)
而在RD 個人/團隊 大量使用TDD的好處.除了可以提高程式品質外.
還可以訓練RD的設計品質 (因為設計完成才能寫TEST 換句話說 不能邊寫CODE邊想設計)
而且如果再搭配自動化的協助(EX: CI)
也可以降低因為 TDD或UNITTEST 所增加的開發成本.
因此不管是TDD還是敏捷性開發對開發 產品/專案 應該都有一定的助力才是 ~_~a
以上是我所理解的推廣型Scrum和TDD...也是我推文所要講的東西 Orz...