本文將總結(jié)在過去的一段時間里，我們在轉(zhuǎn)型過程中踩過的坑，以作前車之鑒。也聊聊在轉(zhuǎn)型過程中，哪些優(yōu)秀的實踐可以嘗試，走上漸進變革的道路。

到今天，我們已經(jīng)在敏捷轉(zhuǎn)型的路上已經(jīng)磕磕碰碰的走了16個月。從啟程時的興奮到現(xiàn)在的淡然，回想起來還是“圖樣圖森破”，原以為把敏捷那一套運作模式拿過來，隨著時間的推移，一切就會好轉(zhuǎn)起來。然而，并沒有那么簡單，受限于組織架構(gòu)，僅僅是把敏捷那一套運作模式照搬過來我們就做不到，更別說照搬過來后能不能適應我們的產(chǎn)品研發(fā)了。

雖然，目前敏捷轉(zhuǎn)型和預期比起來進展不夠理想，但是在期間我們還是運作起來部分優(yōu)秀的實踐，提高了產(chǎn)品研發(fā)效率。本文將總結(jié)在過去的一段時間里，我們在轉(zhuǎn)型過程中踩過的坑，以作前車之鑒。也聊聊在轉(zhuǎn)型過程中，哪些優(yōu)秀的實踐可以嘗試，走上漸進變革的道路。

1.敏捷初識，我們的敏捷做對了嗎

在接觸敏捷之處，大家對敏捷都是一知半解，更多的停留在字面意思的理解上：“敏捷就是快“。一旦有人覺得不快時，就會發(fā)出質(zhì)疑，我們的敏捷做對了嗎？另外一方面，由于剛接觸敏捷，我們開始變得理論化，嚴格遵循敏捷定義的方式方法，條條框框，帶著對敏捷的敬畏，天真的認為敏捷規(guī)定的都是好的，敏捷之外的方式方法都是不完美的，有缺陷的。對，這就是我在剛接觸敏捷時，最大的兩個誤區(qū)。

1.1.目光不要只關(guān)注敏捷的快

快，僅僅是敏捷帶來的一個結(jié)果而已。單純的只關(guān)注這個結(jié)果，并不能對我們的轉(zhuǎn)型帶來什么幫助。關(guān)于快的定義，我們習慣性的參考別人做產(chǎn)品是什么樣的節(jié)奏，找到業(yè)界的優(yōu)秀企業(yè)作對比，認為做到那樣才是快。然而，我們卻很少去關(guān)注對應產(chǎn)品的品類和復雜度，忽略他們的組織文化、組織架構(gòu)、人員素質(zhì)、開發(fā)過程中的取舍等各種細節(jié)?？吹絼e人家的孩子全是優(yōu)點，自家的孩子一堆問題，卻不去了解別人是如何解決那些問題的，付出了什么代價，只想取別人的優(yōu)點，忽略別人的缺點。

欲思其利，必慮其害，欲思其成，必慮其敗。–《便宜十六策·思慮》

我們在做敏捷轉(zhuǎn)型時，引入了外部咨詢培訓，培訓過程中老師舉了一個例子：“他們以前做產(chǎn)品時，一天可以發(fā)20幾個版本?！保@樣的例子對于我們來說簡直是太刺激了，我們的產(chǎn)品要一個多月才能發(fā)出去一個版本。雖然我們知道老師舉例的產(chǎn)品是web端產(chǎn)品與我們的產(chǎn)品完全不一樣，我們還是不由自主的認為我們是不是可以做到1周發(fā)一個版本，甚至更快，畢竟別人一天20多個版本啊。對，我們的目光完全被“快”吸引了，于是什么都圍繞怎么能更快去開展改革，想方設法的充分利用資源，各種并行，反而導致混亂。

1.2.不忘初心，實事求是

我們是一家銷售消費類硬件產(chǎn)品為主的公司，在引入敏捷之前，我們采用的瀑布開發(fā)模式，在產(chǎn)品復雜度低，研發(fā)人員較少的情況下，運作還比較良好。但是，隨著產(chǎn)品復雜度的增加，研發(fā)人員增多，人員依賴度的增加，這樣的研發(fā)模式變得十分笨重，連一個基本的信息傳遞都出了問題，集成一個版本變得十分困難，發(fā)布日期也總是一拖再拖。從結(jié)果上看就是我們不能按時發(fā)布，發(fā)布的周期比較長，產(chǎn)品研發(fā)變得“不敏捷”。然而要實際落地解決問題我們需要在這幾方面改善：

• 建立新的溝通機制，保障跨領域協(xié)作的有效溝通。
• 需求要進行有效的優(yōu)先級排序，并控制數(shù)量，并承諾對應優(yōu)先級需求的交付率。
• 避免建立過大的團隊組織，如果存在，需要根據(jù)業(yè)務的獨立性，拆解為適當規(guī)模的小團隊。
• 團隊之間人員要解耦，盡量避免一個人在多個項目團隊。
• 信息透明，盡量讓團隊成員能基于已有的信息自己做出決策，而不是詢問上級。
• 建立跨領域團隊，并對團隊進行敏捷開發(fā)知識的宣導和指導。
• 引入持續(xù)集成。
• 限制在制品，避免一個人同時開展多項工作，原則上不能超過2個未完成的任務。

等等……

我們不再糾結(jié)于是否一定執(zhí)行了敏捷里面規(guī)定的活動，又或者說我們現(xiàn)在的項目過程，也談不上是完整意義的敏捷開發(fā)，我們更注重什么樣的招式能有效解決我們當下的問題。

1.3.我們的絆腳石

本文開篇講到了組織架構(gòu)導致我們并不能完整的引入敏捷開發(fā)的各項機制。我相信，做過敏捷轉(zhuǎn)型的人應該都遇到了這樣的問題。以下是我們在敏捷轉(zhuǎn)型中遇到的一些實際問題，當你遇到這些問題時，不要驚訝，對于一個傳統(tǒng)的成熟組織來說很難改變，尤其在沒有上層領導積極推動的情況下。

沒有產(chǎn)品經(jīng)理，敏捷團隊只關(guān)注開發(fā)與發(fā)布，不管開始，不管結(jié)果。

在我們公司的組織架構(gòu)采用了弱矩陣形式，敏捷團隊更多的起到協(xié)作開發(fā)前端需求的作用，他們不需要對產(chǎn)品直接負責，也不會關(guān)注產(chǎn)品在市場上的反饋。

測試與開發(fā)職責界限清晰。

在理想的敏捷中，在開發(fā)過程中就開始做測試，而我們還是需要開發(fā)完成后再進入測試，走上了“小瀑布模式”之路。

無法進行短周期迭代，放棄迭代。

由于走上了“小瀑布模式”之路，根本沒辦法做到較短周期的迭代，對于一個月一個版本來說，超過2周的迭代周期已經(jīng)失去了實際的意義。

做好的功能都會發(fā)出去，基本沒有功能灰度驗證，功能越堆越多，維護越來越難。

需求人員都會認為自己想法是完美的，能有效提高產(chǎn)品的價值，他們更關(guān)注自己提的需求，而不是這個產(chǎn)品。

沒有項目經(jīng)理，只有項目負責人，項目負責人不專注，不專業(yè)。

由于公司項目是弱矩陣形式，項目更多的是協(xié)作作用，項目負責人更多的是起到拉通團隊協(xié)作的作用，由于項目負責人往往身兼多職，并不能有效的持續(xù)投入精力優(yōu)化項目過程。

等等……

2.成功的每一小步

固然，我們在轉(zhuǎn)型中問題眾多，還有很大的優(yōu)化空間，但是和以前比起來我們還是取得了不小的進步，以下招式在實際項目開展過程中具有明顯的實際意義，并不受傳統(tǒng)組織架構(gòu)排擠：

2.1.跨職能團隊

對于傳統(tǒng)企業(yè)來說，一般根據(jù)職能屬性進行部門劃分，各部門互相協(xié)作完成項目。然而，跨部門的協(xié)作成本明顯過高，當產(chǎn)品需要頻繁的跨部門協(xié)作時，這樣的模式明顯無法勝任。而在這時，公司必然也會暴露出由于這樣的缺陷，導致的開發(fā)效率低下的問題。此時，以事業(yè)部或核心部門主導，建立虛擬的跨職能團隊，也就順理成章，一氣呵成?？缏毮軋F隊能有效解決產(chǎn)品在開發(fā)時，頻繁協(xié)作溝通的問題。在這樣的團隊里，溝通由實際的開發(fā)、測試、需求人員直接當面溝通，頻率更高，信息失真也比較少，也避免了部門之間扯皮的問題。

2.2.每日晨會

晨會，是跨職能團隊進行溝通的標準活動，每天在固定的地點、固定時間花10分鐘左右舉行，是一種很有效的團隊同步機制。然而晨會看上去簡單，但是要開好，卻沒有那么容易。敏捷里面的推薦晨會內(nèi)容主要包括以下三方面。

• 昨天做了什么？
• 今天要做什么？
• 有什么問題？

對于敏捷小白的我們，剛開始照本宣科的組織晨會，但是采用標準的模式，我們卻始終都開不好這樣的晨會，下面會詳細的說說我們都遇到了哪些問題。

• 晨會溝通時，大部分信息對改善項目進展的實際意思很小，口水話太多。
• 當一位同事在描述自己昨天做了什么，今天要做什么時，大部分人并不在意。
• 大部分工程師晨會都是自顧自說，不關(guān)心自己表達的內(nèi)容是否有效傳遞。
• 推廣晨會輪流組織時，發(fā)現(xiàn)大部分人并沒有這個能力有效的組織晨會，并不太好實踐。
• 晨會討論的內(nèi)容很離散，看不到整個項目的進展。

2.2.1.怎么開好晨會

正如敏捷宣言里面提到的“個體交互勝過流程和工具”一樣。晨會，需要將當前項目的進展透明到整個團隊，并促使團隊成員基于各自目前的情況，通過溝通及時主動的解決問題。那如何才能做到快速有效的溝通呢，我認為需要做到以下幾點：

• 團隊成員都清晰的知道項目的目標和當前的狀態(tài)。
• 項目中的各項工作內(nèi)容都有清晰的優(yōu)先級，以及明確的責任人和當前的進展信息。
• 晨會有明確的規(guī)則，每個人都知道在何時做何事。
• 參與晨會的每一個人都能隨著輕松的了解到與他相關(guān)人員的任務進展狀態(tài)。

要做到這些，當然就少不了一面合理的看板墻了。它是整個晨會的核心載體，晨會時，所有的項目成員都基于看板墻的信息進行討論并更新看板墻的信息。

2.3.看板墻

看板墻，看似只是簡單的將項目中要展示的信息帖到一個版本上面去，但是如果貼得不合理，整個晨會就會一團亂麻，思路離散，最終導致晨會的失敗。接下來，我將談談我們看板的演進過程。

剛開始，我們采用上圖那樣的看板墻，紙片上僅僅寫了用戶故事，每天晨會的時候，大家圍成一圈，按順序每個人講自己昨天做了什么，今天做什么，有什么問題。當發(fā)現(xiàn)某項用戶故事改變了狀態(tài)時，就挪動到對應的列里面去。

漸漸的問題就暴露出來，我們發(fā)現(xiàn)看板墻上的卡片會有很多，而且會越來越多，因為我們總是想做更多的用戶故事，一旦某項用戶故事在開發(fā)過程中受阻，我們就會考慮開展一項新的用戶故事，我們不能接受一個人“閑下來”。另

外，由于每個人講的內(nèi)容，并沒有和卡片直接關(guān)聯(lián)起來，導致我們并不能很好的把講的信息和看板墻結(jié)合起來，以至于看板墻成了一個背景，沒有起到太多的實際意義，我們開始質(zhì)疑，輪流講問題是不是不合理，轉(zhuǎn)變?yōu)橛梢粋€人主持，根據(jù)看板墻上的信息逐個詢問探討，為了實現(xiàn)輪流主持，我們定期換不同的人進行詢問探討，但是有時候有的人卻完全不知道如何有效的主持，導致晨會下來的有效溝通很少。由于看板卡片上記錄的信息很有限，卡片數(shù)量又比較多，以至于項目負責人都難以清晰的了解當前項目的進展，更別說其他團隊成員了。于是我們把看板改成了下圖的樣子：

這樣子，看上去比以前的看板清晰了一點，能比較清晰的知道目前視覺、軟件、測試的任務情況，可惜還是存在不斷的向后面推用戶故事的問題，導致看板的在制品過多。

另外，還是存在部分用戶故事較大，在某個位置停留過長時間的問題，并且我們并不能清晰的了解到該用戶故事目前的進展情況。

這里附帶提一下，總會有人提要把需求的粒度拆分得更小，把一個用戶故事拆分到1到3天的工作量，可惜我們一直沒有實現(xiàn)，或者我們勉強把一個大的用戶故事拆分成了幾個小的用戶故事，但是在我們這種敏捷并沒有完全轉(zhuǎn)變過來的團隊，我們還是喜歡一個需求完整的交付。因為只有這樣我們的黑盒測試才能有效的測，不然會讓測試重復測，浪費測試資源，前端需求對于一個沒有做到發(fā)布狀態(tài)的需求，也覺得不好體驗。

為了有效的跟進較大的用戶故事的進展，我們開始進行任務拆分，我們規(guī)定一項任務的粒度最大不能超過三天的工作量，我們趨向于團隊成員盡量把任務都拆解到小于一天工作量的粒度，因為這樣有利于我們每日晨會進行跟進，于是看板上的卡片就分為了兩類，出現(xiàn)了下面的看板。

我們將看板上的卡片分為用戶故事和與用戶故事對應的任務，當所有與用戶故事相關(guān)的任務都完成時，將用戶故事挪到待發(fā)布中。用戶故事與任務之間使用編號進行關(guān)聯(lián)，這使得我們的晨會過程討論的內(nèi)容更加具體，而不是簡單的匯報工作，項目進展情況也比以前更加清晰。

然而，問題依舊存在，當任務卡片較多時，任務與用戶故事的對應關(guān)系找起來相對麻煩，不能一目了然的了解到用戶故事的進展情況。同樣的，這樣的看板依舊會存在前端需求大量的向后端涌入，導致后端負荷過重，效率降低的情況。得益于精益的限制在制品概念，結(jié)合我們之前的各種經(jīng)驗，我們最終使用了下面這種看板墻。

在這個看板墻里，只有用戶故事卡，用戶故事卡上拆分了用戶故事的不同任務，我們不再追求多個領域能針對一個用戶故事并行開展任務，而是一個領域做完后，再流入到下個領域。表面上并行開展工作看起來效率更高，但是那樣各領域信息并不一致，返工較多，反而導致效率低。由于任務和故事在同一張卡片上，我們可以從看板上一目了然的看到用戶故事當前的狀態(tài)。

另外，我們將卡片分為三種顏色，對應于三個優(yōu)先級，這樣大家在領取任務時，能更加自主。還有一點十分重要，每個領域我們根據(jù)他們的人數(shù)設置在制品限制，目前規(guī)定一個人同時開展的工作不能超過兩項。我們由推的模式轉(zhuǎn)變?yōu)槔哪Ｊ?。這樣能清晰的暴露領域邊界的資源匹配情況，同時也能保護相關(guān)領域不至于任務過多引起混亂，進而導致效率降低。我們由要做更多的需求轉(zhuǎn)變?yōu)椤巴Ｖ箚?，聚焦完成”?/p>

一個人的同時工作項不超過兩項并不是一個標準答案，我們內(nèi)部也未完全按照該標準執(zhí)行。對于基本不會出現(xiàn)阻塞的領域，也許一項也是一個合適的選擇。

2.4.版本規(guī)劃

由于我們的產(chǎn)品包括iOS應用、Android應用、手表端、服務器、H5這樣5個技術(shù)領域。在初期，我們遭遇了各領域互相依賴，因某個領域有bug未能及時修復，導致整體發(fā)布延期的問題，而且還經(jīng)常發(fā)生。

因此，我們采用了版本火車的概念，以發(fā)布為主，功能為輔。也就是在固定的時間節(jié)點必須發(fā)布，如果對應功能沒有達到發(fā)布要求，就推遲到下一個發(fā)布版本。這樣做卻帶來了幾個比較揪心的問題，我們版本沒有明確的主題，僅僅是一堆已完成的需求而已，導致每個版本的亮點不夠。

另外，由于沒有規(guī)劃版本，因此無法給到前端明確的心理預期，他們不知道他們的需求在什么時候能發(fā)布，他們也不知道我們的下一個版本將會攜帶哪些需求。而對于開發(fā)而言，也缺乏明確的目標感，給人一種來了需求我就做，做多少算多少的感覺。于是，我們最終還是放棄了版本火車，改為版本規(guī)劃的方式進行整個產(chǎn)品的研發(fā)。

版本規(guī)劃，最頭痛的問題就是選哪些需求進入該版本進行開發(fā)的問題。要知道，需求永遠都是源源不斷的來，需求的總量總會遠遠大于你當前版本能開發(fā)完成的總量。因此就涉及到一個需求收集和篩選的問題。如果每次版本都要篩選那么多需求，需要耗費很大一撥人大量的時間來進行需求優(yōu)先級討論，以及該需求是否在該版本做的問題。另外，在這么短的時間內(nèi)也得不到太有效的討論結(jié)果。在《看板實戰(zhàn)》中，有一個“優(yōu)先級過濾器”的實踐方案，如下：

在這個看板上，明確了一個團隊的產(chǎn)能，以及接下來要做的需求。當一個需求被挪走后，就會觸發(fā)后續(xù)需求的進入和討論，這樣每次只需要討論少量的需求，更加聚焦。這固然是一個好的實踐，可是我們現(xiàn)階段的團隊并不能適應它，因為我們并沒有真真的做到精益里面提到的拉動式開發(fā)。于是我們在進行版本規(guī)劃時，采用了如下方案：

• 在下一個版本開展前兩周開始收集需求。
• 一個版本一定要有一個明確的主題。
• 版本有明確的時間節(jié)點。
• 需求要明確必須、應該、可以三個優(yōu)先級，比例要適中。
• 必須的需求未按期完成時，版本發(fā)布時間后延。
• 應該的需求要保障至少80%的交付率。
• 可以的需求要保障至少50%的交付率。
• 需求收集完后分為多次進行版本規(guī)劃討論會議。

分多次進行版本規(guī)劃討論會議很關(guān)鍵，由于需求收集的量比較大，另外參會的人比較多，大家很難一次性達成一致。當一次會議結(jié)束后，需要給到整個團隊一些線下時間做更多的思考以及了解更多的附加信息來進一步評估。我們一般會開2到3次這樣的會議，每次會議時間為1到2個小時，這是一個逐步收斂和達成一致的過程。

3.未來

我們的項目過程，還有很多值得優(yōu)化的地方。到目前為止，我們的項目開展過程只能說做到了有序。而在接下來的日子里，我們還需要加強項目的度量。做到，不憑感覺規(guī)劃版本內(nèi)容的多少，不憑感覺說項目做得好還是差。通過度量數(shù)據(jù)，更客觀和明確的暴露項目中的問題。

4.推薦書單

對于我自身，經(jīng)歷過公司組織的一次敏捷咨詢后，就踏上了部門敏捷轉(zhuǎn)型的道路，期間踩坑無數(shù)，幸得以下書籍把我從一個一個坑里面拉了出來。推薦的書單中，部分書籍還未讀完，大部分書籍閱讀完一兩遍后還不得其道，還需要反復閱讀和實戰(zhàn)，這里就不好意思寫自己的感悟和對這些書的評價了，以免誤導大家。但是，這些書都是在我轉(zhuǎn)型的道理上，給予我不少啟發(fā)和幫助的書籍，我相信讀過這些書的人都能有所收獲。

• 《敏捷軟件開發(fā)實戰(zhàn)-估算與計劃》
• 《敏捷軟件測試》
• 《精益創(chuàng)業(yè)》
• 《精益創(chuàng)業(yè)實戰(zhàn)》
• 《看板方法》
• 《看板實戰(zhàn)》
• 《網(wǎng)易一千零一夜》
• 《人月神話》
• 《四步創(chuàng)業(yè)法》
• 《目標》
• 《卓有成效的管理者》
• 《最后期限》
• 《思考，快與慢》

本文由 @小螞蟻 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。