基于PDCA原理的京東敏捷軟件項目管理研究

李志凌 王先科

(京東集團，北京 100176)

0 引言

隨著敏捷軟件開發方法在京東的使用，需要建立一套與之相關的敏捷項目管理方法。依據“先引入，再優化”的原則，京東基于PDCA原理，實踐了自己的敏捷項目管理方法。在實踐中，先規劃、執行了一批試點項目，監控試點項目運行，總結試點項目經驗，形成了項目級別的PDCA大環。在每個項目內部采用迭代軟件開發方式，每個迭代都形成了一個個的PDCA小環。大環和小環互相配合，不斷推動敏捷項目管理方法持續改進。

1 京東實施敏捷項目管理的背景

傳統的瀑布式軟件開發具有兩個痛點：第一，對需求變化的響應差。業務方在早期見不到實際的產品，無法及時給出反饋。如果在后期發生需求變化，因為設計和編碼已經部分完成，軟件變更的成本非常高。第二，早期的問題可能到后期測試時才能發現，而研發如果對需求理解有偏差，會引起極其嚴重的資源浪費和項目延期。

為了解決上述問題，京東的很多項目開始采用敏捷開發方式，研發管理部也結合京東的實際情況，制定了基于PDCA理論的敏捷項目管理流程和規范，以便對敏捷項目進行管理(圖1)。此流程通過定義連續的、短的迭代開發周期，小批量，早交付，及時獲得用戶反饋，并根據實際情況，不斷做出適應性的調整，最終交付符合業務價值的產品。其中，每一次迭代都是一個PDCA的反饋環。

圖1 瀑布開發和敏捷開發的比較

2 京東敏捷項目管理流程規范

業界標準的方法與IT公司實際采用的方法往往存在差異。一般,各公司會制定適合自身情況的敏捷項目管理流程，京東研發部也制定了適合自己的框架，包括一些輕量級的流程、規范、模板、checklist等。

京東敏捷項目管理流程很好地推動著軟件開發以迭代的方式進行，流程詳細定義了每個迭代過程的PDCA過程，給團隊以指導。整個軟件過程是持續改進的過程，交付的軟件功能點數和業務方滿意度隨著時間不斷增加(圖2)。

其中，每個迭代周期為2～4周，每個迭代都包含了PDCA各個階段需要做的工作，如圖3所示。

2.1 迭代的計劃部分

在這個部分，會定義本次迭代(2～4周)的工作目標和工作范圍(要完成的需求)，然后把本次要做的工作做WBS任務分解，形成一個初步的迭代計劃(圖4)。

同時，在執行階段，每天所有項目成員會開一個10～15min的短會。在會議上，溝通實際計劃進展情況，項目成員間互相溝通承諾當天的工作計劃。根據情況，更新迭代計劃和中期的發布計劃。

2.2 迭代的執行部分

在這個階段，團隊主要有3項工作：

(1)項目成員執行計劃中定義的軟件需求分析，開發測試任務。

(2)如果在上一輪的PDCA循環中輸出了相關的改進計劃，團隊將在執行階段對改進計劃落地執行，并衡量計劃的執行效果。

(3)收集過程中的度量數據，為后面的檢查和改進部分做數據準備。

圖2 以流程推動的PDCA迭代改進

圖3 PDCA各階段的任務

圖4 迭代計劃模板

每個迭代的輸出結果是實現了部分新需求的可工作軟件。采用短迭代，每個迭代為2～4周，目的是能夠快速地對迭代的目標成果進行檢驗，加快反饋的速度。

2.3 迭代的檢查部分

迭代的檢查分為兩部分：執行過程中的檢查和執行結束后的檢查。

2.3.1 執行過程中的檢查

(1)每日站會。每天會上，成員溝通遇到的問題，識別的風險，涉及其他成員的依賴關系。

(2)單元測試。研發人員自己做的軟件白盒測試。

(3)結對編程(可選)。2名研發人員一起工作，不斷地進行代碼評審。

(4)代碼評審。在測試前，對研發代碼的正式評審。

(5)迭代測試。對已完成的軟件進行測試，由測試人員進行。

(6)度量數據分析跟蹤。對執行過程的剩余工作量、工時、問題不斷跟蹤(圖5)。

圖5 剩余工作量的度量跟蹤檢查曲線

(7)靜態代碼分析。應用工具對軟件代碼進行掃描，進行質量分析。

2.3.2 執行結束后的檢查

迭代演示會。在會上向項目的利益相關者演示實際的可工作的軟件，得到及時的反饋，進行改進。

2.4 迭代的改進部分

在迭代結束后，項目組成員和項目利益相關者開會對本次迭代的過程和結果進行回顧，及時地總結經驗教訓，對待改進事項充分討論，形成具體的解決方案，并指派專人負責解決和跟進。改進計劃如圖6所示。

3 京東敏捷項目管理實踐案例

本節列舉一個京東的敏捷項目管理簡單案例。因為篇幅所限，這里只列出主要過程。對復雜的問題，可應用A3思維分析工具管理更好地分析跟進問題。如圖7所示。

3.1 迭代計劃會議(計劃)

每輪迭代啟動前，團隊共同討論本輪迭代詳細開發計劃的過程，輸入是產品需求列表，輸出是團隊迭代目標和任務分配。

迭代計劃會議內容包括“做什么，怎么做，誰來做”。細化、分配迭代任務和初始工作計劃，并使用撲克牌進行技術估時。在估算中充分溝通承諾，達成一致輸出的結果(本次迭代目標)，并進行總結記錄，京東有電子化工具對此進行保存(圖8)。

3.2 每日站會(檢查手段之一)

每日工作前，團隊成員的例行溝通機制，全體成員站立參加。每日站立會議的好處有：及時暴露風險和問題，促進團隊內成員的溝通和協調。

圖6 改進計劃模板

圖7 復雜問題的分析改進模板

圖8 迭代計劃范例

3.3 迭代演示會(檢查手段之一)

在每個迭代后，召開此會議。通過向項目利益相關者演示工作成果，進行階段性的檢查。

此檢查點的好處是：通過演示可工作的軟件來確認項目的進度，具有真實性；能盡早獲得用戶對產品的反饋，使產品更加貼近客戶需求。

3.4 回顧會(形成改進方案)

迭代回顧會議是促進團隊持續改進的有效手段，在每輪迭代結束后舉行會議的目的是分享好的經驗和發現改進點，促進團隊不斷進步，形成的改進方案會在下一次迭代開發中實施。

3.5 可視化管理

敏捷管理強調可視化，敏捷項目一般都建立一個實體的物理看板，用來做信息輻射，暴露問題和瓶頸。把待檢查內容和待改進的問題都進行可視化，并指派專人負責跟蹤解決。

4 結語

本文介紹了京東基于PDCA原理的敏捷項目管理實踐。在京東敏捷軟件開發項目中(包括手機APP開發項目和網站開發項目等)，采用2～4周的短PDCA循環周期，快速收到項目利益相關者和項目成員的反饋，并根據反饋和經驗總結不斷改進優化流程，很好地達成了項目目標，并逐漸沉淀為符合京東業務需要的項目管理流程實踐集。需要指出的是，目前此研究尚未在超過60人以上的大型敏捷軟件開發項目實踐過，在大團隊實施場景下，流程等可能還需要一定的調整。

[1]Mike Cohn.用戶故事與敏捷方法[M].北京：清華大學出版社，2010.

[2]Mike Cohn.敏捷估計與規劃[M].北京：清華大學出版社，2007.

[3]Durward KSobek.A3思維——豐田PDCA管理系統的關鍵要素[M].北京：人民郵電出版社，2016.