反思：別被敏捷忽悠

轉自：http://www.infoq.com/cn/news/2014/02/agile-rethink

反思：別被敏捷忽悠

做者 崔康 發佈於 二月 13, 2014

• 開發自測不足——新功能都開發不過來，自測隨便意思一下就行了。
• 迭代發現的一堆Bug不改——產品仍是過渡期，說不定集成測試前BUG就消失了。
• Bug不須要改——我剛和產品溝經過了，需求變動一下就行了。
• Bug無效——我代碼就是這麼實現的嘛，這麼處理也沒什麼很差。
• Bug掛起太多——你看看市場競爭這麼激烈，每一個Bug都深刻判斷咱們哪有時間。
• 發佈產品已知Bug很多—— 迭代發佈產品有些遺留Bug很正常，慢慢優化嘛。

據dylan所說，其領導的團隊採用了旁敲側擊的方法提高研發質量，好比幫忙開發便利的自測工具、合做分析代碼覆蓋率、冒充用戶上論壇投訴、拿競爭對手的結果來刺激團隊等等，但始終是治標不治本。

回頭再看看，全部掩蓋在敏捷研發過程當中的漏洞，日積月累，最終仍是會由整個業務團隊來承擔苦果。因此時常在想，敏捷研發理論是否被神化了，是否常被錯誤理解而讓不職業的現象層出不窮？敏捷不是新的研發理論，只是項目管理的一種形式。

 他認爲，瀑布研發和敏捷研發沒有本質不一樣，理由以下：

• 是迭代發佈的週期不一樣？某些互聯網產品的版本發佈週期一點都不短。入口級的移動APP動輒上百人的團隊，規模比多數PC軟件團隊還大。
• 是有云和沒雲的不一樣？不少行業的後臺（雲架構）比通常互聯網公司複雜多了。
• 是收費和免費致使的不一樣？傳統行業也有不少免費軟件。互聯網的有些免費軟件比傳統軟件質量要求更高。
• 是對產品迭代發佈的質量要求不一樣？
• 是對文檔的要求不一樣？

結論就是，沒有一個要素能真正把互聯網和其餘軟件領域區別開來，因此dylan認爲：

瀑布研發和敏捷研發沒有本質不一樣，，更別說誰好誰壞了，只是由於行業競爭的不一樣，看起來交付節奏不同而已。節奏和軟件研發的傳統精髓沒有關係。

除此以外，dylan還批判了常見的幾個敏捷誤區。剛畢業的學生進入公司要怎麼培養？dylan建議2-3年的職場新人不要學習任何敏捷流程的理論：

• 測試崗位的就好好的把一個功能設計出N種場景，使用各類工具反覆測試找敏銳感。
• 開發崗位的不是要儘快實現一堆功能，而是先充分理解架構，而後對提交的每一行代碼負責。
• 產品崗位的多體驗產品多接觸用戶，頭幾年最好脫離QQ的關係鏈，鍛鍊發佈獨立產品的能力。

總之，dylan認爲，入行新人要學四個字——職業操守，刻在內心，打好基本功，將來無論在什麼項目都會受用。

另外一個誤區，dylan認爲是「溝通比文檔更重要」：

這句話看起來有道理，若是你是幾我的的小團隊，若是人員穩定，功能模塊比較聚焦，生命週期也不太長，也沒客戶找你要什麼手冊，確實不須要寫什麼文檔。

可是若是你是如下狀況的團隊，dylan認爲文檔可能真的比溝通更重要：

• 團隊人數數十人甚至上百。
• 項目生命力長，每一個版本都有新功能，模塊愈來愈多，愈來愈複雜。
• 異地團隊，合做研發。
• 有外包，合做方團隊協同工做。
• 團隊職業化水平高低不齊。
• 團隊不太穩定，或業務歸屬部門不太穩定。

dylan特地列舉了幾種缺少文檔的糟糕狀況：

• 某產品經理忘了半年前的某個功能的具體邏輯，尋求測試同窗的幫助。
• 某開發參加高職級晉升，手上沒有一個像樣的軟件架構圖，拿着測試同事梳理的邏輯架構圖去評審。
• 一個嚴重Bug的坑在N個項目組被踩了N次，修復每一個Bug後的註釋只有幾個字。
• 跨地域的團隊，或者先後臺的團隊之間，發生Bug時互相爭執半天，討論誰該負責修復Bug，彼此不熟悉對方的內部邏輯。
• 至於沒有參考文檔致使測試投入浪費的事就太常見了
• 公司業務調整，跨部門和跨地域的業務交接不太愉快，交接效率低。

第三，dylan認爲不要「邊重構，邊生活」：

之前公司的開發，30-40%的時間花在概念設計和架構設計，30%在細節設計，10%在編碼, 20-30%在代碼自測。編碼自己只佔不多一點時間。技術總監這樣教育新人：你不是coder，你是designer！coder是比較低級的工做，軟件設計纔是高端活。

任什麼時候候的思考，對於架構的投入怎麼充分都不爲過。微信發佈那麼多版本，這兩年重構可能幾乎沒有。這須要有人儘早思考清楚將來作朋友圈，作開放接口，作插件化等等，開發知道了將來要演進的形態，在一開始就有所規劃，預留接口。不然，今天決定要作SNS，重構一次，明天要作插件化，再重構一次，後天做開放平臺和公共賬號，再重構……對公司來講就是個噩夢了。

最後，dylan強調，不要存在「迭代版本的BUG多一點是正常的」的誤區：

每一個交付到測試團隊的產品，必須是可測的，自測過的。不可測的版本就不叫交付。對於可測內容追求在一段時間週期內，儘量高質量的發佈，是修煉職業操守的目標，更是精品團隊的目標。每個掛起的有效Bug都須要確認：爲何改不了？何時改？對發佈影響如何？

若是因市場形勢必需要儘快發佈，至少遵照一個底線：嚴重Bug必須整改並且優先整改。所謂嚴重就是可能讓用戶拋棄你的問題：速度慢，賣點明顯不如對手，賣點沒法正常使用，不穩定，可能給用戶帶來額外損失（手機系統，安全，帳號，費用等等）。這樣的發佈還不如不發。

隨着敏捷開發在IT行業的深刻推廣，敏捷的優勢再也不被業界無限放大，而更多的社區聲音開始討論敏捷的正反兩方面，dylan的觀點能夠給讀者朋友一些不一樣的啓示和借鑑。