《京東敏捷實踐指南》讀後感

背景：

2022年5月，踐行敏捷已經有一年有餘，自認為在Scrum這套框架下已經玩明白了。就老想著找個參照物來驗證一下我們團隊的敏捷成在什麼水平，也找過類似AMM這樣的框架來評估成熟度。但是整體得分不高，這讓我在心中種下了一個疙瘩，評分不高如何改善？其他的公司敏捷是怎麼做的？如何借鑑（抄作業）？機緣巧合下找到了這本《京東敏捷實踐指南》。由於在2022年5月的時候，我的敏捷知識還停留在當時從Scrum聯盟所學習的CSM認證體系課程。核心問題是一直是以Scrum Master的視角去建立3355的架構，沒有深入而這本書在一定程度上補全了我對敏捷的認知。

正文：

我們先來談談這本書講了什麼？

全書只有7個章節，總體來說算是短的，概況起來也很容易大致分為 敏捷基礎 、 敏捷實踐、敏捷流程 三個部分。

第一部分：敏捷基礎

1，第一章，為什麼需要敏捷？

重點1.1：闡述 VUCA時代 。即：動盪性（Volatility）、不確定性（Uncertainty）、複雜性（Complexity）、模糊性（Ambiguity）。

重點1.2：闡述瀑布與敏捷對比。包括：瀑布模式與敏捷的價值交付對比、風險對比、鐵三角對比。

重點1.3：敏捷帶了的收益。包括：提升員工參與度、更快推向市場、提高生產力、消減缺陷。

2，第二章，敏捷是什麼？

重點2.1：敏捷歷史，敏捷起源。傑夫·薩瑟蘭 1995年釋出Scrum框架，2001年17位大師共同簽署《敏捷宣言》。

重點2.2：專案生命週期。

預測型：需要提前大量的計劃工作，然後一次性去執行，執行是一個連續的過程。

迭代型：允許對未完成的工作進行反饋，從而進行修改該工作。

增量型：向客戶提供多個已完成、可立即使用的可交付成果。

敏捷型：既有迭代也有增量、頻繁交付便於根據反饋不斷完善交付成果。

重點2.3：敏捷宣言

重點2.4：十二原則。

重點2.5：主流敏捷框架。

方法	特點
Scrum框架	面對一個5~11人的小團隊，關注管理實踐，核心是迭代
看板方法	面對各級團隊，關注管理實踐，核心是採用看板、限制在製品及拉動式工作，通常搭配看板方法其他各種方法，如Scrum、XP等
XP	極限程式設計，關注工程實踐，通常各種方法都與之搭配，適合各種規模的組織。
SAFe	規模化敏捷框架，面對成百上千人的組織，採用系統思維，自頂向下對整個組織進行設定，核心是將組織現有的各角色對映到預定義好的敏捷角色中，並逐步演進工作方式。
LeSS	大規模Scum,面對成百上千人的組織，採用以少為多的原則，自底向上最大化自組織團隊，核心是強調解耦並最小化團隊，強調不要盲目擴充套件Scum規模。
DevOps	開發運維一體化，除了採用敏捷文化、敏捷運作，核心是打通部門牆，再以工具鏈提升各方面共同作業效率。

第三章：敏捷轉型的四步法。

第一步：培訓。

1：自頂向下 VS 從底向上

2：內部教練 VS 外部諮詢

3：傳統模式 VS 敏捷模式

4：制度流程 VS 管理工具

第二步：調研&方案。

1，成立轉型決策委員會

2，成立敏捷轉型工作小組

3，健全需求管理機制

4，建立釋出火車並設立准入標準。

5，推進持續整合。

6，推進自動化測試

7，調整工作環境

7，增加產品特性團隊獎勵機制。

8，建立基於度量的改進機制。

第三步：通過MoMoKo模型推進敏捷業務

1，影響地圖：Why+Who+How+What

2，使用者故事地圖：使用者+故事+功能集

3，看板：交付+透明+價值+拉動

第四步：通過覆盤、回顧，持續改進。

第二部分：敏捷實踐

第四章，敏捷轉型案例

案例一：360評估專案交付（績效考核專案）

痛點：專案週期短、時間緊、任務重、方案複雜、技術複雜等挑戰因素。如何在保質保量的前提下，更快速的交付專案，以及專案目標。

方案：使用Scrum框架，組建敏捷團隊。對團隊灌輸敏捷價值觀（承諾、勇氣、專注、開放、尊重）。統一目標，追求團隊目標一致性，打造團隊願景、使命、價值觀。針對團隊使用看板管理日程事務做到 滲透式溝通。

關鍵詞：

Scrum：是迭代式增量軟體開發過程，是敏捷方法論中的重要框架之一。3個角色：PO、SM、DevTeam。三個工件：PB，SB，增量。5個事件：衝刺、計劃會、每日站會、評審會、回顧會

MVP（Minimum Viable Product）：用最小的成本和最有效的方式，把產品快速推向市場，然後基於市場的反饋快速迭代。
DOR（Defintion of Ready）：準備好的定義。對於什麼樣的情況才是準備好了，是做好方案是準備好了？還是做好計劃算準備好了？形成團隊共識。
DOD（Definition of Done）：完成好的定義。對於什麼樣的情況算是完成了，是上線了算完成了嗎？還是測試了算完成了？所有人形成統一認知。
釋出計劃：釋出計劃是指系統部署釋出的排期計劃。軟體釋出並非一迭代一個釋出，釋出也不與迭代強掛鉤（釋出計劃>迭代計劃）。
迭代計劃：迭代計劃是指規劃當前迭代中所承載的目標、以及支援目標的任務、責任人、截止時間，計劃工期等。
會議：迭代計劃會、每日站會、迭代評審會、迭代回顧會。
自動化測試：頻繁且快速的交付，對測試人員是一個極大的挑戰。需要依靠自動化測試工具解放測試人員。

收益：通過使用敏捷專案管理模式，對產品進行卷動規劃，利用MVP 持續獲得使用者反饋，不斷優化使用者體驗，修復缺陷，及時調整產品方向對專案進行糾偏。對團隊內部進行定期覆盤，經驗積累在早期，使得團隊持續改進。最終獲得了使用者高度好評。

案例二：青龍看板實現高績效（內部管理專案）-Kanban

痛點： 傳統瀑布模式被詬病，主要體現在交付週期長、上線效果差、使用者評價低，無法實現產品的持續交付與快速反饋。

方案：敏捷管理模式下使用看板（kanban），將從需求到產品全過程進行視覺化管理。

從需求到產品4個階段：IDEA（創意）、AGAIN（細化）、BACKLOG（方案）、NEXT（後續）
開發時期分為3個階段：TODO（待辦）、DOING（進行中）、DONE（完成）
測試時期分為3個階段：TODO（待測）、DOING（測試中）、DONE（完成）
上線時期分為3個階段：DEPLOY(上線完成)、PENDING（掛起）、WASTE（垃圾站）

結合電子看板，可以清楚的看見流動時間、流動速度、流動效率，流動負載、流動分佈。

收益： 完成需求個數提升69%，加班時間減少50%，團隊通過持續交付。不斷積累收穫的喜悅，團隊每個人都關係所負責的任務從想法到上線完成，再到運營以及使用者的反饋。

案例三：京東ME打造移動快速交付能力實踐（網際網路專案）

痛點：傳統的軟體開發模式需要經歷：需求調研、方案梳理、系統設計、開發、測試、部署、運維等過程。週期長、迭代速度慢。在面對移動辦公應用行業快速發展，同時內部需求也非常複雜，並且不斷變化的場景下難以支撐。

方案：引入Scrum敏捷開發，解決需求頻繁變動、開發週期越來越短的問題。

組建團隊：以使用者為中心組建特性團隊。
制定團隊精神團隊工作協定：DoD、DoR。
產品敏捷：A，需求優先順序（Pi）、驗收標準（AC）

B，按照INVEST原則拆分需求： Idependent(獨立的) 、Negotiable(便於溝通的)、Valuable(有價值的)、Estimable(可估計的)、Small(小的)、Testable(可測試的)

C，梳理明確的目標和願景，並清晰的傳遞給團隊。

業務敏捷：邀請業務方共同參與評審，向他們展示開發成果，並接收反饋。
工程敏捷：快速交付業務需求，工程敏捷實踐包括：自動化測試、單元測試、TDD（測試驅動開發）、DDD（領域驅動開發）、持續整合。基於目標儘早發現問題，儘早解決問題。

收益：原先2個月才能交付的產品，並且不能保證符合使用者需求。現在一週一個版本的交付，連續7個版本之後完成產品交付。有效提高了需求準確性、以及軟體交付能力。

優化：1，規模化敏捷；

2，交付指標度量；

A：交付效率：需求交付週期、開發交付週期、交付吞吐量；

B：交付質量：線上缺陷密度、故障恢復時間、上線成功率；

C：交付能力：釋出頻率、釋出前置時間。

案例四：京東購物APP千人敏捷案例（京東APP）

痛點：多團隊共同作業，需求模組多，新需求多，單個需求上線時間要求短，版本時間間隔長。

方案：採用規模化敏捷，啟動SAFe模型來管理產品，組建虛擬團隊、建立釋出系統、形成規則、開展方法論培訓。

實踐一：虛擬團隊：跨越地域障礙組建產品、研發、測試、專案角色。形成標準化Scrum團隊。
實踐二：全員培訓：

SM培訓：專案經理、部門領導，未來都有可能成為SM
PO培訓：團隊的產品經理是PO的最佳人選。
Scrum團隊培訓：全員參與培訓，獲得CSM認證。

實踐三：需求拆解：

1，產品經理作為唯一入口接受需求。
2，按照不同場景分析問題和機會。
3，需求流轉到業務開發部門進行分析和梳理。
4，對使用者故事進行評估和計算，並梳理優先順序。

實踐四：多團隊共同作業：各團隊以版本釋出為目標，打造團隊節奏。進行關聯需求的共同計劃會，解決多個團隊聯調共同作業問題。（PI Planing）
實踐五：版本列車（釋出火車）：固定釋出節奏，如同列車到點發車，趕不上就只能下一趟。
實踐六：釋出規範：《敏捷團隊流程規範》

《角色及崗位職責》
《團隊DoR&DoD標準》
《看板工作流標準》
《需求梳理會議流程標準》
《迭代計劃會議流程標準》
《站立會議流程標準》
《回顧會議工作流程標準》
《評審會議工作流程標準》

缺：《專案立項標準流程》、《專案啟動會標準流程》、《專案驗收會標準流程》；另外組織還需要補充各個職能的流程規範（產品、專案、測試等）

實踐七：迭代日曆：團隊事件（會議、釋出等）形成公開日曆，固定時間、固定地點，建立團隊節奏感。
實踐八：版本平臺工具：

設定管理系統：實現系統設定和質量監督管理。（程式碼、檔案）
打包管理系統：CI自動化打包平臺，每日自動整合。提供完備的質量保證機制、研發預警機制。
灰度釋出系統：實現系統灰度釋出，與整體釋出平臺連線。
奔潰監控系統：資料監控實時報警，及時跟進效率，定義以郵件或IM方式自動通知。減少人工參與，減少資源使用。

收益：整體交付效率從1-1.5月發版一次，縮短2週一次的發版頻率，專案交付效率提升41%，Bug減少58%，釋出準確率達到100%。業務和版本完全解耦，質量得到保障，需求顆粒度更小，交付更快速。

經驗：團隊leader要經常反思，提防「假敏捷」的形式主義，不能提高效率，反而增加工作量。

案例五：企業資訊化部SaaS化敏捷專案群實戰（辦公自動化專案）

痛點：IM、OA、ERP、HR多個產品線需要協同，業務複雜、需求多、利益相關者眾多，溝通協調複雜、開銷大、專案緊急任務重；

方案：明確解決方案、價值主張與定位；明確各系統之間的依賴關係，宣講上下文；制定整體方案定位以及產品路線圖；匯入SAFe專案群管理模式，開展敏捷專案群管理，組織專案群增量計劃會議（PI計劃會）；

收益：通過價值風險管理（已解決、已承擔、已接受、已減輕），大大降低了專案失敗的風險，使得各階段里程碑如期交付，並持續迭代重新整理計劃，各團隊同步進度、問題和風險。

案例六：企業資訊化部自動化測試實踐

痛點：敏捷管理是採用小步快跑，分批發布必然需要依託強大的測試支撐，來保證產品質量。傳統的手工測試，不足以滿足業務需求。

方案：搭建自動化測試平臺，解放測試資源

TAAS自動化測試平臺：專門為PC端和伺服器端打造的自動化測試平臺。講自動化測試用例、自動化場景執行、自動化測試報告傳送串聯，形成自動化迴歸閉環。
JMAC移動雲測平臺：提供行動端測試完整的解決方案，按部署方式分為：伺服器端功能、使用者端功能。包括：測試用例指令碼維護、釋出包管理、測試結果分析與傳送、CI、遠端真機
JCPS效能壓測平臺：提供一個BS架構的輕量級壓測平臺簡化壓測流程，提升壓測效率。
SCAP程式碼掃碼平臺：基於靜態程式碼檢查提供的一套可行的解決方案，涉及：並行處理、流程控制、OOP規範、例外處理、效能、集合處理、命名規範、註釋規範、複雜度及依賴檢查

延伸：UI自動化測試、API自動化測試、自動化測試、自動化單元測試。

收益：獲得指標中的問題管理與效率管理。單次執行節約人工測試50個時。

案例七：7FRESH技術研發中心持續整合實踐（線下生鮮）

痛點：解決持續整合實驗；包括：單個工程師的多程式碼之間整合；多個工程師之間的程式碼整合；應用與資料庫以及中介軟體的整合；不同程式組裝業務系統後的整合。

方案：通過建設CI/CD流水線，解決持續釋出與持續整合問題包括：本地構建、整合構建、提測構建、釋出構建。

構建型別	具體事件	需要的工具
本地構建	自動編譯	通過Maven和JFrog 實現一鍵編譯；
	單元測試	Junit單元測試框架實現對用例編寫、用例執行和結果反饋。 Mockito模擬單元測試中的外部依賴，實現單元測試用例的獨立
	程式碼掃描	SonarLint、FindBugs、PMD等程式碼掃描外掛支援本地掃描。
整合構建	事件觸發	Git 或SVN 程式碼管理工具，通過設定WebHook能夠在程式碼提交和等事件時通知整合伺服器啟動構建任務。
	任務管理	使用Jenkins，來監聽程式碼提交時間、構建任務管理和排程、構建結果反饋。
	構建任務	自動編譯和單元測試，同本地構建。程式碼掃描，可以通過SonarQube這樣的程式碼質量工具與Jenkins的整合來實現。元件測試和單元測試一樣，通過Uit和Mockito來支援
提測構建	事件觸發	如果通過Jira 、禪道等工具來管理「送測」，可以由整合伺服器來監聽提測事件，從而觸發提測構建。
	構建任務	自動編譯、單元測試和程式碼掃描通整合構建實現，任務管理通過Jenkins實現，該階段自動化測試中的元件測試需要部暑並啟動應用程式，因此以自動部署為前提（詳見自動部署）：可以通過AP叫和GUI兩種方式來測試單個服務元件或業務元件，API測試需要支援RPC協定和HTTP協定的自動化測試框架；
	自動部署	需要有組態檔、資料庫腳木和部署指令碼的集中管理工具。採用Docker方式部署，則利用Dockerfile替代原來的部署指令碼，並需要映象管理工具的支援。
釋出構建	事件觸發	需要企業統一發布平臺的「應用釋出」事件通知整合伺服器啟動構建任務
釋出構建	構建任務	自動編譯、單元測試、程式碼掃描、自動化測試（元件測試、整合測試和系統測試）都通過Jenkins等持續整合工具來實現任務排程和管理，該階段執行的測試屬於驗收測試，需要部署並啟動應用程式：整合測試是服務元件或業務元件通過業務或資料流程整合起來進行的測試：系統測試多通過GUI測試來實現，需要支援GUI測試的自動化測試框架（如支援WbUI的Selenium和支援Mobile UI的Appium等）。釋出構建中的自動化測試步驟，除了被測系統外圍依賴的服務需要應用Mock工具，其他依賴(如DB和中介軟體)都需要是實際存在的並且儘量與生

第三部分：敏捷流程

第五章，敏捷專案管理流程範例

5.1 概述

5.1.1 適用範圍：本流程與規範適用於京東企業資訊化部敏捷專案及與之類似的各種專案。

5.1.2 約定：重點介紹具有自身特點的敏捷實踐流程與規範。

5.1.3 角色與職責

Scrum Master （SM）

內部推薦有影響力且對敏捷有熱情的人員擔任；
依據Scrum方法論，為取得更好的實施效果，不建議PO兼任SM；
負責輔導團隊執行Scrum流程；
保護團隊不受外部干擾；

產品負責人（Product Owner PO）

為產品規劃遠景；
為投資回報率（ROI）負責；
負責產品定義、編寫PRD、設計原型、驗收產品；
維護產品待辦列表(Product Backlog）；

開發團隊（Developers）

具有自組織、跨職能特點，包括：開發、測試、後端開發人員。
負責交付產品功能；
最適宜的規模：3~9人;
遵循 Definition of Done 來注入質量

專案經理（PM）

組織協調、推動解決專案問題，負責解決資源不足、外部依賴等問題。
定期向團隊及利益干係人彙報專案進展、問題、風險。
對專案範圍、成本、質量和價值進行監控。
推進及把控敏捷專案執行。

5.2 整體流程框架

5.3 流程描述

5.3.1 立項

目的：	確定專案是否有實現的價值以及具備進入實施條件。
角色:	業務方、Scrum團隊以及評審專家組
輸入:	業務方原始需求、商業需求檔案（BRD）、立項報告
輸出：	初步的產品待辦列表、立項評審記錄
執行：	系統架構-->方案評審-->釋出計劃-->迭代計劃-->Sprint0規劃-->Product Backlog （優先順序）-->立項評審

5.3.2 制定整體版本釋出計劃

目的：	確立整體版本和迭代計劃
角色：	Scrum團隊、業務方
輸入：	初步產品待辦列表
輸出：	版本釋出計劃和迭代計劃
時間：	立項會結束後
執行：	需求梳理-->使用者故事地圖-->業務流程圖-->制定DoD

5.3.3 專案執行（Scrum Guid）

事件	5.3.3.1 迭代計劃會	5.3.3.2 每日站立會議	5.3.3.4 迭代開發	5.3.3.5需求梳理會	5.3.3.6 迭代評審會	5.3.3.7 迭代回顧會
目的	確定當輪迭代需要完成的任務及如何完成達成共識.	同步資訊，暴露問題和風險。	產生交付增量	為研發人員進行更為準確的任務拆分和迭代估算提供依據，為下一次迭代計劃會議有效執行做好準備。	團隊演示Sprint成果，獲取業務方的反饋。	發現迭代過程中的問題，以持續改進。（總結經驗教訓）
角色	Scrum 團隊、業務方代表	開發團隊、SM	Scrum 團隊	Scrum 團隊	Scrum 團隊、專案經理、業務方、相關利益干係人。	Scrum 團隊、專案經理
時間	每一輪迭代的第一天	每天固定時間	計劃會議結束之後	推薦迭代中期進行（Any Time）	迭代的最後一天	評審會後，下個迭代計劃之前
輸入	Product Backlog	更新後的看板	Product Backlog、 Sprint Backlog	調整前的Product Backlog、新的需求資訊	本輪迭代可以演示的成果。	改進建議
輸出	Sprint Backlog	待跟進實現	產品增量（潛在交付物、程式碼、檔案、使用者手冊）	經過更新的Product Backlog	業務方、相關利益干係人和PO的反饋。	回顧會議紀要改進計劃（清單）
執行	需求優先順序任務分解與估算團隊速率匹配需求數認領任務（無指派）單任務顆粒度8~16小時	團隊成員更新任務狀態輪流發言，三個問題。時長控制15分鐘。不深入討論，有必要另組會領導若參會，不發言	設計：架構、互動、風險編碼：持續整合、程式碼重構、程式碼檢查。測試：單測：開發人員用例：測試人員自動化：測試人員體測：產品經理 Bug分級：測試人員驗收測試：使用者	全員梳理or單人溝通。 PO主導故事點估算。優先順序排序。 I think every User Story ，Must be have Ac。	Scrum 邀請業務方、相關利益干係人（關鍵決策人）參會。演示已完成功能。獲取反饋，以及接受or拒絕的決定。 Scrum團隊審視DoD完成情況。	SM引導，暢所欲言回顧、覆盤（Kiss）針對問題，討論方案。高優先順序項作為改進任務，納入下一個迭代進行處理。

5.3.4 結項

目的：	按部門的規範結束專案
角色：	專案經理、PO、業務方
輸入：	《專案總結報告》、《專案結申請》
輸出：	結項審批意見
時間：	團隊和業務方約定結項日期
執行：	核心功能驗證並通過->未完成、非核心、待優化項批准運維或新立專案方式進行開發-->按《結項管理規範》執行

5.4 需求管理

需求條目化：每個使用者故事需要有規範的格式

使用者故事（US）：

三要素（角色、活動、價值），舉例：作為一名<角色>，我想<功能or目標>，這樣就可以<商業價值or收益>。
3C：卡片（Card）、對話（Conversation）、確認（Confirmation）

驗收標準（AC）：假設/假定（Given）上下文、前置條件，當（When）執行某些事件、行動或操作，那麼（Then）獲得可觀察到的結果。

維護產品待辦列表：根據價值排列需求優先順序，需要符合DEEP 原則。

Detailed Appropriately （詳略得當）
Estimated （做過估算的）
Emergent（湧現的）
Prioritized （排列優先順序的）

5.5 變更管理

為了保持迭代節奏，原則上是不允許在當前的迭代中加入額外需求，需求變更需要依據以下原則進行調整，同時遵守專案變更原則。

質量缺陷類的需求（線上bug）。
公司戰略級緊急需求。
與系統執行效率相關的非緊急需求
與使用者體驗相關的非緊急需求
普通的新功能需求，調整至後續迭代（即：加入新功能的需求，優先順序被修改，需要拿走同等故事點需求）

5.6 專案監控

早會：同步風險、問題、工作進展。
燃盡圖：剩餘工時、進度。
Sprint Backlog：任務狀態
會議：定期舉行利益者相關彙報會議。
專案經理監督：目標、範圍、成本、質量、進度、風險
釋出計劃：持續交付、風險彙報。
流程：流程約束與監督，如：變更流程
看板：資料監控看板以及報表，進行團隊狀態播報與彙報

5.7 敏捷成熟度評估

成熟度模型：有意識的（一級）< 有實踐的（二級） < 熟練的（三級） < 可靠的（四級） < 優化的（五級）

成熟度評估維度：每個季度執行一次評估，自評，互評。

5.8 敏捷專案度量參考維度

過程維度（舉例）：

所有需求錄入專案管理系統的完整度（描述、優先順序、驗收標準）
各項會議前、中、後的準備與跟蹤。
使用者故事的顆粒度合理拆分，建議3天
任務顆粒度顆粒拆分，建議8小時
日事日畢，每日更新任務狀態
持續整合，程式碼掃描發現的問題，bug，以及評價修復時間
自動化測試比例、單元測試覆蓋率
流程合規度，是否按時間盒執行，沒有超時
團隊迭代速度。

結果維度（舉例）：

平均上線時間
需求平均前置時間
開發平均前置時間
專案目標達成度
上線後的問題缺陷數或故障次數
上線問題平均修復時間

第六章敏捷優秀實踐

一、產品研發流程

階段	創意漏斗	探索分析	產品規劃	迭代交付	運營&體驗優化
目的	過濾創意，確定戰略方向，進行組合管理；	價值探索，確保開發有價值的需求；	從使用者角度對需求條目進行描述（使用者故事），規劃最小可行產品（MVP）及多個迭代的釋出計劃；
角色	業務部門利益相關者、業務代表、產品負責人	業務代表、真實使用者、產品負責人、開發團隊、Scrum Master；	業務代表、真實使用者、產品負責人、開發團隊、Scrum Master；
時間	進行週期性會議討論和決策，如每週或每兩週一次；	1～2周；	1周以內；
輸入	點子、使用者需求、運維反饋、運營資料、業務部門戰略規劃；	BRD	產品願景、產品路線圖、產品特性清單；
輸出	戰略主題、產品組合看板、BRD。	產品願景、產品路線圖、產品特性清單（FeatureList）。	使用者故事、產品待辦列表、部分詳細使用者故事的PRD、迭代計劃、釋出計劃。
過程	戰略主題產品組合看板	現場觀察深度訪談沉浸式體驗產品願景利益相關者地圖價值主張畫布人物角色使用者體驗地圖產品路線圖快速原型	使用者故事產品待辦列表 DoR和DoD 使用者故事地圖釋出計劃	原型驗證產品待辦列表梳理會議迭代計劃會議每日站立會議敏捷架構持續交付流水線使用者體驗測試迭代評審會議迭代回顧會議	使用者體驗地圖運營監控
說明	無論是ToB產品還是ToC產品，首先都會對眾多創意進行過濾，確定高優先順序、高價值的產品方向。如果涉及多個業務線，還需要規劃在有限的可承擔的成本和人力投入下，各業務線業務需求的投入百分比，進行組合管理。	利用同理心，站在使用者的角度探索使用者，挖掘使用者的痛點和需求，考慮使用者體驗，構思解決方案，並對其進行驗證。	將需求條目化，並從使用者角度對條目進行描述（使用者故事），按場景組織使用者故事，規劃最小可行產品（Minimum Viable Product，MVP）及多個迭代的釋出計劃。	以迭代的方式進行細粒度的迭代規劃、開發、驗證、使用者體驗測試，以及按業務需要正式上線。	運營推廣，監控生產環境的實際執行效果，分析運營資料，根據使用者反饋優化使用者體驗，持續打磨產品。

電梯演講（Elevator Pitch）的格式描述願景，具體如下：

為了［目標使用者］，他們的［需要和機會］，這個［產品名稱］，是一個［產品型別］，它可以［關鍵優點，使用理由］，而不像［同類競爭者］，我們的產品［差異化宣告］

感悟：

對於《京東敏捷實踐指南》一書我給出：⭐⭐⭐⭐⭐ 五顆星。

這本書基本把敏捷常見的流程、工具、框架都有介紹到位，是一本可以直接拿來實操的書，我所負責軟體專案部一直把時間都花在了3355的建設上，但是3355只是Scrum框架最基礎的模樣，足夠簡單，但也不夠完善。我們公司雖然將職能分成了「產品設計部」、「軟體專案部」、「軟體研發部」、「軟體質量部」、「IT運維部」這五個部門，但是花時間建設的一直是軟體專案部，所有心思都變成了，怎麼開好四個會議：「計劃會、每日站會、迭代評審會、回顧會」。所有的工作基本都是以專案經理視角，為了開好這幾個會議而去工作。然後這是短視的，開篇有講這本書在第一定程度上補全了我對敏捷的認知。我覺得至少在前段「產品設計部」和後段的「軟體質量部」給我開啟了視野，也做出了改變。

1，產品經理的改變：問題清單，使用者故事，產品路線圖，原型設計。

問題清單：

之前：無論是產品經理，還是專案經理，又或者是軟體的實施專員，只要收集到了使用者提出的問題也好，需求也罷就登記在禪道中。禪道中的需求一直在積壓，這裡使用者提出的有些是問題，要立即解決。有些是需求，需要經過評審。但是到底是問題，還是需求我們就沒有把這個規範給建立起來。

之後：我們利用線上檔案，建立了一個使用者問題清單，所有提出的問題、需求、異常都經過問題清單登記，然後經過產品經理與項經理評審之後再決定是問題或需求、Bug。再走對應的流程，這一份檔案清單的建立，將於使用者對接的需求替換成了問題。而問題轉換為需求，登記在問題清單的，不一定要做，也不一定知道怎麼做。而登記在禪道的，就是一定要做，而且方案已經經過評審。

使用者故事：

之前：一直以來我們並沒有理解使用者故事的概念，傳統的認為就是需求，而需求也沒有統一的格式，長的可能連方案帶圖片幾百字，短的也有可能就一句話。並且故事沒有估算故事點。更沒有根據故事點，計算團隊速率。除此之外，還有一個問題是，需求從來只寫了要做什麼，卻沒有寫上不要做什麼，導致一直以來迭代都有延期的情況。

之後：按照<角色>、<目標>、<價值> 固定格式來寫使用者故事，每次迭代中期有一次故事點評估會議，根據故事點數，以及團隊迭代速率限定每次迭代做多少用故事。另外以AC的模式寫清楚驗收標準，迭代延期得到一定程度的控制。

產品路線圖：

之前：經常被使用者告知某某需求需要緊急優先，導致插入臨時任務造成迭代延期。

之後：產品路線圖根據使用者故事（故事點），以及團隊迭代速率。排期「迭代執行計劃」每次評審會後與使用者一道更新。使得團隊保持固定節奏，同時也能使用者明白「產能有限」插入需求就要移走需求的道理。並且，也可以讓團隊內部人員知曉要提前為哪些技術做預研。

原型設計：

之前：原型設計，沒有形成統一設計語言、設計規範，甚至沒有統一工具。

之後：統一工具，統一規範，每次原型變更需要經過內部評審，使用者評審後，放在禪道需求當中，不在只設計當前迭代要開發的內容，讓產品部可以獨立工作。

2，專案經理的改變：DoD、專案日曆、釋出計劃、迭代目標、會議紀要（郵件）

DoD：

之前：團隊內部對完成的定義，並不一致。開發人員任務開發完成就算完成了，測試人員任務釋出就算完成了，專案經理任務迭代驗收單簽署了就算完了。

之後：形成團隊DoD之後統一認為，一個需求釋出了才算完成。

專案日曆：

之前：多個專案團隊的會議以及釋出時間，資訊不方便查詢，組織內也沒做到透明。

之後：建立專案日曆，各個團隊的資訊，通過日曆直接查詢。作為專案部經理，我也可以選擇時間參加任意團隊的會議。

釋出計劃：

之前：沒有制定釋出計劃，迭代結束日期就是釋出日期，迭代與釋出是強耦合。

之後：迭代與釋出解耦，需求完成通過測試，即可釋出。制定好釋出計劃，初期按「釋出火車」固定每週2、4釋出。

迭代目標：

之前：只有專案目標，沒有迭代目標。以致於這個迭代怎麼算完成了，怎麼樣才能獲得使用者認可並沒有統一認知，也沒有形成團隊默契。

之後：每個迭代必須制定迭代目標，每日站會強調，昨天我為目標搞定了什麼，什麼阻礙了迭代目標。

會議紀要（郵件）：

之前：有會議計劃，但是沒有將會議紀要轉換成待辦清單，以及分發業務部門要承擔的部分和 IT要承擔的部分。會議也沒有共同簽字，甚至都沒有以郵件形式群發。

之後：迭代計劃會，評審會。都有明確的會議紀要，形成待辦清單，雖然沒有會籤但是每次郵件都會發給專案干係人做為溝通管理。

3，開發人員的改變: 單元測試，CodeReView

單元測試：

之前：單元測試一直很薄弱，開發人員依賴測試做把關，測試人員有礙於對業務的理解，漏測時有發生。

之後：部分開發工程師，逐步建立單元測試的理念。

CodeReView：

之前：程式碼審查，沒有固定週期，也沒有通過程式碼審查進行技能教練。

之後：逐步建立程式碼審查規範，部分專案團隊有固定週期。

4，測試人員的改變：自動化測試

自動化測試

之前：無自動化測試。依賴純手工檢測。

之後：建立測試用例評審制度，逐步引入DevOps測試工具。

5，運維人員的改變：無

《京東敏捷實踐指南》作為我學習敏捷體系依賴，我認為最具可執行的一本書，作者理論知識很紮實，而且這些理論也付出了實際行動的驗證。在此本書的閱讀當中，如果讓我再這本書選一初對我改變最大的地方，我想就是故事點+產品路線圖。這個工具成功的讓我後續一個專案中將混亂的一百多個需求，在三天內，規劃清楚要跑多少迭代，哪些需求在哪幾個迭代完成，能讓我和使用者在一個頻道上溝通，成功的解除了那次專案危機（如圖）。

慚愧的是雖然做出瞭如上改變，但是大約半年後續這些改變由於缺乏監督，取得的成果在逐步退滑，這也是管理沒跟上的後果：僵化，優化，固化。

道阻且長，行則將至！至此，就寫到這裡。