編者按：

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

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

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

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

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

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

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

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

從需求到產(chǎn)品，往往經(jīng)歷這四個階段：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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