敏捷實踐的誤區和陷阱的七個方面

我們認為敏捷實踐經歷的誤區和陷阱大致可以分成如下七個方面：特性團隊、人、浪費、區域性優化、軟體質量、測試自動化、流程。

　　特性團隊（Feature Team）

　　在組織中想要達到真正的Feature Team是一個很漫長的過程，當在組織中實現區域性的端到端的組的時候，更大的端到端的組的演變要求就會出現，因為這時組織中新的瓶頸會展現出來，這也是為什麼敏捷雖不能解決問題，但卻使問題更顯現地表現出來的原因之一。

　　在組織的轉型中，產品有非常龐大的老程式碼：

　　1、通常早期的Feature Team所包括的功能性測試不完全，外部的測試對於這些Feature Team所起到的保護作用還是相當重要的；

　　隨著時間的推移，Feature Team對於自己feature自動化測試加強以及測試能力的提高，釋出給外部的產品質量會大大提高；

　　2、對於外部其他組的依賴介面會很多，特別是組在不同國家的時候，溝通、交接和等待的浪費會很大；

　　3、當產品中開發部門和開發部門的依賴減少後，開發和測試的瓶頸會更突出；

　　4、當產品中各個功能部門的依賴減少的時候，產品和產品間的瓶頸會凸顯。

　 　想象一下從客戶提需求到最終提交功能需要經過多少個過程，特別是大型組織中的產品，端到端意味著幾十個過程甚至更多，Feature Team中能容納多少個這樣的過程就意味著這個Feature Team的靈活度有多高，本質上敏捷就是為了減少相互的依賴、等待和傳遞所帶來的消耗。

　　一個組織是一個龐大的系統，Feature Team的轉變過程意味著減少整個系統中的Limitation。

　　在向Feature Team演變的過程，在相對比較短的時間把原先十幾或者幾十Component Team打破組成新的Feature Team，這中間的風險在於：

　　1、組的成熟度：成熟度需要時間，也需要一些錯誤的代價；

　　2、組的長期成長和短期專案計劃：由於為了專案的進度而把對某領域很熟悉的組移出去做不熟悉的領域；

　　3、組織的產出效率：怎樣合理的利用現有的有經驗人員和新人，建立新結構所需要的基礎會使組織整體的產出效率減低；

　　4、不可控和無序：怎樣讓這些組高質量的釋出產品在轉變過程變的不可控。

　　理想和現實中的平衡是Feature Team所面對一個問題，劇烈的變動意味著劇烈的陣痛。

　　人

　　我們的轉變是基於Scrum+XP的方式，轉變的影響巨大，之前存在的許多職位、頭銜都會面臨變化甚至消失的可能。例如將不再會有專案經理來集中處理專案管理的工作，對於產品需求研發順序的管理也由以往的專案經理手中轉為產品負責人來負責。就算是最基層的開發人員和測試人員，他們的日常工作方式以及職責範圍也面臨著極大變化。這也意味著轉變可能會遇到非常大的阻力，人天性會抗拒未知的變化。

　 　某平臺部門的轉變尤其特殊，研發的老大意志堅定，在初期Pilot成功後，就大刀闊斧地進行組織架構改革，彷彿一夜之間所有的專案經理全部消失。而以往 圍繞功能模組所組建的分散的測試團隊以及開發團隊也被重組，每一個Scrum團隊都擁有好幾名來自不同功能模組領域的開發和測試人員，從某種角度來看，這 是我們所倡導的跨功能特性團隊的雛形。

　　各種形式的人員流失造成很大的困難，有人因為個人或家庭的原因離開公司，也有人在新成立的產品線 謀得職位，也有人被提升。但這一切都造成原來位置上的熟手損失殆盡，尤其是測試相關人員的流動，曾是很大的隱患。在以往的研發模式中，測試被嚴格劃分為多 個層級，由不同的測試部門執行，彼此之間通過高階別工程師以及文件和流程體系來溝通，確保各個層級的測試得到執行。新的組織架構中，除了Scrum團隊 後，就是系統測試團隊，而Scrum團隊測試和系統測試之間的銜接則出現了灰色地帶，原因就是彼此對對方的職責各有不同假設，卻未能發現及解決。

　　當時擁護及反對“敏捷”的各有人在。很有意思的是，在內部論壇上，我們屬於敏捷的堅定支持者，又喜歡說話或者說辯論，所以可謂是當時論壇裡的焦 點，矛頭所向。和大家進行了很多很多的辯論，當然多數都是無疾而終。我認為這些討論，以及發生在工作場合裡的許多討論，同事間私下的交流都非常好，在變革 之際，能夠幫助大家去理解這場變革（就算是純粹的抱怨也並非一無是處）。

　　組織變革的關鍵還是在於充分溝通，以及切實執行。有不同的聲音不要緊，關鍵是要去澄清和解決他們的疑問，因為沒有大家的理解和認同，變革也很難取得實際的效果。

　　浪費

　　加班加點趕進度的情形相信大家並不少見，但如果這麼辛苦做出來的東西並沒有真正地或是及時地派上用場，恐怕就更加可惜了。該平臺部門曾經很辛苦 地去兌現某一個重要釋出的最後期限，而根據客戶提交的缺陷報告來看，其中有一些功能客戶並沒有在拿到這個重要釋出後就去使用，而是在拿到後續的釋出後才有 使用到這些特定的功能。

　　該平臺部門並非是直接面向終端客戶，還需要結合上層的網元應用才能真正地產生效果。常規的模式都是網元有一系列客戶需求（具有非常大的粒度）中 分割出對系統平臺的需求後，傳遞到平臺部門的專案進行管理。出現過的情形是，平臺部門趕出來遞交的功能特性，由於網元應用沒能及時開發出來，而無法遞交給 客戶使用。

　　對此，大家有很多疑惑，我們是否在做該做的事情（功能特性），其中到底有多少浪費。Scrum的主張就是對使用者需求進行優先順序排序，但其中有一 些關鍵的點必須要重視，否則很容易流於形式而無法從中獲益，第一，要將需求分割到合適的細粒度，團隊才有可能持續地遞交高優先順序的功能特性，需求粒度不夠 小，假設Product Backlog裡就只有一個條目，那麼不管是PO還是銷售還是客戶都沒有辦法取捨；第二，要逐漸達到以真正端到端級別的需求為單位進行開發、管理；第三， 開發團隊和PO（能夠和終端客戶、使用者交流更好）之間有頻繁地交流、功能成品展示，從而可以利用反饋來改進、提高後續功能的開發。

　　區域性優化

　　有話說“不怕神一樣的敵人，就怕豬一樣的隊友”，其實做軟體也是，怕的就是勁不往一處使。但說回來還真不是大家不努力，而是對這個“一處”的看 法各有不同。關注於各自目標的達成，並不能保證這些努力疊加起來能夠實現那個 “共同的”目標，對區域性進行的優化可能會反過來扯集體的後腿。這樣的現象，組織各個層面都有。團隊內、團隊之間、產品線之間，都存在著這樣的情況。

　　例如團隊內部，由於不習慣轉型過程中新的特性團隊的工作方式，團隊內部也還是頗有些涇渭分明的開發、測試各一撥人，自個選自個的工作，迭代開始 的時候，各自就把自己的任務選走，然後整個迭代就盯著自己的一畝三分地拼命幹。但問題是，團隊需要負責、承諾的是最終可以運作的軟體增量，而這樣的模式無 法保證迭代結束時的交付。

　　團隊之間也是如此，為了讓自己的團隊工作預期更穩定、工作中能更專心，團隊也都要求確定他們的工作領域，迭代中則有些簡單粗暴的拒絕許多協助進行缺陷分析的請求。結果就是導致缺陷分析、修復的工作變得非常難以開展，而且有很多尚未查明的潛在缺陷被放棄追蹤和申報。

　　更大範圍內來看，我們完成了傳輸平臺的開發還不夠，要能夠產生客戶價值，還少不了上層的應用軟體系統。但我們的系統工程師團隊、Scrum團 隊、系統領域測試團隊等，以及上層的開發團隊、功能測試團隊、版本測試團隊、系統測試團隊等一干團隊，儘管都在努力改進自己的工作績效，可問題是，這些局 部的、片面的優化，在組織層面觀察，對終端客戶產生的影響微乎其微，甚至是副作用。

　　敏捷、精益的要點正在於此 —— 關注於產生的價值，移除不必要的浪費。不恰當的區域性優化也是一種浪費，我們要具備系統思考的能力，從整體上看問題，然後改進績效。組建特性團隊就是開始。

　　軟體質量

　　軟體質量是很多組織都有的一些共性問題，任何變化都意味著質量降低然後恢復到當初，然後再變得比以前好的迴圈，在我們組織中還是不可避免經歷這樣的迴圈。

　　在敏捷的轉型中，如果沒有很好的考慮這些質量的風險，那麼最終它所帶給組織的將是未來很長一段時間的“痛”，揹負的“債”需要很大的代價來償還，所導致的結果將對客戶的滿意度和信任都會產生很大的影響。

　　質量問題中，通常我們認為會有三種型別的問題：老程式碼的問題，新功能開發的問題和改問題引入的新問題

　　老程式碼的遺留質量問題所佔的比重通常是比較大。龐大的系統，任何的改動都有可能影響老程式碼的問題，或者老程式碼不能滿足當前的需求所需要做的調整，往往是這些改動或者新需求會影響那些地方通常是比較難界定出來，對於老程式碼的測試自動化保護是關鍵。

　　新功能開發所帶來的問題通常會由於對於進度壓力的妥協，在匆忙完成當前迭代週期的內容或者需要延遲當前迭代週期去做更多的測試之間矛盾。敏捷的開發模式使得原先長週期的專案進度和專案質量矛盾會在更短的週期裡（4周）顯現出來。

　　在敏捷實踐中，最大的一個優勢就在於快速的質量反饋。由於持續整合，持續迴歸測試，質量的反饋就會在2~3天甚至3~4小時之內反饋到程式碼提交的軟體人員。

　　當然這樣的快速反饋是基於持續整合所達到的層次，最完美的情況肯定是整個產品所有的測試都被放入到持續整合，那麼對於整體軟體將會有一個非常全面的質量考量。

　　自動化測試

　　測試自動化被許多人看做是敏捷的基石之一，眾多的敏捷實踐依賴於自動化的程度，例如持續整合。而能夠實現增量式開發也需要能夠快速、全面地進行 迴歸測試，確認已存在的功能特性沒有受到新特性開發的影響。在大張旗鼓地進行敏捷轉變之前，我們的產品線就已經開始嘗試過測試自動化。一個專門的測試自動 化小組在半年多時間內，操作芬蘭專家開發的自動化測試工具，將那些執行頻率很高的迴歸測試用例集實現自動化執行。基於由此專案得來的成功經驗，測試自動化 的概念被廣為傳播，而且這個實踐也開始作為一個基本要求附加給測試團隊，自動化測試用例佔所有測試用例的比例作為一個指標被上層主管密切關注。

　　開始進行敏捷轉變時，圍繞著測試自動化有很多的爭論，主要的焦點在於是否要追求100%的測試自動化。反對方和支援方都各有理由，難分高下，不 同理念都有追隨者在實踐。支持者認為自動化測試可以節省執行時間，而且可以在夜間及週末進行測試執行。反對者認為實現自動化用例耗用了測試人員的絕大部分 時間，來自於基層的部分意見反映他們都沒有時間去真正的測試系統，而且還有一些用例非常難實現自動化，或者說成本非常高。而最新的一個情況是，在一個新的 版本釋出計劃中，測試自動化的開銷總計以萬小時計算，那麼是否有必要一定要實現100%測試自動化？

　　我個人認為，其中很重要的一點就是測試自動化以及其比例被作為硬性指標施壓給團隊，導致團隊無暇顧及測試自動化的質量高低。而測試自動化的質量 恰恰會影響到：執行時間的長短、維護自動化指令碼的開銷、實現測試目的的準確性等。另一個原因就是，瞭解、專長於測試自動化，具備大範圍應用測試自動化經驗 的專家太少，還常常疲於應付實現具體的測試自動化用例，無暇去傳授、輔導及培養其他同事的測試自動化技能。

　　流程

　　敏捷的轉型過程中，如果認為流程可以被拋棄，可以按照自己的想法去做開發測試，這樣的觀念將是很大的一個誤區。

　　流程之所以為流程是因為它所承載的是一個組織長時間積累的經驗與教訓，它被實踐所證明有效的方式，怎樣使做某件事情的效果與效率達到最優，並在多年的實踐中被不斷的補充。

　　比如同行評審，我們的誤區在於認為人們會自動自發的組織好同行評審，可以使用開發組所自己的方式。老的同行評審的傳統並沒有很好的沿襲，特別在組織大規模擴招的時候。導致的結果是我們的需求，設計程式碼的問題比以往任何時候都要多。

　　比如測試，組織大規模的調整，但是相對應的測試在新組織裡的怎樣的計劃，新開發組裡測試以怎樣的方式進行，怎樣是最有效率的進行測試，開發組的 測試和外部測試之間的區別和協調，測試在端到端的整個開發過程中的佈局與充分性。我們的誤區是對這些問題在相當長的時間以後才逐漸意識到這方面的缺乏，然 後逐漸提出改進。

====================================分割線================================

最新內容請見作者的GitHub頁：http://qaseven.github.io/