之前對于敏捷開發，我還是比較喜歡Scrum的方式，不過Scrum的方式大家也知道，雖然很敏捷，但是總是有些缺陷的，如下：
1、缺少對多團隊參與的大型項目的指導框架。（我的想法：敏捷一般是針對小團隊，但是類似大公司，比如微軟、Sony這樣子的，需要共同開發一個大的軟件，比如Windows 8，能不能運用敏捷，怎么去運用敏捷，這種問題在現有的敏捷體系下很難回答出來）
2、缺少開發和QA測試的集成模型。（我的想法：現有的敏捷中對于測試這塊的確重視不多，甚至有人認為開發做得好完全就不必測試了，其實真的開發做的100% Bug Free，這個世界上的確不用測試了，但是能嗎？另外，開發一般只考慮正在做的這個功能是否能夠正常工作，但是對于多個功能之間的調用之類的測試就不會考慮很多）
3、無法支持需求驅動下完整的可追溯性。（我的想法：Scrum不推薦寫文檔啊，提Bug啊，最好所有事情，都能面對面交流就行了，但是實際情況呢？面對面的交流，也許你今天能記得，但是明天可能忘記；如果只有一個Bug要修，你記得很清楚，但是如果是100個Bug要修呢，你能記得很清楚嗎？如果你手下有N個開發，你怎么去記得哪個功能分配給誰在做呢？）
4、整個團隊完全致力于項目的開發是基本前提。一旦開發團隊的方向出現變化，會導致項目的崩潰。（我的想法：其實這個現象已經在很多開展敏捷開發的團隊中見到，都是一開始滿意歡喜想上馬敏捷，最后卻崩潰了。因為“專家”所謂的敏捷固定過程中，人人都要主動交流啊，自領任務啊，估算任務等這種很理想的狀態并不是所有公司，所有人都能實現的，一旦當偏離值出現的時候，也就是這個項目崩潰的開始。）
5、一旦使用敏捷方法失敗，不但時間會被浪費，團隊人員也會出現松動。當相關人員離職后，整個過程的經驗積累也無法得以保存。（我的想法：同第三點）
很多公司雖然在搞敏捷，其實都是被很多所謂的“專家”搞混了，以為敏捷會有一個固定的模式，其實這個是不對的，敏捷只是一種指導思想，軟件的生命周期不會因為敏捷而發生變化，還是會有需求，還是會有開發，也還是會有測試，在這個的基礎上，怎么去讓這些過程能夠銜接得很好，最后得到一個質量好的產品，才是最重要的。顯然，敏捷是其中的一個方法，但是它也不是萬能的，因為不同的產品會有不同的開發模式，比如，銀行軟件可能就不太適合敏捷。
在我看來，SpecDD其實是對于Scrum的一個升級。
這個模型中，大家可以看到Scrum的精神思想其實也完全體現得淋漓盡致，這個也就是為什么我說SpecDD其實可以看作Scrum的一個升級版一樣。
在這個模型中，我最有感受的是測試這塊，所以下面我就主要說說這塊，今天就暫時不談了。
（未完待續）