阿里敏捷教練全面解析淘寶直播敏捷實踐之路

背景介紹

阿里不多提敏捷轉型或DevOps，阿里是強業務驅動的，無論用什麼辦法，必定要達到業務目標。

我來自敏捷教練團隊，咱們的職責是幫助團隊拿結果。這裏的團隊不限於研發團隊，我如今支持的團隊包括銷售團隊和產品運營團隊。咱們要幫助整個業務鏈上全部職能角色協做起來達成業務目標。

阿里同窗對敏捷的態度很是有意思。你們有問題才找我，同時會提醒我一句話，「咱們不在意敏捷，只要解決痛點和問題就行」。因此阿里的同窗很是實在，就是要見效，只要他感受到有效果，原來痛的地方不痛了，原來不通暢的地方順暢了，他就以爲敏捷轉型的努力是值得的。

面臨的問題

咱們更像一個內部顧問，團隊帶着痛點和問題來找敏捷教練，咱們要貼着他的問題想辦法，一塊兒作實踐的落地，一塊兒評估效果。

• 迭代過了一半，需求還沒定

2016年5月底，我進淘寶直播團隊的時候，主要的痛點是「需求定不下來」。當時直播跟電商結合仍是新業務，沒有人知道應該作成什麼樣。運營和產品一直在摸索。摸索的過程當中有不少猶豫，這樣需求出來的比較晚。手機淘寶一個月發一個大版本，可能離封版只有兩週，這一版到底作什麼還沒想明白，開發和測試很是着急。

• 開發時間緊，加班趕工

需求出來後，開發很是趕，基本在5-8個工做日把1個月的版本需求都開發完。一個大版本總要有些亮點，不能只作一些小改進。因此開發工做量很集中，這個時候開發都在玩命加班趕工。

• 質量不達標，版本發不出

趕工是有代價的，趕出來的東西可能表面上看是OK了，可是內在欠的技術債比較多，質量容易出問題。手機淘寶用戶量很是大，質量卡點很是嚴，有嚴重缺陷沒修好絕對不容許上線。淘寶直播2016年3月底發佈第一個公衆版本（淘寶的用戶均可以用），3月、4月、5月連續三個版本，每個版本都沒有遇上正常的發版節奏。要申請緊急發版，提申請的人超級尷尬以爲很沒面子。

• 線上問題多，運營變客服

版本發出去了，但是質量太差了，主播每天在說直播間怎麼黑屏了，怎麼閃退了。運營同窗原本應該作一些拉新、留存，想一些玩法，結果很苦的在主播羣裏作客服，運營同窗一片抱怨。

着手解決問題

• 數據度量

我須要一個儀表盤快速瞭解團隊。咱們常常講到底怎麼去衡量一個團隊是否是敏捷？或者如今有沒有比過去更敏捷？有幾個維度仍是值得你們去看的。

速率怎麼樣?一個月能不能交付更多功能，或者交付功能的價值有沒有提升。

週期時長有多長？從打算作一個功能到用戶能夠用上這個功能，享受到它的價值要多久。這個時長越短，團隊的適應性越好，在短期內能響應一個新需求並把它交付。

質量怎麼樣？不少團隊敏捷轉型的時候，一上來就追求快。短期內是快了，卻欠了不少技術債。過一段時間速率會下來，最後既沒有快也沒有好。個人思路是先保證交付的東西質量都特別好，一次把有價值的事情作對，去掉中間的返工、浪費。若是有很好的質量，架構演進會更容易，開發新功能會更快。從質量出發先好再快，長期來說可以拿到又快又好的效果。

最後準時性很重要。在阿里尤爲電商系，可能90%以上需求是倒排的。需求提出來老闆不會讓團隊評估多久能夠作出來，老闆一般說這個東西很重要，什麼時間以前必定要，並且不是光要功能，還要業務結果。阿里不看苦勞看功勞，咱們直接拉業務指標看。

還有一個最重要的維度是業務目標。敏捷也好、DevOps也好，最重要的仍是業務，若是業務沒作好其餘都是零。即使作了一百個功能，若是業務指標沒上來也是白搭。對於團隊來說，老闆跟你說10月底要達到什麼樣的業務目標，即使沒有100%把握作到，也要找到一條可行的路，10月底前把這件事搞定，在阿里這樣纔是靠譜的。

接下來會講咱們怎麼始終扣緊業務目標，作的每一件事情均可以幫助咱們拿到業務目標。這點在阿里特別重要。咱們會找一些具體的指標來度量這幾個維度。

速率度量

完成需求數是一個簡單的度量，說它簡單是由於咱們只度量了單位時間內完成需求的個數，咱們沒有算故事點數，也沒有考慮功能大小。

若是需求很是大，意味着它的開發測試時間都會變長，第一次獲得反饋的時間也會很晚。一個大需求若是拆成兩個小需求，而且每一個需求均可以獨立發佈，先上一個再上一個，實際上是比完成一個大需求再發布更好。這個指標有一個積極的反作用是鼓勵團隊把需求拆小一點，逐步的迭代和優化。我會跟產品經理商量，有沒有辦法把需求拆到研發團隊在5個工做日內能夠提測這樣的粒度。若是一個團隊有四五個開發，一週以內搞不定一個需求，意味着這個東西自己很大或者很複雜。

這個度量指標提出來後有人問我，需求大小不均，爲何只算個數。我說是爲了鼓勵你們拆需求。他說爲何要拆需求，我說不要憋大招小步快跑。這樣他本身會把邏輯理順。

質量度量

看質量更可能是看過程的質量，在提測之後發現缺陷的數量，還有嚴重缺陷和低級缺陷佔比。若是同一批人，一樣的週期，缺陷數量突增，就有點不靠譜了。從5月到8月缺陷數量有明顯的降低。

嚴重缺陷很好理解，咱們來看看低級缺陷。低級缺陷是傻子都能發現的缺陷。這個指標衡量的是提測質量。若是開發比較上心，對本身交付的東西有責任心，一般不會有不少低級缺陷。回顧會上我會問低級缺陷數量咱們有沒有辦法降下去？團隊商量後以爲一個月不該該超過十個，就變成一個目標了，團隊會朝着這個方向努力。

週期時長度量

週期時長咱們拆了三段：分析時長、開發時長和測試時長，合起來是總的週期時長。

6月的週期時長大概是30天，分析時長大約佔了一半。需求準備的時間特別長，你們以爲應該花更多時間分析需求，以避免沒想明白。實際上咱們會發現即使多一倍時間分析需求，也未必能把全部問題都想明白。咱們作的是創新的事情，這裏有很是多的未知，想在一開始就把全部坑找出來不現實。咱們要在研發過程當中去探索，而不是在前面增長複雜的流程和評審。

你們會發現從6月到8月分析時長縮短了，開發時長和測試時長增長了。尤爲是測試時長從3天增長到了7天。之前咱們是小瀑布模式：一個月的功能最後三天一塊兒提測，測試同窗加班到凌晨。後來咱們改進爲小批次逐步提測，迭代的早期開始就不斷有需求提測，測試壓力分佈在整個迭代週期。

還有一點你們可能很困惑，爲何7月的時長這麼可怕，若是翻到前面會發現7月份交付需求數量也變少了，這裏面有一個頗有意思的故事。7月有兩個很大的需求插隊進來，團隊的併發增長了。那個時候看板上有些卡片好幾天拖不動，由於開工了太多需求，研發同窗根本顧不過來。7月是一個比較失敗的版本，我把7月的度量數據拿給開發負責人，我問改進了一個多月，爲何週期時長反而變長了，完成的需求反而變少了。開發負責人很是聰明，說咱們併發過高了，這時候我以爲不須要再多說了。其實數據的力量很強大，你們知道高併發的傷害，可是傷害多嚴重不清晰。數據顯示出來，由於併發提升，增長了那麼多等待，你們以爲這件事代價太大了划不來。 8月淘寶直播火了，不斷有合做方找咱們想要加塞需求。經歷了7月版本，團隊經過反思學會說不。到了8月，咱們比較能控制本身的節奏了。

準時性度量

準時性咱們看計劃交付的功能有多少按時交付了。7月併發度提升了，速率並無提升，準時交付率也降低了。咱們6月和8月是100%準時交付 ， 7月沒作到。不要緊，只要找到緣由，吃一塹長一智就能夠了。

變化的背後

聚焦業務目標

阿里是強業務驅動的公司，作任何事情在一個季度或半年，業務效果必定要被驗證。淘寶直播是一個新業務，你們不知道往哪裏去，這時候特別須要快速試錯和驗證。

我到手淘我也不瞭解他們的業務，就作了一個業務指標板，列出9月底要達到的目標，每月發版後更新數據。

這些數據在BI系統裏能夠看到，爲何還要費力作個物理板呢？我觀察雖然在BI系統裏隨時能夠看到，而且你們都有權限，可是真正去看的就那麼幾我的，主要是運營和產品同窗。研發 TL會看，一線同窗通常不會看。你們也不太清楚正在作的功能對提高業務指標有什麼幫助。

可視化之後，你們常常路過這個板，有時候就會聊兩句，7月底了某某指標還沒到一半怎麼辦，還有同窗挺身而出跟運營說有好點子，要知道之前都是運營說服產品和開發同窗趕忙作。

業務主線

業務目標只是一個方向或者要去的地方，怎麼到那裏要有一個路線圖，要有一個規劃，這個規劃是按季度作。產品、研發和業務三方負責人清楚季度規劃，一線同窗不清楚。後來咱們決定季度規劃定下來之後要分享給全員，全部人都要知道接下來三個月要去哪裏，要攻什麼目標，打法和策略怎樣，分解到每月要交付什麼核心功能。這個規劃就是咱們的業務主線。

迭代目標

業務主線不落地也是空的，接下來迭代裏的核心功能要扣住季度規劃的業務目標和業務打法。咱們作了比較狠的事情，產品經理不僅要講作什麼功能，還要說明白作這個功能的業務價值在哪裏，這個價值還要可度量。發佈了這個功能之後看數據，好比直播間的觀衆有不一樣來源，有人從直播列表進來，有人從微博過來，有人是關注了主播從主播的直播預告列表進來，經過埋點能夠知道每一個來源對直播間UV的貢獻。直播間UV這個月相比上個月有提高，到底哪一個來源貢獻比較大，上了哪一個功能帶來了這樣的變化。有個新入職的產品經理之前作遊戲直播也沒有電商經驗，可是她提的需求通過數據驗證確實很是有效，你們很是信任她。反過來說若是一個產品經理一次沒命中，咱們會以爲他運氣很差，若是老是摸不中，再提需求可能你們要打一個問號。

迭代計劃

咱們的迭代計劃能夠一層層展開，從業務主線連接到核心需求。我剛去的時候他們恰好要發版，我問這個版本三個最重要的需求是什麼。我分別問了三個開發同窗，他們的回答不同，有個開發同窗直接跟我說作了不少，可是零零碎碎都想不起。6月、7月、8月咱們主線很清晰。

迭代過程

迭代過程咱們有物理看板，這是一個完整的端到端的板，這裏只顯示了一段。白色的是需求卡片，黃色的是任務卡片，紅色的是風險、問題或缺陷，綠色的是誰作這個需求。我跟開發同窗講，每一個人只有兩張綠紙條，每一個同窗同一個時刻最多領兩個任務，先領高優先級需求的任務，完成一個任務再領新任務。6月份開始用看板，集成封板前一天，我在釘釘上收到電子照片，全部需求在待集成那一列，而後開發TL跟我說感謝。以前連續三個版本都沒遇上節奏，此次順利集成了，你們都很開心。6月咱們沒有作更多的改進，只是把研發過程可視化出來，天天按照優先級的順序更新今天進展如何，明天計劃到哪裏，有沒有問題和風險。你們會有一種強烈的動力想把卡片拖到終點。

我剛進團隊的時候你們以爲敏捷教練不幹活，就是作了幾個板弄了點數據，到底有什麼用。你們也不太認敏捷這一套，好比開回顧會，我跟開發TL說開個回顧會吧，開發TL說代碼寫不過來沒空開，我就說我很會控場，保證一小時以內開完。他有點活動心思，就開一個小時。回顧會開了之後，他以爲說的問題都在點兒上，改進行動也靠譜，就比較認同了。

去年雙十一以後我離開淘寶直播去支持別的團隊，今年1月底我去回訪，發現他們的敏捷實踐堅持得很是好，那個板比原來的更漂亮。阿里的同窗都是價值驅動的，他以爲這個東西有用，纔會堅持作下去。

快速驗證假設

快速驗證假設的工具在不少公司都有，就是A/B Test。在手淘A/B Test有很是好的技術支持，在APP裏面集成SDK，服務端是現成的，很快能夠接入。怎麼樣把工具用好是另一個挑戰了。

首頁改版

當時想嘗試在直播列表裏透出直播信息，最容易想到把評論信息透出來，這樣氣氛可以感染到用戶，吸引用戶進來看直播。開發同窗嘗試了一個禮拜很苦惱地找我說，把評論透出來很麻煩，消息系統咱們用了別人的，這個功能他們沒有，要現開發一個。他們有一時排不上，就想看代碼本身改，結果花了一個禮拜才調通接口，有沒有辦法能夠快一點？我說最核心驗證點在哪裏，是否是透出來評論吸引用戶進直播間？若是透出來的評論信息不是從消息流裏自動獲取的，而是在某幾個直播間手動抓一些評論透出來，多久能實現？他說快的話今晚就能夠搞定。先弄清楚驗證的核心點是什麼，再去看驗證這個核心點最快最輕成本最低的方法是什麼。

直播首頁改版是很大的需求，咱們不會全部東西一塊作，而是拆成小點。每一個點能夠獨立驗證，並且很是輕，用戶幾乎感受不到變化。這個例子裏有兩個點，一是底下讚的地方從靜態變成動態，還有一個是從主播的靜態圖片改爲直播間當前的十秒視頻回放。這樣可能氣氛好一點，會吸引更多用戶看直播。不須要PRD和交互視覺設計，運營直接和開發同窗聊一下，大概知道要驗證什麼作成什麼樣，開發實現核心功能，推1%的用戶作一個A/B TEST。數據若是有明顯統計意義上的區別，可能摸對了，再按照作產品的方式精細地作出來。沒摸對，成本確定不會超過一個禮拜，這個事情不用再投入了。

一塊兒打磨需求

需求爲何定不下來？

我去參加需求評審會，發現會開得很長，三個小時尚未結束的意思。還有需求評審會變成了需求討論會。開發和測試提不少問題，好像產品經理都沒考慮到。會後我問開發你是第一次看到這個需求文檔嗎？他說是的。人的大腦很神奇，複雜的東西只要足夠長的時間均可以理解，但要在短期內理解或者判斷一個複雜的事情就很是挑戰。開發和測試短期內看一個很複雜的需求，很容易漏掉一些東西。另外有一些事情只有開發和測試知道，產品經理不知道，若是預先沒溝通，只能現場聊。

從等待接棒到攜手前行

開發說PRD交互都搞定再送到這裏，不到我這一棒我無論的。這樣到了需求評審、甚至開發測試階段才發現問題，越到後面代價越高。與其後面發現不少問題，產品從新設計，不如一開始攜手打磨需求。因此咱們有一個需求小組。需求小組不超過五我的，一般產品經理、交互設計師和一個開發、一個測試足夠了。

一塊兒打磨需求

需求小組分工協做：產品經理要把爲何講清楚，用戶什麼場景下爲了達到什麼目的要用這個功能，設計師看這麼作體驗好很差，是否是反人類的操做。開發同窗會看技術上這麼幹是否是一個性價比比較好的路徑，是否是有更好更輕代價更低的方案能夠達到一樣的效果。測試同窗能夠着手寫驗收標準，驗收標準應該是場景化的：用戶在什麼場景下作什麼操做，期待獲得什麼樣的效果。驗收標準徹底能夠跟PRD相互印證，指導後面的開發和測試，你們以爲這樣的驗收標準很是具體可衡量。需求小組裏你們先有共識，再拿到大組評審。這裏面有對比，當時拿了兩個相對複雜的需求作試點，達成共識再到大組評審，很快就經過評審了。那些根本沒參加需求小組討論的也以爲這樣設計很天然，由於你們想到的問題需求小組想在前面了。有一個需求沒有通過小組討論，產品經理想作一個比較炫的東西，被服務端開發TL拍回來，說這麼搞技術上不可行，就很是悲慘，由於那個時候PRD已經寫完了。

提升提測質量

我以爲度量是一個輔助性的工具，度量自己不是目的。團隊聚焦於改進的目標，度量幫團隊評估進展。低級BUG多開發確定有進步空間，可是光有指標你們仍是不知道怎麼改進。

這個事情特別有意思，站會上測試同窗說最近提測質量很差，直接閃退了。我問測試同窗有什麼建議。測試同窗說第一次在系統裏提測是能夠的，信任你質量過關。如何自測用例跑不過，提測要打回。打回了之後，第二次不能在系統裏提測，必須拿着手機裝上提測版本APP到測試同窗面前跑一遍自測用例。我問開發同窗，你們以爲合理嗎？開發同窗以爲有點很差意思，由於確實提測有問題，說就這麼辦。開發同窗自尊心強，讓他拿手機到測試同窗那裏跑用例感受很沒面子，提測不經過的狀況少多了。有不少改進很簡單，並且很多點子是團隊本身想出來的。

此外，你們還約定了明確的提測標準。之前「提測」比較隨意，可能本身手打包。如今要求有一個構件號，這意味着代碼合入代碼庫沒有衝突，經過了靜態掃描，基本上一些安全問題，還有低級編碼問題會掃出來，這樣才能打出來有構建號的提測包。還有端到端的自測用例經過，不能用mock。

從小瀑布到持續交付

爲何測試同窗很晚纔回家，由於之前是小瀑布，分析、開發而後整包提測。我以爲讓女孩子加班到半夜很是不人道，必定要改。首先需求拆小，儘可能拆3-5個工做日能夠提測，從第三天開始就逐步有功能提測。

迭代缺陷增量趨勢

之前咱們在發版前三天全部BUG冒出來，8月咱們發如今迭代初期有BUG出現，確定有東西能夠測纔有新的缺陷出來。我以爲缺陷增量趨勢是很是好的指標。

微軟作敏捷轉型的時候特別有意思，高層不知道底下團隊有沒有作敏捷，就去看缺陷增量趨勢。若是是小瀑布，很長時間沒有BUG，而後一堆BUG冒出來。若是持續有東西能夠測，BUG會比較均勻地分佈在整個迭代週期裏。

對開發來講也很好，若是最後提測發現嚴重BUG，修完可能帶來更多問題，最後BUG不收斂。儘早集成，儘早測試，實際上是暴露技術風險最有效的手段。

總結：持續改進

你們可能會說敏捷教練很神奇，可以想到這麼多招幫你們改進。事實上這裏大部分改進方法都是團隊同窗本身想出來的，大部分問題也是團隊同窗經過看板和度量本身發現的。每一個人天生就有得到成功和快樂的全部資源。 團隊也同樣，我相信每一個團隊都有變得成功高效的全部資源。我只是去幫助你們看到問題，激發你們想辦法，引導你們持續改進。只要咱們持續改進，這個月比上個月有進步，這個團隊慢慢總能夠成長爲一個很是棒的團隊。

做者簡介：張迎輝（花名問菊）：阿里巴巴敏捷教練，羅漢堂講師，開發和講授多門敏捷課程，前後支持手機淘寶、優酷、移動事業羣等多個部門的團隊敏捷轉型。2011年開始接觸敏捷開發，是認證的CSM、CSD、CSPO。親身感覺到敏捷給團隊帶來的改變，立志成爲敏捷踐行者。

---

本文做者：雲效鼓勵師

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。