千億成交額背後，京東技術團隊的敏捷轉型模式

導讀ID:TOP100case

導語：本案例主要介紹了京東敏捷轉型中的案例：如京麥、倉儲開放平台、途牛。並且在最後總結了京東的敏捷轉型模式，即一個中心，四個基本點（價值為中心，透明、迭代、反饋、教練四個基本點）。

（全文共4052字 預計閱讀時長：4分鐘）

案例一

京麥團隊-創造互聯網行業無人離職的奇蹟

2012年底，有一個屌絲團隊，做的產品慢慢被邊緣化，客戶不滿意現有產品，技術負債高，團隊馬上要被解散去做其他產品了。這個場景聽起來熟悉嗎？這就是當時京麥團隊的處境。

很幸運的是，團隊leader旁聽了一次敏捷的工作坊，知道敏捷應該怎麼玩，也知道了和其他團隊之間的差距在哪裡。因此京麥團隊決定試一試，用敏捷開發的方式進行軟體開發，有了想法馬上行動。

第一步，組織團隊進行敏捷培訓，全員知道什麼是正確的敏捷軟體開發。這是敏捷軟體開發的第一步，也是至關重要的一步。

第二步，團隊坐在一起，這裡團隊指的是產品、研發、測試整個團隊，而不僅僅是研發。團隊坐在一起的好處有很多，比如有了問題，直接喊「張三這個問題我們一起看一下？」 又或者產品和研發正在討論某個具體的需求，測試人員聽到後立刻加入進來，信息快速共享並達成一致。

另外，團隊坐在一起還有其他的好處，團隊的每日站會更加容易同時一起開，代碼評審也會隨時隨地的發生，任務板上的任務團隊更容易更新。簡言之，團隊坐在一起更容易促成團隊之間的溝通，以及信息共享。

第三步，按照Scrum框架的定義，嚴格地開展每一個會議，如迭代計劃會、每日站會、迭代評審會、迭代回顧會以及產品列表梳理會。每一個會議都不能省略。

第四步，Scrum會議堅持開的情況下，團隊可以嘗試引入已經被證明有效的良好工程實踐。如持續集成、結對編程、測試驅動開發等

在堅持以上四步之後，京麥團隊達到了如下的成果：

交付周期從之前的12周，降到現在的2周

同時在線的用戶數提升了3倍

活躍用戶數提升了5倍

京麥團隊到現在敏捷轉型接近三年，團隊也已經拆分成4個小團隊，整個團隊還是在堅持著使用Scrum的方式，每兩周一個迭代，持續交付價值，持續改進。下面是他們團隊任務板的一個持續改進圖，供大家參考。

在京麥團隊的帶動下，整個POP團隊都已經開始了敏捷轉型之旅。

案例二

倉儲開放平台-交付效率提升1倍

倉儲開放平台團隊在人員數量不變的前提下，2015年上半年就完成了2014年一年的任務量，即團隊效率至少提升了1倍。想知道這個團隊是如何做到的嗎？我們一起來看看這個團隊的例子。

首先這個團隊經理是很開放的一個人，喜歡新鮮事物，喜歡嘗試。這是非常好的開端。

第一步，倉儲團隊的總監找到我們，商量進行大團隊的敏捷轉型。

這裡多說一下，為什麼這個團隊的總監會找到我們。前期我們（敏捷教練）在POP京麥團隊的成功試點，越來越多的團隊也想進行敏捷轉型。也就是說通過早期成功的樣板團隊，樹立了榜樣，也為後期的敏捷轉型鋪好了路。

第二步，敏捷導入，即進行普及性的培訓。上面提到的團隊經理和他手下的幾個leader都來參加了Scrum Master敏捷訓練營的培訓。

團隊經理聽完培訓之後做出反饋：「在京東第一次接觸敏捷研發管理的思想，是在今年春節前一次公司組織的敏捷培訓課程上，聽了敏捷教練BOB的授課，感覺這種管理模式既可以改善現有研發工作中的一些問題，又能給團隊帶來很多新鮮事物，真是我們迫切需要的。於是，在部門領導的倡導下，我們幾個三級部門開始了各自團隊的敏捷之旅。」

第三步，團隊開始按照Scrum進行敏捷軟體開發，並且持續改進。大多數團隊一開始都會選擇兩周作為一個迭代周期，因為兩周是一個很好的開始點。

第四步，制定了團隊規則之後，就要執行。比如「最初開站會的時候，大家都不是很積極，到了規定的時間，很多人還在忙自己的事情，不叫不來。

後來敏捷團隊制訂了獎懲機制，每天不按時參加站會又不提前請假的，都要扣20塊錢作為水果基金。這下大家的積極性提高了，每天參加站會的人也比較齊全了。有一次一個同事因為處理問題，晚來了2分鐘，本來是有情可原的，但為了兌現承諾，他主動買了5盒草莓分給大家。」。

另外，回顧會議是非常關鍵的。「在敏捷回顧會上，大家都要總結上個迭代周期里的工作情況，包括做得好的地方和需要總結提高的地方。會議由Scrum Master主持，每個人會拿到不同顏色的便簽紙，藍色的便簽紙上寫做的好的實例和總結，紅色的便簽紙上寫的是待提高的事例和建議。在寫完總結後，大家會按順序輪流發言，提出自己的意見和建議，最終匯總到Scrum Master處。每次回顧會，都會讓大家獲得很多的經驗和寶貴的意見，從而提升整個敏捷團隊的工作質量。」

在部門領導和公司管理層的支持下，我們敏捷團隊鳥槍換炮，從以前傳統的牆面看板，上升為觸摸電視屏幕的電子看板。懷著激動和感激的心情，我們幾個小夥伴瞬時間將高大上的觸摸電視和支架組裝完畢。

在團隊敏捷轉型的一開始，為了讓大家對Scrum有更全面的了解，團隊還自發組織了讀書行動。每天固定時間固定地點，團隊花30分鐘共同閱讀同一本書，並且大家會就這一個主題進行討論。

案例三

途牛-全新項目的敏捷轉型

5月8日京東和途牛聯合宣布，雙方展開深入戰略合作。6月下旬，我作為敏捷教練進駐途牛團隊，幫助途牛項目一期進行敏捷軟體開發的輔導。

針對全新項目的轉型，有以下幾點需要注意。

第一，需要先梳理出第一版的產品列表（Product Backlog）。一開始我就和途牛團隊的8位產品經理進行產品需求的梳理，並且使用用戶故事地圖進行了產品需求的大概規劃。

第二，團隊坐在一起。產品研發和測試全部坐在一起。由於這個項目的特殊性，需要和途牛進行頻繁的介面測試和聯調，途牛團隊也安排坐在一起了。

第三，形成Scrum of Scrums（SoS）會議。這個項目有四個團隊，跟團游、門票、平台、途牛方。每個團隊都有自己的每日站會，固定每天下班前每個團隊代表和產品經理一起開SoS會議，同步團隊開發中遇到的問題、障礙和風險。

第四，團隊堅持Scrum的會議。並不斷改進產品和團隊一起的工作方法。

京東敏捷軟體開發的精髓

一個核心，四個基本點

一個核心：價值驅動

四個基本點：透明、迭代、持續改進、教練

「一個核心：價值驅動」

不以價值驅動為導向的敏捷轉型就是耍流氓。我見過很多團隊要進行敏捷轉型，而如果你要問他們為什麼要敏捷，則答案五花八門：老闆的要求，聽說敏捷能讓我們效率提升，質量提高。也有很多負面的聲音，敏捷不適合我們團隊，我們公司文化和敏捷不匹配，敏捷就是加班，等等。這些都沒有回答到點子上。

敏捷軟體開發的精髓就是儘早頻繁的交付商業價值（感謝Alistair Cockburn博士）。任何不以價值驅動的敏捷軟體開發都是偽敏捷。

以價值驅動，以價值為核心，具體到實踐層面要怎麼做呢？

我給大家介紹一個非常有用而且簡單的工具—產品列表（Product Backlog）。團隊敏捷轉型，在接受了普及培訓之後，第一個要做的事情就是建立一個且是唯一的產品列表。這麼做最重要的原因就是需求統一入口。

一個產品只有一個產品列表，並且產品列表要符合DEEP原則，即Detailed Appropriately, Emergent, Estimated, Prioritized.

介紹一下DEEP原則，對應的中文分別是：

Detailed Appropriately詳略得當的。也就是說產品列表中的需求條目是有粗粒度的，也有細粒度的，不是完全一樣的。馬上要做的需求，一定屬於細粒度的；而1個月後要做的可能就是粗粒度的。

Emergent湧現的。產品列表中的需求是湧現出來的。可能在產品開發過程中，用戶或開發人員有一個很好的想法或點子，那麼我們就把它加到產品列表中去。

Estimated估算過的。每一個需求條目需要是做過估算的。只有做過估算，我們才知道它的規模大小，再結合已知需求的價值大小，我們就能判斷出這個需求的投入產出比。

Prioritized排序的。每個需求條目都有一個唯一的順序。

「四個基本點：透明 迭代 持續改進 教練」

基本點一：透明。

敏捷軟體開發當中最重要的基本點就是，透明。回想一下上面的案例中，團隊轉型一定要盡量讓團隊坐在一起，這是保證透明的基礎。團隊坐在一起之後，團隊間的溝通會比原來順暢很多，信息也就很容易的暴露出來，即團隊信息狀態的透明。

敏捷轉型中的另一個很重要的基礎設施是任務板。對於一開始實施敏捷轉型的團隊，我強烈建議使用物理的任務板。物理任務板有非常多的好處：

團隊信息以及團隊進展的公開。

每個人每天都需要更新自己的任務，受到同僚壓力，團隊中濫竽充數的人幾乎不存在。

物理任務板可以任意進行重新規劃和設計。（相比電子任務板）。

基本點二：迭代。

有些人在說敏捷是什麼的時候就說，敏捷就是快速迭代。這個說法有點過於片面，不過也說明了迭代是敏捷當中很重要的一個基本點。

兩周一個迭代周期，並且迭代結束的時候一定要交付出潛在可交付的產品增量。這樣有什麼好處呢？

兩周固定的迭代周期，省去預定會議的行政事務，團隊可以形成習慣。

兩周就會有交付物，相比原來兩個月甚至一年才有一次交付物，這是一個極大的提高。

對於軟體開發來說，用戶能看到（或者使用）產品才是最關鍵的。因為只有用戶看到（或使用）產品，他才可以給出真實的反饋。團隊才能基於用戶的反饋做出調整，做出用戶真正想要的產品。

基本點三：持續改進。

一提到持續改進我就想起一位日本友人的介紹：持續改進在日語中是Kaizen。他跟我們提到1次改進不是Kaizen，10次改進也不是Kaizen，100次改進也不是Kaizen，只有做到1000次改進才能算是真正的Kaizen，即持續改進。為什麼一定是1000次呢，他說到只有做到了1000次改進才能養成改進的習慣，才能算作持續改進。

在Scrum中有三個會議可以給團隊提供持續改進的機會。

每日站會。每天團隊在一起，同步團隊整體的進展情況，相互鼓勵並改進。

迭代評審會。團隊和產品負責人一起回顧一下迭代內的產品增量，以及利益干係人都有哪些反饋。這是一個非常好的改進產品的機會。

迭代回顧會。團隊在一起反思，作為一個團隊我們哪裡做的好，哪裡可以做的更好，哪些是我們想要嘗試的。回顧會是一個團隊工作流程改進的機會。

基本點四：教練。

在我的Scrum Master敏捷訓練營培訓課上，我會介紹Scrum的三條腿的基礎，即透明、檢視和調整。在寫完第一個基礎透明之後，我會問參與者下一個基礎是什麼。很多次大家會回答，敏捷教練。雖然Scrum的基礎沒有敏捷教練，但我還是想強調一下對於敏捷轉型來說，敏捷教練是非常關鍵的。

敏捷教練會做哪些事情幫助團隊呢？

培訓。作為普及性的培訓，讓團隊全員了解Scrum是如何工作的，以及團隊需要如何一起工作。

輔導。敏捷教練需要和團隊在一起工作，指導他們的Scrum會議。

挑戰。作為敏捷教練，需要不斷的挑戰團隊現狀，讓團隊能夠緊密的一起工作。另外，敏捷教練還可以把一些新想法、新的嘗試帶入到團隊，並讓這些新的內容生根發芽。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！