【編者按】說起敏捷大家并不陌生，自從國外引進后，一直都很火，很多人都在討論。無論是項目延期，失敗，質量低下等等，你總能聽到：“你是不是沒有敏捷？”。因此，敏捷就成了包治百病的“靈丹妙藥”。于是很多項目組公司開始學習敏捷、采用敏捷。但是遺憾的是很多人嘗試過后發現以前的問題并沒有被敏捷所解決掉，反而帶來了很多新的問題。
在《敏捷，是靈丹妙藥還是又一個忽悠？》這篇文章中也曾提到，很多人為了敏捷，文檔不要了，計劃不要了，測試用例也不要了，認為幾個人站在走廊里溝通溝通就把一切都搞定了，因為敏捷了嘛。但是問題并沒有因為“敏捷“了而被解決掉，于是乎得出敏捷是個忽悠的結論。
作者Dylan是騰訊無線研發部副總監，擁有十多年測試行業經驗。此前dylan在騰訊和華為主場展開了關于敏捷研發質量的技術交流。作為分享嘉賓之一的Mary就回顧通信和移動互聯網兩個行業的敏捷研發理念差異， 并結合自身經歷做了一番思考。下面我們一起來看下：
從傳統軟件業到移動互聯網- 質量標準的弱化
傳統大型軟件公司，開發節奏慢周期長，QA和測試環節受重視程度高，測試結論有權威性，越在后期發現的BUG讓開發人員如臨大敵。
轉型來到移動互聯網部門，咱開始學習敏捷研發理論了，接受起來蠻順利，隨著參與項目的增多，越來越感受到自己的職業價值觀不斷受到擠壓，各種混亂事件讓測試人員及團隊挺糾結，質量標準很難成為嚴格遵守的權威：
整個就是測試團隊的糾纏血淚史。這幾年我們也采用了旁敲側擊的方法提升研發質量，比如幫忙開發便利的自測工具，合作分析代碼覆蓋率，冒充用戶上論壇投訴，拿競品對手的結果來刺激團隊等等，但始終是治標不治本。
回頭再看看，所有掩蓋在敏捷研發過程中的漏洞，日積月累，最終還是會由整個業務團隊來承擔苦果。所以時常在想，敏捷研發理論是否被神化了，是否常被錯誤理解而讓不職業的現象層出不窮？
敏捷不是新的研發理論，只是項目管理的一種形式
傳統研發模式和敏捷模式到底有什么要素是不同的？或者說，傳統軟件和互聯網軟件有什么不同？
最后發現，沒有一個要素能真正把互聯網和其他軟件領域區別開來，所以我們只能這么看：瀑布研發和敏捷研發沒有本質不同，更別說誰好誰壞了，只是因為行業競爭的不同，看起來交付節奏不一樣而已。節奏和軟件研發的傳統精髓沒有關系。
今天競爭足夠激烈（利潤夠大），華為必須快速占領某國市場了，它可以立馬快速的研發和交付明天手機QQ成最大IM平臺了，它可以一年提交一個新版本，比傳統軟件業的質量環節更多更嚴。
研發團隊根據行業（用戶）需求和生存情況來決定敏捷節奏（如上圖的四種生存情況），但是團隊的內在素質能力不應該有什么差異。傳統軟件行業素養高的開發，換到互聯網團隊，同樣素養高。
批判常見的幾個敏捷誤區
既然如此，我們來依次對公司里流行的關于敏捷的偽論斷進行剝皮：
1．新人培訓從敏捷研發開始
剛畢業的學生進入公司要怎么培養？本人建議2-3年的職場新人不要學習任何敏捷流程的理論：
總之，入行新人要學四個字-職業操守，刻在心里，打好基本功，未來不管在什么項目都會受用。
2 ．溝通比文檔更重要
這句話看起來有道理，如果你是幾個人的小團隊，如果人員穩定，功能模塊比較聚焦，生命周期也不太長，也沒客戶找你要什么手冊，確實不需要寫什么文檔。
但是如果你是這樣的團隊，文檔可能真的比溝通更重要：
沒有文檔的惡果，可以參看以下的事件：
以上6個要素，符合的越多，文檔必要性就越大，尤其是以精品為唯一導向的大公司，首先要有對文檔的基本認識。無數軟件行業的先輩都不是傻子，文檔上偷懶誰都會。
這個行業也許不需要利用率太低，可讀性差，格式復雜死板，更新太頻繁的文檔，比如：
但是這個行業的團隊需要圖形化，模塊化，可視化程度高，邏輯詳細完整準確，容易傳播的文檔：如產品邏輯+異常邏輯圖，軟件架構設計圖，經典BUG根因分析，體驗/競品體驗分析公司可以考慮把可視化編輯工具集成到WEB端，直接在網頁上編輯和查閱文檔。
我們甚至可以利用創新的輸入工具，提高文本錄入的效率。如我們的APP自研反饋工具利用語音識別接口，錄入BUG的問題描述。
3． 邊重構，邊生活
竊以為這句話只在刀架在脖子上才有效。實在不得已而為之（例如面臨生死存亡之類的危機）。沒想清楚長期架構，最好不要急著開工。磨刀不誤砍柴工是真理。
以前公司的開發，30-40%的時間花在概念設計和架構設計，30%在細節設計，10%在Coding, 20-30%在代碼自測。Coding本身只占很少一點時間。技術總監這樣教育新人：你不是Coder，你是Designer！Coder是比較低級的工作，軟件設計才是高端活。
任何時候的思考，對于架構的投入怎么充分都不為過。微信發布那么多版本，這兩年重構可能幾乎沒有。這需要有人盡早思考清楚未來做朋友圈，做開放接口，做插件化等等，開發知道未來要演進的形態，在一開始就有所規劃，預留接口。否則，今天決定要做SNS，重構一次，明天要做插件化，再重構一次，后天作開放平臺和公共帳號，再重構…..對公司來說就是個噩夢了。
如果團隊沒有架構大牛，則需要充分的頭腦風暴，每個迭代不能只想近期要做什么，面向未來思考和歸納。警惕以下案例：
4．迭代版本的BUG多一點是正常的
首先，每個交付到測試團隊的產品，必須是可測的，自測過的。不可測的版本就不叫交付！
對于可測內容追求在一段時間周期內，盡可能高質量的發布，是修煉職業操守的目標，更是精品團隊的目標。每一個掛起的有效BUG都需要確認：為什么改不了？什么時候改？對發布影響如何？ （當然，因Android平臺的碎片化會帶來大量難以重現的機型相關問題，我們可以通過其它技術手段處理）
如果因市場形勢必須要盡快發布，至少遵守一個底線：嚴重BUG必須整改而且優先整改。所謂嚴重就是可能讓用戶拋棄你的問題：速度慢，賣點明顯不如對手，賣點無法正常使用，不穩定，可能給用戶帶來額外損失（手機系統，安全，賬號，費用等等）。這樣的發布還不如不發。
每個版本建議總結一下：嚴重BUG以及用戶投訴大的問題，根源是什么，改進措施是什么，歸檔分享。
對于迭代測試發現的一堆問題都攢到最后，期望有天能自動消失的項目團隊，我都不想點評了。每一個莫名放過缺陷的產品都可能成為一個折翼的天使。
精品研發團隊，應該對眼里的軟件錯誤有潔癖，就算修復不了，我也記錄下來錯在哪里。
對于敏捷研發的忽悠觀點，就批判這么多。精品觀，本人的理解首先要回歸職業的原點。每個角色堅守職業操守，會讓團隊成為老虎 ，讓我們在精品路上走得更遠。
文章來自：騰訊
CTO俱樂部是目前國內最有影響力、規模最大的技術管理者分享與交流平臺，由全球最大中文IT社區CSDN創辦。CTO俱樂部實行會員免費申請、實名認證的加入機制。自2009年創辦以來，已有注冊會員10000余名，覆蓋國內數千家IT公司和各行業企業研發部門的CTO、技術副總裁、首席架構師、技術總監、工程總監等高級技術管理者。更多精彩分享與交流機會，歡迎加入CTO俱樂部、關注CTO俱樂部微信號csdn-cto。
程序員人生，我編程，我富裕，記住wfuyu網，php教程，php學習，php手冊，CMS模版制作
聲明：本站大部分內容是作者原創，少部分收集于互聯網供大家一起學習，原版權很多不明，如有侵權請聯系本站，謝謝！
粵ICP備14040726號-1?? 2015-2020 程序員人生 版權所有
