編者按：

      王梓晨，2012年加入京東，在運營研發部擔任架構師一職，匠藝全棧工程師。曾負責京東智能分單團隊，主導了京東智能分單系統的架構工作，4個月內提升服務性能數十倍。還研發了地址配送網點分類模型，基于機器學習算法，實現了配送到路區的精準化分單，大幅提升了分單準確率，節省人工成本。熱衷于敏捷開發，目前專注于自然語言處理、高并發架構設計、搜索技術。

       互聯網思維被定義為“專注”、“極致”、“口碑”、“快”，這四項看似互斥的四個特性卻恰恰被融合在了一起，我們通常所說的敏捷團隊，是如何做到的呢？

      2017年3月1日，王梓晨在中生代技術群做了《京東敏捷團隊看板和潛在交付物實踐》的主題分享。本次分享來自京東一線團隊的實踐總結，該團隊曾獲得京東集團優秀項目與top100最佳案例等獎項，專注于互聯網電商的服務高可用與自然語言處理。該團隊早期便采用全敏捷方式的項目管理，而敏捷團隊有效精準的識別sprint task中的潛在交付物（PSP）勢必事半功倍，本次分享滲透敏捷迭代的細枝末節來詳述京東的敏捷看板實踐。

       如果你錯過了分享直播，或者你參加了分享，還想回顧總結，本篇便是分享內容的干貨總結。

      大家好，我是京東運營研發部架構師王梓晨。“青龍系統”是京東分揀配送系統的代號，既京東高效物流體驗的支撐系統。而青龍智能分單系統是該環節的“大腦”，負責規劃配送的全路徑。即從您在京東網站下單后，貨品出庫到分揀中心運輸到哪個配送站，以及由哪個配送員最終送達到您的手中，這些規劃工作都是由智能分單系統來計算完成的。

       你是否曾有這樣的疑問，系統業務流程繁雜、戰略項目層出不窮、與日俱增的訪問量與背后技術體系需要不斷優化……今天我們就來分享京東一線作戰連隊，運營研發-青龍研發部，是如何運用敏捷精益化的管理方法，實現了產品的快速交付。

        傳統的瀑布模式之所以被詬病，其核心是交付周期長，上線效果弱，用戶差評高。而所有問題的根源，就在于無法實現產品的快速，持續交付和快速反饋。我們今天要看到的是敏捷精益管理中的看板部分，就像這樣，一個普通的任務在看板里，被拆成了N個狀態。把所有的項目和產品拆分為一個一個落地的產品需求，然后根據這些需求進行迭代跟進，一個迭代往往由兩周構成。

       這是我們早期的看板，現在已經完全線上化了。這個不重要，且來看這看板的構成。從業務需求轉化為可以落地開發的任務，再到可以交付使用的產品，都要一絲不茍地經歷這樣的成長與蛻變：

從需求到產品，往往經歷這四個階段：

IDEA => AGAIN => BACKLOG => NEXT
a) 倘若霎時間萌生一個想法：“我們要把挪威冰鮮三文魚送到千家萬戶”，那么千萬不要錯過，隨時記錄下來，別遺忘、別丟棄，放在IDEA列里。
b) 當IDEA逐漸孵化，開始滋生萌芽時，我們再次細化，“是否熱帶水果也可以送？是否查干湖凍魚也可以？…不僅僅京東自營平臺要支持，物流開放平臺也要支持…”，需求得以再次升華，體現在AGAIN一欄里。
c) 怎么結合現有的配送模式使得效益最大化，怎么全方位支持，網站下單后，經過訂單流轉的各個系統，如何有效的識別與控制……，這些問題逐一解決后，業務的一個想法便形成了初步的需求，有板有眼，列入Backlog欄里。
d) 當Backlog逐漸成熟，可以進入迭代中時，則正是挪入Next欄中。Next中的需求一般以用戶故事的形式來體現，“作為….我想要…以便于達成….的目的”這樣格式化的用戶故事并不是形式主義，而是強迫我們去思考需求背后的目的，促使對需求本身的深度挖掘。
e) 再輔以Acceptance，以及Deadline。在主要方向的驗證點和交付日期明確后，我們就可以正式進入開發了。

開發階段也被拆分為“TODO-DOING-DONE”三個階段。

a) TODO階段，我們要對進入迭代內的任務，即Next欄中的每項內容進行拆分。架構設計、數據庫建模設計、交互設計，統統體現在這里。根據細致的討論，我們把需求任務拆分為一個一個可以安心開發的子任務。每個子任務的周期建議為1-2天，這樣，風險就可以被我們控制在2天以內。
b) DOING階段中，把TODO階段拆分細化后的戰利品拖動過來，進行開發。開發中有任何問題由開發人員主動召集大家討論，若存在較大的風險或者需求有變化則及時變更航道，把影響控制在最小的范圍內。
c) DOING完成后，就可以進入DONE階段了。我們的每一個需求點都被拆解為落地的任務，并細化到天，每天晨會拖動看板的滿足感和成就感是不言而喻的。任務拖入DONE就代表著已經開發完成，junit自測完成，可以交付測試了。

測試階段，同樣也細分為“TODO-DOING-DONE”三個階段。

a)      TODO階段，對任務需求的用例進行評估，并整理出測試用例。需要性能測試的部分，也在這個階段盡可能的體現出，以便在以后的測試階段可以考慮的周全。
b)     從每一個子任務的測試DOING到DONE，標志著該User Story測試通過，可以進入上線的準備了。

最后還要介紹DEPLOY、PENDING、WASTE三個階段，這三個階段分別代表著上線完成，掛起，垃圾站三種狀態。

a) 由于外部資源的以來或者其他外部資源的介入而引起的擱置，故而PENDING必不可少，經過產品的推敲，和架構的升級，PENDING的任務可以重回DEVELOP或者TEST，同時也能從另外一個維度來審視任務制定的合理性。
b) 任務若被丟棄，則列入到WASTE一欄中。若是由于法務、合同等因素引起的，在情理之中；若是由于業務分析不夠透徹，接口性能設計不合理，那么在Sprint Retrospective時就要被列入需要重點Review的對象了，當然，小伙伴們一起決策。

綜上所述，可以縱向的審視看板。分為產品看板、研發、測試、上線以及其他五個部分組成。在敏捷重要的會議里，計劃會往往是對backlog精雕細琢，并準備放入本sprint里大干一場的。而回顧會恰恰是對Deploy里的user story做整體點評，總結與反思。對于還停留在develop & test欄里的內容，更要分析原因以改進。展示會則不僅限于deploy，test done 甚至develop done亦可以展示，短期的展示更有利于需求及時響應變化。每日站立會則是關注于user story自身的狀態、checklist、deadline等細節。

本次分享本來重點是在看板，但是關于每日晨站立會我想多說一些，我發現很多團隊把平日該有的溝通都留到站立會做，致使站立會時間變得很長，其他成員難免會出現走神，看手機之類，就對站會氛圍有損了。站立會本來只是說昨日做了什么，遇到什么問題需要誰來協助，今日需要做什么就可以了。8個人左右的團隊以15分鐘為限站會會比較有效果。而平時工作中遇到的問題，需要其他部門協調的，需要業務確認的，或者依賴中間件的…盡量盡快主動的協調。站會只是站會，不包含評審會、回顧會的職責。

那么，敏捷看板中的潛在交付物有哪些呢？

首先，如何衡量一個user story是否優質。
對于user story評價的時間節點在進入迭代開發之后。User story的拆分原則一般定義為半個迭代內可以上線完成的工作量。若涉及到多位成員的，最好可以再次細分為一位成員一個卡片。User story的名稱需要一目了然，最好設計為項目名稱-需求名稱這樣極易一眼識別的話術。當然其描述也至關重要，引起歧義或者對需求的思考不到位是最可怕的，故而描述也一定要按照As a <Role>, I want to <Activity>, so that <Business Value>的格式來書寫。除此之外還需要定義checklist作為user story的補充，checklist按照階段可以分為三類，產品業務的驗證點，開發的開發點，測試的用例點，每個環節都需要在進入各自狀態前制定完成。有了描述，有了完成列表，那么deadline自然是必不可少的，作為一種承諾。另外User story還需要一些Tags，可以包含“需要功能測試”、“需要代碼review”、“需要性能測試”、“依賴外部系統”等提醒功能的標簽。最后還可以基于任務本身的性質不同而制定不同的背景色，如按照業務需求、技術改進、bug類、業務優化類、緊急需求等來分類，一個迭代中最好適當包含一些技術提升的任務，和業務任務搭配起來使得團隊氛圍不那么單一。

從產品的idea到develop todo之間，可交付物大致分為事前分析、詳細設計與運營反饋三部分。
事前分析主要包括需求的市場調研、ROI分析報告、BRD等。
詳細設計包含業務流程圖、產品設計PRD、系統技術概要設計等。很重要的一點是產品同學需要和主要研發同學溝通業務背景及業務細節，而不斷迭代地完善產品的詳細設計。 因為文檔永遠只能是思考和記錄，絕對不能用來代替溝通。如若這些不到位，到develop或者test乃至deploy階段之后才暴露出問題，付出的代價便隨著迭代的周期而指數級增長。
運營反饋為需求上線以后，如何建立良好的運營報告分析，與業務期望的反饋，通常通過報表+監控的方式來體現。

Develop todo，這個環節絕非是可有可無的。因為user story的開發設計序列圖，數據建模，架構設計圖都要在這個環節完成，上手就寫代碼，然后再返工，相信痛過的人都知道。Develop doing至develop done之間，junit、接口設計文檔、涉及的數據字典的wiki維護都是必不可少的交付物。Develop done至test todo之間，測試人員需要主導對照user story中checklist里逐一業務點核對junit是否覆蓋完全。開發同學需要確認測試環境是否完備，如數據庫表是否建立、索引是否完善、jar是否上傳私服、rpc接口是否注冊、網絡權限、白名單、redis初始化數據是否正常、maven是否正常編譯打包運行。脫離了這些環節，只是測試同學從git上download下來，編譯打包出來的代碼對于功能測試而言沒有任何價值。

Test todo需要整理測試用例文檔，需要用線上的包冒煙一次。同時在test done之前需要針對checklist中逐條內容進行核驗，且能合理定義出邊界測試場景，還要對接口冪等性、異常輸入進行測試。

Test done后，是最容易出問題的時候，因為經過開發、反復測試，認為沒有什么問題可以上線了，故而最容易疏漏。Depoly之前，一定要merge 代碼后進行線上包的回歸測試，且逐一梳理數據庫是否完備、是否存在數據庫白名單、rpc服務是否已經注冊、redis主備是否到位、有沒有跨機房的容災、es是否讀寫分離、cassandra是否已經配置監控、回退方案是否可執行、有無業務影響、重要依賴外部系統是否有降級方案……天下大事必做于細，天下難事必做于易，嚴謹的思維是看板的基本素質。

Deploy時，對于web系統而言，除了系統日志，還要看catalina日志，以及cpu load 、mem、jvm、io、swap、線程進程、網絡指標（流入流出、接收丟棄ip包數量、tcp等詳細指標）、磁盤指標等情況。若是docker還要觀察宿主機的運營情況，有沒有異常的資源爭用。當然，這些都應該有一套成熟的監控系統自動報警并做到可視化。確保程序發布成功后，仍然需要觀察業務正常運行穩定一段時間。且需要有良好的運營監控反饋機制，可以方便的分析線上運營情況而不斷的優化業務，系統產品都是在演進中逐漸完善的，這個階段不可忽視。

看板是限制在制品的產物，是少即是多的最好詮釋。“快”和“準”需要結合良好試錯機制在有限的時間內最大限度的完美我們的產品。通過縮短交付的周期，持續進行交付，不斷收獲的喜悅，堆積，而在每個很小的跌代里不斷發起沖刺，團隊里的每個兄弟都關心所負責任務從IDEA萌芽到上線完成，到運營及用戶的反饋，以及后續優化與改進，如老曹@曹洪偉 所描述的全棧工程師，真正成為產品的主人。