我們倆來(lái)自于諾基亞西門子網(wǎng)絡(luò)杭州3G研發(fā)中心，本文內(nèi)容來(lái)源于諾西一個(gè)通信產(chǎn)品研發(fā)部門所進(jìn)行的敏捷轉(zhuǎn)變，它是典型的多站點(diǎn)開(kāi)發(fā)的研發(fā)組織，在芬蘭、印度、中國(guó)等國(guó)家都有研發(fā)團(tuán)隊(duì)，總計(jì)超過(guò)600人。我們免去在文中冗述各種功績(jī)和所得，只在這里和大家分享我們所經(jīng)歷的那些誤區(qū)、陷阱，當(dāng)然還有那些應(yīng)對(duì)的措施。

　　特性團(tuán)隊(duì)（Feature Team）

　　在組織中想要達(dá)到真正的Feature Team是一個(gè)很漫長(zhǎng)的過(guò)程，當(dāng)在組織中實(shí)現(xiàn)局部的端到端的組的時(shí)候，更大的端到端的組的演變要求就會(huì)出現(xiàn)，因?yàn)檫@時(shí)組織中新的瓶頸會(huì)展現(xiàn)出來(lái)，這也是為什么敏捷雖不能解決問(wèn)題，但卻使問(wèn)題更顯現(xiàn)地表現(xiàn)出來(lái)的原因之一。

　　在組織的轉(zhuǎn)型中，產(chǎn)品有非常龐大的老代碼：

　　1. 通常早期的Feature Team所包括的功能性測(cè)試不完全，外部的測(cè)試對(duì)于這些Feature Team所起到的保護(hù)作用還是相當(dāng)重要的；隨著時(shí)間的推移，F(xiàn)eature Team對(duì)于自己feature自動(dòng)化測(cè)試加強(qiáng)以及測(cè)試能力的提高，發(fā)布給外部的產(chǎn)品質(zhì)量會(huì)大大提高；

　　2. 對(duì)于外部其他組的依賴接口會(huì)很多，特別是組在不同國(guó)家的時(shí)候，溝通、交接和等待的浪費(fèi)會(huì)很大；

　　3. 當(dāng)產(chǎn)品中開(kāi)發(fā)部門和開(kāi)發(fā)部門的依賴減少后，開(kāi)發(fā)和測(cè)試的瓶頸會(huì)更突出；

　　4. 當(dāng)產(chǎn)品中各個(gè)功能部門的依賴減少的時(shí)候，產(chǎn)品和產(chǎn)品間的瓶頸會(huì)凸顯。

　　想象一下從客戶提需求到最終提交功能需要經(jīng)過(guò)多少個(gè)過(guò)程，特別是大型組織中的產(chǎn)品，端到端意味著幾十個(gè)過(guò)程甚至更多，F(xiàn)eature Team中能容納多少個(gè)這樣的過(guò)程就意味著這個(gè)Feature Team的靈活度有多高，本質(zhì)上敏捷就是為了減少相互的依賴、等待和傳遞所帶來(lái)的消耗。

　　一個(gè)組織是一個(gè)龐大的系統(tǒng)，F(xiàn)eature Team的轉(zhuǎn)變過(guò)程意味著減少整個(gè)系統(tǒng)中的Limitation。 在向Feature Team演變的過(guò)程，在相對(duì)比較短的時(shí)間把原先十幾或者幾十Component Team打破組成新的Feature Team，這中間的風(fēng)險(xiǎn)在于：

　　1. 組的成熟度：成熟度需要時(shí)間，也需要一些錯(cuò)誤的代價(jià)；

　　2. 組的長(zhǎng)期成長(zhǎng)和短期項(xiàng)目計(jì)劃：由于為了項(xiàng)目的進(jìn)度而把對(duì)某領(lǐng)域很熟悉的組移出去做不熟悉的領(lǐng)域；

　　3. 組織的產(chǎn)出效率：怎樣合理的利用現(xiàn)有的有經(jīng)驗(yàn)人員和新人，建立新結(jié)構(gòu)所需要的基礎(chǔ)會(huì)使組織整體的產(chǎn)出效率減低；

　　4. 不可控和無(wú)序：怎樣讓這些組高質(zhì)量的發(fā)布產(chǎn)品在轉(zhuǎn)變過(guò)程變的不可控。

　　理想和現(xiàn)實(shí)中的平衡是Feature Team所面對(duì)一個(gè)問(wèn)題，劇烈的變動(dòng)意味著劇烈的陣痛。

　　人

　　我們的轉(zhuǎn)變是基于Scrum+XP的方式，轉(zhuǎn)變的影響巨大，之前存在的許多職位、頭銜都會(huì)面臨變化甚至消失的可能。例如將不再會(huì)有項(xiàng)目經(jīng)理來(lái)集中處理項(xiàng)目管理的工作，對(duì)于產(chǎn)品需求研發(fā)順序的管理也由以往的項(xiàng)目經(jīng)理手中轉(zhuǎn)為產(chǎn)品負(fù)責(zé)人來(lái)負(fù)責(zé)。就算是最基層的開(kāi)發(fā)人員和測(cè)試人員，他們的日常工作方式以及職責(zé)范圍也面臨著極大變化。這也意味著轉(zhuǎn)變可能會(huì)遇到非常大的阻力，人天性會(huì)抗拒未知的變化。

　　某平臺(tái)部門的轉(zhuǎn)變尤其特殊，研發(fā)的老大意志堅(jiān)定，在初期Pilot成功后，就大刀闊斧地進(jìn)行組織架構(gòu)改革，仿佛一夜之間所有的項(xiàng)目經(jīng)理全部消失。而以往圍繞功能模塊所組建的分散的測(cè)試團(tuán)隊(duì)以及開(kāi)發(fā)團(tuán)隊(duì)也被重組，每一個(gè)Scrum團(tuán)隊(duì)都擁有好幾名來(lái)自不同功能模塊領(lǐng)域的開(kāi)發(fā)和測(cè)試人員，從某種角度來(lái)看，這是我們所倡導(dǎo)的跨功能特性團(tuán)隊(duì)的雛形。

　　各種形式的人員流失造成很大的困難，有人因?yàn)閭€(gè)人或家庭的原因離開(kāi)公司，也有人在新成立的產(chǎn)品線謀得職位，也有人被提升。但這一切都造成原來(lái)位置上的熟手損失殆盡，尤其是測(cè)試相關(guān)人員的流動(dòng)，曾是很大的隱患。在以往的研發(fā)模式中，測(cè)試被嚴(yán)格劃分為多個(gè)層級(jí)，由不同的測(cè)試部門執(zhí)行，彼此之間通過(guò)高級(jí)別工程師以及文檔和流程體系來(lái)溝通，確保各個(gè)層級(jí)的測(cè)試得到執(zhí)行。新的組織架構(gòu)中，除了Scrum團(tuán)隊(duì)后，就是系統(tǒng)測(cè)試團(tuán)隊(duì)，而Scrum團(tuán)隊(duì)測(cè)試和系統(tǒng)測(cè)試之間的銜接則出現(xiàn)了灰色地帶，原因就是彼此對(duì)對(duì)方的職責(zé)各有不同假設(shè)，卻未能發(fā)現(xiàn)及解決。

　　當(dāng)時(shí)擁護(hù)及反對(duì)“敏捷”的各有人在。很有意思的是，在內(nèi)部論壇上，我們屬于敏捷的堅(jiān)定支持者，又喜歡說(shuō)話或者說(shuō)辯論，所以可謂是當(dāng)時(shí)論壇里的焦點(diǎn)，矛頭所向。和大家進(jìn)行了很多很多的辯論，當(dāng)然多數(shù)都是無(wú)疾而終。我認(rèn)為這些討論，以及發(fā)生在工作場(chǎng)合里的許多討論，同事間私下的交流都非常好，在變革之際，能夠幫助大家去理解這場(chǎng)變革（就算是純粹的抱怨也并非一無(wú)是處）。

　　組織變革的關(guān)鍵還是在于充分溝通，以及切實(shí)執(zhí)行。有不同的聲音不要緊，關(guān)鍵是要去澄清和解決他們的疑問(wèn)，因?yàn)闆](méi)有大家的理解和認(rèn)同，變革也很難取得實(shí)際的效果。

　　浪費(fèi)

　　加班加點(diǎn)趕進(jìn)度的情形相信大家并不少見(jiàn)，但如果這么辛苦做出來(lái)的東西并沒(méi)有真正地或是及時(shí)地派上用場(chǎng)，恐怕就更加可惜了。該平臺(tái)部門曾經(jīng)很辛苦地去兌現(xiàn)某一個(gè)重要發(fā)布的最后期限，而根據(jù)客戶提交的缺陷報(bào)告來(lái)看，其中有一些功能客戶并沒(méi)有在拿到這個(gè)重要發(fā)布后就去使用，而是在拿到后續(xù)的發(fā)布后才有使用到這些特定的功能。

　　該平臺(tái)部門并非是直接面向終端客戶，還需要結(jié)合上層的網(wǎng)元應(yīng)用才能真正地產(chǎn)生效果。常規(guī)的模式都是網(wǎng)元有一系列客戶需求（具有非常大的粒度）中分割出對(duì)系統(tǒng)平臺(tái)的需求后，傳遞到平臺(tái)部門的項(xiàng)目進(jìn)行管理。出現(xiàn)過(guò)的情形是，平臺(tái)部門趕出來(lái)遞交的功能特性，由于網(wǎng)元應(yīng)用沒(méi)能及時(shí)開(kāi)發(fā)出來(lái)，而無(wú)法遞交給客戶使用。

　　對(duì)此，大家有很多疑惑，我們是否在做該做的事情（功能特性），其中到底有多少浪費(fèi)。Scrum的主張就是對(duì)用戶需求進(jìn)行優(yōu)先級(jí)排序，但其中有一些關(guān)鍵的點(diǎn)必須要重視，否則很容易流于形式而無(wú)法從中獲益，第一，要將需求分割到合適的細(xì)粒度，團(tuán)隊(duì)才有可能持續(xù)地遞交高優(yōu)先級(jí)的功能特性，需求粒度不夠小，假設(shè)Product Backlog里就只有一個(gè)條目，那么不管是PO還是銷售還是客戶都沒(méi)有辦法取舍；第二，要逐漸達(dá)到以真正端到端級(jí)別的需求為單位進(jìn)行開(kāi)發(fā)、管理；第三，開(kāi)發(fā)團(tuán)隊(duì)和PO（能夠和終端客戶、用戶交流更好）之間有頻繁地交流、功能成品展示，從而可以利用反饋來(lái)改進(jìn)、提高后續(xù)功能的開(kāi)發(fā)。

　　局部?jī)?yōu)化

　　有話說(shuō)“不怕神一樣的敵人，就怕豬一樣的隊(duì)友”，其實(shí)做軟件也是，怕的就是勁不往一處使。但說(shuō)回來(lái)還真不是大家不努力，而是對(duì)這個(gè)“一處”的看法各有不同。關(guān)注于各自目標(biāo)的達(dá)成，并不能保證這些努力疊加起來(lái)能夠?qū)崿F(xiàn)那個(gè) “共同的”目標(biāo)，對(duì)局部進(jìn)行的優(yōu)化可能會(huì)反過(guò)來(lái)扯集體的后腿。這樣的現(xiàn)象，組織各個(gè)層面都有。團(tuán)隊(duì)內(nèi)、團(tuán)隊(duì)之間、產(chǎn)品線之間，都存在著這樣的情況。

　　例如團(tuán)隊(duì)內(nèi)部，由于不習(xí)慣轉(zhuǎn)型過(guò)程中新的特性團(tuán)隊(duì)的工作方式，團(tuán)隊(duì)內(nèi)部也還是頗有些涇渭分明的開(kāi)發(fā)、測(cè)試各一撥人，自個(gè)選自個(gè)的工作，迭代開(kāi)始的時(shí)候，各自就把自己的任務(wù)選走，然后整個(gè)迭代就盯著自己的一畝三分地拼命干。但問(wèn)題是，團(tuán)隊(duì)需要負(fù)責(zé)、承諾的是最終可以運(yùn)作的軟件增量，而這樣的模式無(wú)法保證迭代結(jié)束時(shí)的交付。

　　團(tuán)隊(duì)之間也是如此，為了讓自己的團(tuán)隊(duì)工作預(yù)期更穩(wěn)定、工作中能更專心，團(tuán)隊(duì)也都要求確定他們的工作領(lǐng)域，迭代中則有些簡(jiǎn)單粗暴的拒絕許多協(xié)助進(jìn)行缺陷分析的請(qǐng)求。結(jié)果就是導(dǎo)致缺陷分析、修復(fù)的工作變得非常難以開(kāi)展，而且有很多尚未查明的潛在缺陷被放棄追蹤和申報(bào)。

　　更大范圍內(nèi)來(lái)看，我們完成了傳輸平臺(tái)的開(kāi)發(fā)還不夠，要能夠產(chǎn)生客戶價(jià)值，還少不了上層的應(yīng)用軟件系統(tǒng)。但我們的系統(tǒng)工程師團(tuán)隊(duì)、Scrum團(tuán)隊(duì)、系統(tǒng)領(lǐng)域測(cè)試團(tuán)隊(duì)等，以及上層的開(kāi)發(fā)團(tuán)隊(duì)、功能測(cè)試團(tuán)隊(duì)、版本測(cè)試團(tuán)隊(duì)、系統(tǒng)測(cè)試團(tuán)隊(duì)等一干團(tuán)隊(duì)，盡管都在努力改進(jìn)自己的工作績(jī)效，可問(wèn)題是，這些局部的、片面的優(yōu)化，在組織層面觀察，對(duì)終端客戶產(chǎn)生的影響微乎其微，甚至是副作用。

　　敏捷、精益的要點(diǎn)正在于此 —— 關(guān)注于產(chǎn)生的價(jià)值，移除不必要的浪費(fèi)。不恰當(dāng)?shù)木植績(jī)?yōu)化也是一種浪費(fèi)，我們要具備系統(tǒng)思考的能力，從整體上看問(wèn)題，然后改進(jìn)績(jī)效。組建特性團(tuán)隊(duì)就是開(kāi)始。

　　軟件質(zhì)量

　　軟件質(zhì)量是很多組織都有的一些共性問(wèn)題，任何變化都意味著質(zhì)量降低然后恢復(fù)到當(dāng)初，然后再變得比以前好的循環(huán)，在我們組織中還是不可避免經(jīng)歷這樣的循環(huán)。

　　在敏捷的轉(zhuǎn)型中，如果沒(méi)有很好的考慮這些質(zhì)量的風(fēng)險(xiǎn)，那么最終它所帶給組織的將是未來(lái)很長(zhǎng)一段時(shí)間的“痛”，背負(fù)的“債”需要很大的代價(jià)來(lái)償還，所導(dǎo)致的結(jié)果將對(duì)客戶的滿意度和信任都會(huì)產(chǎn)生很大的影響。

　　質(zhì)量問(wèn)題中，通常我們認(rèn)為會(huì)有三種類型的問(wèn)題：老代碼的問(wèn)題，新功能開(kāi)發(fā)的問(wèn)題和改問(wèn)題引入的新問(wèn)題

　　老代碼的遺留質(zhì)量問(wèn)題所占的比重通常是比較大。龐大的系統(tǒng)，任何的改動(dòng)都有可能影響老代碼的問(wèn)題，或者老代碼不能滿足當(dāng)前的需求所需要做的調(diào)整，往往是這些改動(dòng)或者新需求會(huì)影響那些地方通常是比較難界定出來(lái)，對(duì)于老代碼的測(cè)試自動(dòng)化保護(hù)是關(guān)鍵。

　　新功能開(kāi)發(fā)所帶來(lái)的問(wèn)題通常會(huì)由于對(duì)于進(jìn)度壓力的妥協(xié)，在匆忙完成當(dāng)前迭代周期的內(nèi)容或者需要延遲當(dāng)前迭代周期去做更多的測(cè)試之間矛盾。敏捷的開(kāi)發(fā)模式使得原先長(zhǎng)周期的項(xiàng)目進(jìn)度和項(xiàng)目質(zhì)量矛盾會(huì)在更短的周期里（4周）顯現(xiàn)出來(lái)。

　　在敏捷實(shí)踐中，最大的一個(gè)優(yōu)勢(shì)就在于快速的質(zhì)量反饋。由于持續(xù)集成，持續(xù)回歸測(cè)試，質(zhì)量的反饋就會(huì)在2~3天甚至3~4小時(shí)之內(nèi)反饋到代碼提交的軟件人員。

　　當(dāng)然這樣的快速反饋是基于持續(xù)集成所達(dá)到的層次，最完美的情況肯定是整個(gè)產(chǎn)品所有的測(cè)試都被放入到持續(xù)集成，那么對(duì)于整體軟件將會(huì)有一個(gè)非常全面的質(zhì)量考量。

　　自動(dòng)化測(cè)試

　　測(cè)試自動(dòng)化被許多人看做是敏捷的基石之一，眾多的敏捷實(shí)踐依賴于自動(dòng)化的程度，例如持續(xù)集成。而能夠?qū)崿F(xiàn)增量式開(kāi)發(fā)也需要能夠快速、全面地進(jìn)行回歸測(cè)試，確認(rèn)已存在的功能特性沒(méi)有受到新特性開(kāi)發(fā)的影響。在大張旗鼓地進(jìn)行敏捷轉(zhuǎn)變之前，我們的產(chǎn)品線就已經(jīng)開(kāi)始嘗試過(guò)測(cè)試自動(dòng)化。一個(gè)專門的測(cè)試自動(dòng)化小組在半年多時(shí)間內(nèi)，操作芬蘭專家開(kāi)發(fā)的自動(dòng)化測(cè)試工具，將那些執(zhí)行頻率很高的回歸測(cè)試用例集實(shí)現(xiàn)自動(dòng)化執(zhí)行。基于由此項(xiàng)目得來(lái)的成功經(jīng)驗(yàn)，測(cè)試自動(dòng)化的概念被廣為傳播，而且這個(gè)實(shí)踐也開(kāi)始作為一個(gè)基本要求附加給測(cè)試團(tuán)隊(duì)，自動(dòng)化測(cè)試用例占所有測(cè)試用例的比例作為一個(gè)指標(biāo)被上層主管密切關(guān)注。

　　開(kāi)始進(jìn)行敏捷轉(zhuǎn)變時(shí)，圍繞著測(cè)試自動(dòng)化有很多的爭(zhēng)論，主要的焦點(diǎn)在于是否要追求100%的測(cè)試自動(dòng)化。反對(duì)方和支持方都各有理由，難分高下，不同理念都有追隨者在實(shí)踐。支持者認(rèn)為自動(dòng)化測(cè)試可以節(jié)省執(zhí)行時(shí)間，而且可以在夜間及周末進(jìn)行測(cè)試執(zhí)行。反對(duì)者認(rèn)為實(shí)現(xiàn)自動(dòng)化用例耗用了測(cè)試人員的絕大部分時(shí)間，來(lái)自于基層的部分意見(jiàn)反映他們都沒(méi)有時(shí)間去真正的測(cè)試系統(tǒng)，而且還有一些用例非常難實(shí)現(xiàn)自動(dòng)化，或者說(shuō)成本非常高。而最新的一個(gè)情況是，在一個(gè)新的版本發(fā)布計(jì)劃中，測(cè)試自動(dòng)化的開(kāi)銷總計(jì)以萬(wàn)小時(shí)計(jì)算，那么是否有必要一定要實(shí)現(xiàn)100%測(cè)試自動(dòng)化？

　　我個(gè)人認(rèn)為，其中很重要的一點(diǎn)就是測(cè)試自動(dòng)化以及其比例被作為硬性指標(biāo)施壓給團(tuán)隊(duì)，導(dǎo)致團(tuán)隊(duì)無(wú)暇顧及測(cè)試自動(dòng)化的質(zhì)量高低。而測(cè)試自動(dòng)化的質(zhì)量恰恰會(huì)影響到：執(zhí)行時(shí)間的長(zhǎng)短、維護(hù)自動(dòng)化腳本的開(kāi)銷、實(shí)現(xiàn)測(cè)試目的的準(zhǔn)確性等。另一個(gè)原因就是，了解、專長(zhǎng)于測(cè)試自動(dòng)化，具備大范圍應(yīng)用測(cè)試自動(dòng)化經(jīng)驗(yàn)的專家太少，還常常疲于應(yīng)付實(shí)現(xiàn)具體的測(cè)試自動(dòng)化用例，無(wú)暇去傳授、輔導(dǎo)及培養(yǎng)其他同事的測(cè)試自動(dòng)化技能。

　　流程

　　敏捷的轉(zhuǎn)型過(guò)程中，如果認(rèn)為流程可以被拋棄，可以按照自己的想法去做開(kāi)發(fā)測(cè)試，這樣的觀念將是很大的一個(gè)誤區(qū)。

　　流程之所以為流程是因?yàn)樗休d的是一個(gè)組織長(zhǎng)時(shí)間積累的經(jīng)驗(yàn)與教訓(xùn)，它被實(shí)踐所證明有效的方式，怎樣使做某件事情的效果與效率達(dá)到最優(yōu)，并在多年的實(shí)踐中被不斷的補(bǔ)充。

　　比如同行評(píng)審，我們的誤區(qū)在于認(rèn)為人們會(huì)自動(dòng)自發(fā)的組織好同行評(píng)審，可以使用開(kāi)發(fā)組所自己的方式。老的同行評(píng)審的傳統(tǒng)并沒(méi)有很好的沿襲，特別在組織大規(guī)模擴(kuò)招的時(shí)候。導(dǎo)致的結(jié)果是我們的需求，設(shè)計(jì)代碼的問(wèn)題比以往任何時(shí)候都要多。

　　比如測(cè)試，組織大規(guī)模的調(diào)整，但是相對(duì)應(yīng)的測(cè)試在新組織里的怎樣的計(jì)劃，新開(kāi)發(fā)組里測(cè)試以怎樣的方式進(jìn)行，怎樣是最有效率的進(jìn)行測(cè)試，開(kāi)發(fā)組的測(cè)試和外部測(cè)試之間的區(qū)別和協(xié)調(diào)，測(cè)試在端到端的整個(gè)開(kāi)發(fā)過(guò)程中的布局與充分性。我們的誤區(qū)是對(duì)這些問(wèn)題在相當(dāng)長(zhǎng)的時(shí)間以后才逐漸意識(shí)到這方面的缺乏，然后逐漸提出改進(jìn)。

　　作者簡(jiǎn)介：
　　徐毅，諾基亞西門子網(wǎng)絡(luò)擔(dān)任精益及敏捷顧問(wèn)，專長(zhǎng)于大型組織（超過(guò)500人）的敏捷遷徙轉(zhuǎn)變。精通各種風(fēng)格、類型的黑盒測(cè)試，包括驗(yàn)收性測(cè)試驅(qū)動(dòng)開(kāi)發(fā)、探索性測(cè)試、測(cè)試自動(dòng)化等。
　　王獻(xiàn)，諾基亞西門子網(wǎng)絡(luò)擔(dān)任項(xiàng)目質(zhì)量經(jīng)理，主要職責(zé)是幫助開(kāi)發(fā)部門質(zhì)量和流程的改進(jìn)。工作經(jīng)驗(yàn)從測(cè)試工程師和測(cè)試質(zhì)量工程師，到度量組組長(zhǎng)，再到項(xiàng)目質(zhì)量經(jīng)理。經(jīng)歷過(guò)大型組織的整個(gè)轉(zhuǎn)型，對(duì)于敏捷，Scrum以及組織中的所有的流程有些個(gè)人的見(jiàn)解。

it知識(shí)庫(kù)：敏捷實(shí)踐的七個(gè)方面，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。