編者按：

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

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

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

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

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

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

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

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

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

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

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

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

測(cè)試階段，同樣也細(xì)分為“TODO-DOING-DONE”三個(gè)階段。

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

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

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

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

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

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

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

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

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

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

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

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

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