南順網絡
敏捷轉型16個月，總結期間得與失
本文将總結在過去(qù)的(de)一(yī)段時間裏，我們在轉型過程中踩過的(de)坑，以作前車之鑒。也聊聊在轉型過程中，哪些優秀的(de)實踐可(kě)以嘗試，走上漸進變革的(de)道(dào)路。
到今天，我們已經在敏捷轉型的(de)路上已經磕磕碰碰的(de)走了16個月。從啓程時的(de)興奮到現在的(de)淡然，回想起來還是“圖樣圖森破”，原以為(wèi)把敏捷那一(yī)套運作模式拿過來，随着時間的(de)推移，一(yī)切就會好轉起來。然而，并沒有那麽簡單，受限于組織架構，僅僅是把敏捷那一(yī)套運作模式照搬過來我們就做(zuò)不到，更别說照搬過來後能不能适應我們的(de)産品研發了。
雖然，目前敏捷轉型和(hé)預期比起來進展不夠理(lǐ)想，但是在期間我們還是運作起來部分優秀的(de)實踐，提高(gāo)了産品研發效率。本文将總結在過去(qù)的(de)一(yī)段時間裏，我們在轉型過程中踩過的(de)坑，以作前車之鑒。也聊聊在轉型過程中，哪些優秀的(de)實踐可(kě)以嘗試，走上漸進變革的(de)道(dào)路。
1.敏捷初識，我們的(de)敏捷做(zuò)對了嗎
在接觸敏捷之處，大家對敏捷都是一(yī)知半解，更多的(de)停留在字面意思的(de)理(lǐ)解上：“敏捷就是快“。一(yī)旦有人覺得不快時，就會發出質疑，我們的(de)敏捷做(zuò)對了嗎？另外一(yī)方面，由于剛接觸敏捷，我們開始變得理(lǐ)論化，嚴格遵循敏捷定義的(de)方式方法，條條框框，帶着對敏捷的(de)敬畏，天真的(de)認為(wèi)敏捷規定的(de)都是好的(de)，敏捷之外的(de)方式方法都是不完美的(de)，有缺陷的(de)。對，這就是我在剛接觸敏捷時，最大的(de)兩個誤區。
1.1.目光不要隻關注敏捷的(de)快
快，僅僅是敏捷帶來的(de)一(yī)個結果而已。單純的(de)隻關注這個結果，并不能對我們的(de)轉型帶來什麽幫助。關于快的(de)定義，我們習慣性的(de)參考别人做(zuò)産品是什麽樣的(de)節奏，找到業界的(de)優秀企業作對比，認為(wèi)做(zuò)到那樣才是快。然而，我們卻很少去(qù)關注對應産品的(de)品類和(hé)複雜度，忽略他們的(de)組織文化、組織架構、人員素質、開發過程中的(de)取舍等各種細節。看到别人家的(de)孩子(zǐ)全是優點，自(zì)家的(de)孩子(zǐ)一(yī)堆問題，卻不去(qù)了解别人是如(rú)何解決那些問題的(de)，付出了什麽代價，隻想取别人的(de)優點，忽略别人的(de)缺點。
欲思其利，必慮其害，欲思其成，必慮其敗。–《便宜十六策·思慮》
我們在做(zuò)敏捷轉型時，引入了外部咨詢培訓，培訓過程中老師舉了一(yī)個例子(zǐ)：“他們以前做(zuò)産品時，一(yī)天可(kě)以發20幾個版本。”，這樣的(de)例子(zǐ)對于我們來說簡直是太刺激了，我們的(de)産品要一(yī)個多月才能發出去(qù)一(yī)個版本。雖然我們知道(dào)老師舉例的(de)産品是web端産品與我們的(de)産品完全不一(yī)樣，我們還是不由自(zì)主的(de)認為(wèi)我們是不是可(kě)以做(zuò)到1周發一(yī)個版本，甚至更快，畢竟别人一(yī)天20多個版本啊。對，我們的(de)目光完全被“快”吸引了，于是什麽都圍繞怎麽能更快去(qù)開展改革，想方設法的(de)充分利用資源，各種并行，反而導緻混亂。
1.2.不忘初心，實事求是
我們是一(yī)家銷售消費類硬件産品為(wèi)主的(de)公司，在引入敏捷之前，我們采用的(de)瀑布開發模式，在産品複雜度低(dī)，研發人員較少的(de)情況下，運作還比較良好。但是，随着産品複雜度的(de)增加，研發人員增多，人員依賴度的(de)增加，這樣的(de)研發模式變得十分笨重，連一(yī)個基本的(de)信息傳遞都出了問題，集成一(yī)個版本變得十分困難，發布日期也總是一(yī)拖再拖。從結果上看就是我們不能按時發布，發布的(de)周期比較長(cháng)，産品研發變得“不敏捷”。然而要實際落地(dì)解決問題我們需要在這幾方面改善：
建立新的(de)溝通機制，保障跨領域協作的(de)有效溝通。需求要進行有效的(de)優先級排序，并控制數量，并承諾對應優先級需求的(de)交付率。避免建立過大的(de)團隊組織，如(rú)果存在，需要根據業務的(de)獨立性，拆解為(wèi)适當規模的(de)小團隊。團隊之間人員要解耦，盡量避免一(yī)個人在多個項目團隊。信息透明，盡量讓團隊成員能基于已有的(de)信息自(zì)己做(zuò)出決策，而不是詢問上級。建立跨領域團隊，并對團隊進行敏捷開發知識的(de)宣導和(hé)指導。引入持續集成。限制在制品，避免一(yī)個人同時開展多項工作，原則上不能超過2個未完成的(de)任務。
等等……
我們不再糾結于是否一(yī)定執行了敏捷裏面規定的(de)活動，又或者說我們現在的(de)項目過程，也談不上是完整意義的(de)敏捷開發，我們更注重什麽樣的(de)招式能有效解決我們當下的(de)問題。
1.3.我們的(de)絆腳石
本文開篇講到了組織架構導緻我們并不能完整的(de)引入敏捷開發的(de)各項機制。我相信，做(zuò)過敏捷轉型的(de)人應該都遇到了這樣的(de)問題。以下是我們在敏捷轉型中遇到的(de)一(yī)些實際問題，當你遇到這些問題時，不要驚訝，對于一(yī)個傳統的(de)成熟組織來說很難改變，尤其在沒有上層領導積極推動的(de)情況下。
沒有産品經理(lǐ)，敏捷團隊隻關注開發與發布，不管開始，不管結果。
在我們公司的(de)組織架構采用了弱矩陣形式，敏捷團隊更多的(de)起到協作開發前端需求的(de)作用，他們不需要對産品直接負責，也不會關注産品在市場上的(de)反饋。
測試與開發職責界限清晰。
在理(lǐ)想的(de)敏捷中，在開發過程中就開始做(zuò)測試，而我們還是需要開發完成後再進入測試，走上了“小瀑布模式”之路。
無法進行短(duǎn)周期叠代，放棄叠代。
由于走上了“小瀑布模式”之路，根本沒辦法做(zuò)到較短(duǎn)周期的(de)叠代，對于一(yī)個月一(yī)個版本來說，超過2周的(de)叠代周期已經失去(qù)了實際的(de)意義。
做(zuò)好的(de)功能都會發出去(qù)，基本沒有功能灰度驗證，功能越堆越多，維護越來越難。
需求人員都會認為(wèi)自(zì)己想法是完美的(de)，能有效提高(gāo)産品的(de)價值，他們更關注自(zì)己提的(de)需求，而不是這個産品。
沒有項目經理(lǐ)，隻有項目負責人，項目負責人不專注，不專業。
由于公司項目是弱矩陣形式，項目更多的(de)是協作作用，項目負責人更多的(de)是起到拉通團隊協作的(de)作用，由于項目負責人往往身兼多職，并不能有效的(de)持續投入精力優化項目過程。
等等……
2.成功的(de)每一(yī)小步
固然，我們在轉型中問題衆多，還有很大的(de)優化空間，但是和(hé)以前比起來我們還是取得了不小的(de)進步，以下招式在實際項目開展過程中具有明顯的(de)實際意義，并不受傳統組織架構排擠：
2.1.跨職能團隊
對于傳統企業來說，一(yī)般根據職能屬性進行部門劃分，各部門互相協作完成項目。然而，跨部門的(de)協作成本明顯過高(gāo)，當産品需要頻繁的(de)跨部門協作時，這樣的(de)模式明顯無法勝任。而在這時，公司必然也會暴露出由于這樣的(de)缺陷，導緻的(de)開發效率低(dī)下的(de)問題。此時，以事業部或核心部門主導，建立虛拟的(de)跨職能團隊，也就順理(lǐ)成章(zhāng)，一(yī)氣呵成。跨職能團隊能有效解決産品在開發時，頻繁協作溝通的(de)問題。在這樣的(de)團隊裏，溝通由實際的(de)開發、測試、需求人員直接當面溝通，頻率更高(gāo)，信息失真也比較少，也避免了部門之間扯皮的(de)問題。
2.2.每日晨會
晨會，是跨職能團隊進行溝通的(de)标準活動，每天在固定的(de)地(dì)點、固定時間花10分鍾左右舉行，是一(yī)種很有效的(de)團隊同步機制。然而晨會看上去(qù)簡單，但是要開好，卻沒有那麽容易。敏捷裏面的(de)推薦晨會內(nèi)容主要包括以下三方面。
昨天做(zuò)了什麽？今天要做(zuò)什麽？有什麽問題？
對于敏捷小白的(de)我們，剛開始照本宣科的(de)組織晨會，但是采用标準的(de)模式，我們卻始終都開不好這樣的(de)晨會，下面會詳細的(de)說說我們都遇到了哪些問題。
晨會溝通時，大部分信息對改善項目進展的(de)實際意思很小，口水話太多。當一(yī)位同事在描述自(zì)己昨天做(zuò)了什麽，今天要做(zuò)什麽時，大部分人并不在意。大部分工程師晨會都是自(zì)顧自(zì)說，不關心自(zì)己表達的(de)內(nèi)容是否有效傳遞。推廣晨會輪流組織時，發現大部分人并沒有這個能力有效的(de)組織晨會，并不太好實踐。晨會讨論的(de)內(nèi)容很離(lí)散，看不到整個項目的(de)進展。
2.2.1.怎麽開好晨會
正如(rú)敏捷宣言裏面提到的(de)“個體交互勝過流程和(hé)工具”一(yī)樣。晨會，需要将當前項目的(de)進展透明到整個團隊，并促使團隊成員基于各自(zì)目前的(de)情況，通過溝通及時主動的(de)解決問題。那如(rú)何才能做(zuò)到快速有效的(de)溝通呢(ne)，我認為(wèi)需要做(zuò)到以下幾點：
團隊成員都清晰的(de)知道(dào)項目的(de)目标和(hé)當前的(de)狀态。項目中的(de)各項工作內(nèi)容都有清晰的(de)優先級，以及明确的(de)責任人和(hé)當前的(de)進展信息。晨會有明确的(de)規則，每個人都知道(dào)在何時做(zuò)何事。參與晨會的(de)每一(yī)個人都能随着輕松的(de)了解到與他相關人員的(de)任務進展狀态。
要做(zuò)到這些，當然就少不了一(yī)面合理(lǐ)的(de)看闆牆了。它是整個晨會的(de)核心載體，晨會時，所有的(de)項目成員都基于看闆牆的(de)信息進行讨論并更新看闆牆的(de)信息。
2.3.看闆牆
看闆牆，看似隻是簡單的(de)将項目中要展示的(de)信息帖到一(yī)個版本上面去(qù)，但是如(rú)果貼得不合理(lǐ)，整個晨會就會一(yī)團亂麻，思路離(lí)散，最終導緻晨會的(de)失敗。接下來，我将談談我們看闆的(de)演進過程。
剛開始，我們采用上圖那樣的(de)看闆牆，紙片上僅僅寫了用戶故事，每天晨會的(de)時候，大家圍成一(yī)圈，按順序每個人講自(zì)己昨天做(zuò)了什麽，今天做(zuò)什麽，有什麽問題。當發現某項用戶故事改變了狀态時，就挪動到對應的(de)列裏面去(qù)。
漸漸的(de)問題就暴露出來，我們發現看闆牆上的(de)卡片會有很多，而且會越來越多，因為(wèi)我們總是想做(zuò)更多的(de)用戶故事，一(yī)旦某項用戶故事在開發過程中受阻，我們就會考慮開展一(yī)項新的(de)用戶故事，我們不能接受一(yī)個人“閑下來”。另外，由于每個人講的(de)內(nèi)容，并沒有和(hé)卡片直接關聯起來，導緻我們并不能很好的(de)把講的(de)信息和(hé)看闆牆結合起來，以至于看闆牆成了一(yī)個背景，沒有起到太多的(de)實際意義，我們開始質疑，輪流講問題是不是不合理(lǐ)，轉變為(wèi)由一(yī)個人主持，根據看闆牆上的(de)信息逐個詢問探讨，為(wèi)了實現輪流主持，我們定期換不同的(de)人進行詢問探讨。
編輯:--ns868
