我們倆來(lái)自于諾基亞西門(mén)子網(wǎng)絡(luò )杭州3G研發(fā)中心，本文內容來(lái)源于諾西一個(gè)通信產(chǎn)品研發(fā)部門(mén)所進(jìn)行的敏捷轉變，它是典型的多站點(diǎn)開(kāi)發(fā)的研發(fā)組織，在芬蘭、印度、中國等國家都有研發(fā)團隊，總計超過(guò)600人。我們免去在文中冗述各種功績(jì)和所得，只在這里和大家分享我們所經(jīng)歷的那些誤區、陷阱，當然還有那些應對的措施。
本文僅代表徐毅和王獻的看法，如此大的組織轉變，我們作為不到1%的人口代表，看到的、經(jīng)歷的難免會(huì )有誤差，恐怕不能概括事件的全貌，如有出入，請見(jiàn)諒。我們認為經(jīng)歷的誤區和陷阱大致可以分成如下七個(gè)方面：特性團隊、人、浪費、局部?jì)?yōu)化、軟件質(zhì)量、測試自動(dòng)化、流程。
特性團隊(Feature Team)
在組織中想要達到真正的Feature Team是一個(gè)很漫長(cháng)的過(guò)程，當在組織中實(shí)現局部的端到端的組的時(shí)候，更大的端到端的組的演變要求就會(huì )出現，因為這時(shí)組織中新的瓶頸會(huì )展現出來(lái)，這也是為什么敏捷雖不能解決問(wèn)題，但卻使問(wèn)題更顯現地表現出來(lái)的原因之一。
在組織的轉型中，產(chǎn)品有非常龐大的老代碼：
1. 通常早期的Feature Team所包括的功能性測試不完全，外部的測試對于這些Feature Team所起到的保護作用還是相當重要的;
隨著(zhù)時(shí)間的推移，Feature Team對于自己feature自動(dòng)化測試加強以及測試能力的提高，發(fā)布給外部的產(chǎn)品質(zhì)量會(huì )大大提高;
2. 對于外部其他組的依賴(lài)接口會(huì )很多，特別是組在不同國家的時(shí)候，溝通、交接和等待的浪費會(huì )很大;
3. 當產(chǎn)品中開(kāi)發(fā)部門(mén)和開(kāi)發(fā)部門(mén)的依賴(lài)減少后，開(kāi)發(fā)和測試的瓶頸會(huì )更突出;
4. 當產(chǎn)品中各個(gè)功能部門(mén)的依賴(lài)減少的時(shí)候，產(chǎn)品和產(chǎn)品間的瓶頸會(huì )凸顯。
想象一下從客戶(hù)提需求到最終提交功能需要經(jīng)過(guò)多少個(gè)過(guò)程，特別是大型組織中的產(chǎn)品，端到端意味著(zhù)幾十個(gè)過(guò)程甚至更多，Feature Team中能容納多少個(gè)這樣的過(guò)程就意味著(zhù)這個(gè)Feature Team的靈活度有多高，本質(zhì)上敏捷就是為了減少相互的依賴(lài)、等待和傳遞所帶來(lái)的消耗。
一個(gè)組織是一個(gè)龐大的系統，Feature Team的轉變過(guò)程意味著(zhù)減少整個(gè)系統中的Limitation。
在向Feature Team演變的過(guò)程，在相對比較短的時(shí)間把原先十幾或者幾十Component Team打破組成新的Feature Team，這中間的風(fēng)險在于：
1. 組的成熟度：成熟度需要時(shí)間，也需要一些錯誤的代價(jià);
2. 組的長(cháng)期成長(cháng)和短期項目計劃：由于為了項目的進(jìn)度而把對某領(lǐng)域很熟悉的組移出去做不熟悉的領(lǐng)域;
3. 組織的產(chǎn)出效率：怎樣合理的利用現有的有經(jīng)驗人員和新人，建立新結構所需要的基礎會(huì )使組織整體的產(chǎn)出效率減低;
4. 不可控和無(wú)序：怎樣讓這些組高質(zhì)量的發(fā)布產(chǎn)品在轉變過(guò)程變的不可控。
理想和現實(shí)中的平衡是Feature Team所面對一個(gè)問(wèn)題，劇烈的變動(dòng)意味著(zhù)劇烈的陣痛。
人
我們的轉變是基于Scrum+XP的方式，轉變的影響巨大，之前存在的許多職位、頭銜都會(huì )面臨變化甚至消失的可能。例如將不再會(huì )有項目經(jīng)理來(lái)集中處理項目管理的工作，對于產(chǎn)品需求研發(fā)順序的管理也由以往的項目經(jīng)理手中轉為產(chǎn)品負責人來(lái)負責。就算是最基層的開(kāi)發(fā)人員和測試人員，他們的日常工作方式以及職責范圍也面臨著(zhù)極大變化。這也意味著(zhù)轉變可能會(huì )遇到非常大的阻力，人天性會(huì )抗拒未知的變化。
某平臺部門(mén)的轉變尤其特殊，研發(fā)的老大意志堅定，在初期Pilot成功后，就大刀闊斧地進(jìn)行組織架構改革，仿佛一夜之間所有的項目經(jīng)理全部消失。而以往圍繞功能模塊所組建的分散的測試團隊以及開(kāi)發(fā)團隊也被重組，每一個(gè)Scrum團隊都擁有好幾名來(lái)自不同功能模塊領(lǐng)域的開(kāi)發(fā)和測試人員，從某種角度來(lái)看，這是我們所倡導的跨功能特性團隊的雛形。
各種形式的人員流失造成很大的困難，有人因為個(gè)人或家庭的原因離開(kāi)公司，也有人在新成立的產(chǎn)品線(xiàn)謀得職位，也有人被提升。但這一切都造成原來(lái)位置上的熟手損失殆盡，尤其是測試相關(guān)人員的流動(dòng)，曾是很大的隱患。在以往的研發(fā)模式中，測試被嚴格劃分為多個(gè)層級，由不同的測試部門(mén)執行，彼此之間通過(guò)高級別工程師以及文檔和流程體系來(lái)溝通，確保各個(gè)層級的測試得到執行。新的組織架構中，除了Scrum團隊后，就是系統測試團隊，而Scrum團隊測試和系統測試之間的銜接則出現了灰色地帶，原因就是彼此對對方的職責各有不同假設，卻未能發(fā)現及解決。
當時(shí)擁護及反對“敏捷”的各有人在。很有意思的是，在內部論壇上，我們屬于敏捷的堅定支持者，又喜歡說(shuō)話(huà)或者說(shuō)辯論，所以可謂是當時(shí)論壇里的焦點(diǎn)，矛頭所向。和大家進(jìn)行了很多很多的辯論，當然多數都是無(wú)疾而終。我認為這些討論，以及發(fā)生在工作場(chǎng)合里的許多討論，同事間私下的交流都非常好，在變革之際，能夠幫助大家去理解這場(chǎng)變革(就算是純粹的抱怨也并非一無(wú)是處)。
組織變革的關(guān)鍵還是在于充分溝通，以及切實(shí)執行。有不同的聲音不要緊，關(guān)鍵是要去澄清和解決他們的疑問(wèn)，因為沒(méi)有大家的理解和認同，變革也很難取得實(shí)際的效果。
浪費
加班加點(diǎn)趕進(jìn)度的情形相信大家并不少見(jiàn)，但如果這么辛苦做出來(lái)的東西并沒(méi)有真正地或是及時(shí)地派上用場(chǎng)，恐怕就更加可惜了。該平臺部門(mén)曾經(jīng)很辛苦地去兌現某一個(gè)重要發(fā)布的最后期限，而根據客戶(hù)提交的缺陷報告來(lái)看，其中有一些功能客戶(hù)并沒(méi)有在拿到這個(gè)重要發(fā)布后就去使用，而是在拿到后續的發(fā)布后才有使用到這些特定的功能。
該平臺部門(mén)并非是直接面向終端客戶(hù)，還需要結合上層的網(wǎng)元應用才能真正地產(chǎn)生效果。常規的模式都是網(wǎng)元有一系列客戶(hù)需求(具有非常大的粒度)中分割出對系統平臺的需求后，傳遞到平臺部門(mén)的項目進(jìn)行管理。出現過(guò)的情形是，平臺部門(mén)趕出來(lái)遞交的功能特性，由于網(wǎng)元應用沒(méi)能及時(shí)開(kāi)發(fā)出來(lái)，而無(wú)法遞交給客戶(hù)使用。
對此，大家有很多疑惑，我們是否在做該做的事情(功能特性)，其中到底有多少浪費。Scrum的主張就是對用戶(hù)需求進(jìn)行優(yōu)先級排序，但其中有一些關(guān)鍵的點(diǎn)必須要重視，否則很容易流于形式而無(wú)法從中獲益，第一，要將需求分割到合適的細粒度，團隊才有可能持續地遞交高優(yōu)先級的功能特性，需求粒度不夠小，假設Product Backlog里就只有一個(gè)條目，那么不管是PO還是銷(xiāo)售還是客戶(hù)都沒(méi)有辦法取舍;第二，要逐漸達到以真正端到端級別的需求為單位進(jìn)行開(kāi)發(fā)、管理;第三，開(kāi)發(fā)團隊和PO(能夠和終端客戶(hù)、用戶(hù)交流更好)之間有頻繁地交流、功能成品展示，從而可以利用反饋來(lái)改進(jìn)、提高后續功能的開(kāi)發(fā)。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
