qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

          什么是SpecDD?

          之前對于敏捷開發,我還是比較喜歡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的一個升級版一樣。

            在這個模型中,我最有感受的是測試這塊,所以下面我就主要說說這塊,今天就暫時不談了。

            (未完待續)

          posted on 2013-06-13 10:45 順其自然EVO 閱讀(259) 評論(0)  編輯  收藏 所屬分類: 測試學習專欄

          <2013年6月>
          2627282930311
          2345678
          9101112131415
          16171819202122
          23242526272829
          30123456

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 贡嘎县| 梧州市| 卓尼县| 遵义县| 宁阳县| 寿宁县| 浦东新区| 永登县| 滦南县| 陕西省| 阿拉尔市| 云安县| 盖州市| 南郑县| 诸暨市| 阳东县| 天全县| 彭山县| 大石桥市| 图们市| 八宿县| 辽阳县| 东山县| 雷波县| 筠连县| 衢州市| 南皮县| 白山市| 察隅县| 博野县| 鸡西市| 平果县| 响水县| 松江区| 九龙县| 中江县| 勃利县| 高要市| 交口县| 会东县| 台北县|