我們倆來自于諾基亞西門子網絡杭州3G研發中心，本文內容來源于諾西一個通信產品研發部門所進行的敏捷轉變，它是典型的多站點開發的研發組織，在芬蘭、印度、中國等國家都有研發團隊，總計超過600人。我們免去在文中冗述各種功績和所得，只在這里和大家分享我們所經歷的那些誤區、陷阱，當然還有那些應對的措施。
本文僅代表徐毅和王獻的看法，如此大的組織轉變，我們作為不到1%的人口代表，看到的、經歷的難免會有誤差，恐怕不能概括事件的全貌，如有出入，請見諒。我們認為經歷的誤區和陷阱大致可以分成如下七個方面：特性團隊、人、浪費、局部優化、軟件質量、測試自動化、流程。
特性團隊(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(能夠和終端客戶、用戶交流更好)之間有頻繁地交流、功能成品展示，從而可以利用反饋來改進、提高后續功能的開發。
文章來源于領測軟件測試網 http://www.k11sc111.com/
