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

李志凌 王先科

(京東集團(tuán)，北京 100176)

0 引言

隨著敏捷軟件開發(fā)方法在京東的使用，需要建立一套與之相關(guān)的敏捷項目管理方法。依據(jù)“先引入，再優(yōu)化”的原則，京東基于PDCA原理，實踐了自己的敏捷項目管理方法。在實踐中，先規(guī)劃、執(zhí)行了一批試點(diǎn)項目，監(jiān)控試點(diǎn)項目運(yùn)行，總結(jié)試點(diǎn)項目經(jīng)驗，形成了項目級別的PDCA大環(huán)。在每個項目內(nèi)部采用迭代軟件開發(fā)方式，每個迭代都形成了一個個的PDCA小環(huán)。大環(huán)和小環(huán)互相配合，不斷推動敏捷項目管理方法持續(xù)改進(jìn)。

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

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

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

圖1 瀑布開發(fā)和敏捷開發(fā)的比較

2 京東敏捷項目管理流程規(guī)范

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

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

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

2.1 迭代的計劃部分

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

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

2.2 迭代的執(zhí)行部分

在這個階段，團(tuán)隊主要有3項工作：

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

(2)如果在上一輪的PDCA循環(huán)中輸出了相關(guān)的改進(jìn)計劃，團(tuán)隊將在執(zhí)行階段對改進(jìn)計劃落地執(zhí)行，并衡量計劃的執(zhí)行效果。

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

圖2 以流程推動的PDCA迭代改進(jìn)

圖3 PDCA各階段的任務(wù)

圖4 迭代計劃模板

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

2.3 迭代的檢查部分

迭代的檢查分為兩部分：執(zhí)行過程中的檢查和執(zhí)行結(jié)束后的檢查。

2.3.1 執(zhí)行過程中的檢查

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

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

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

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

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

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

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

(7)靜態(tài)代碼分析。應(yīng)用工具對軟件代碼進(jìn)行掃描，進(jìn)行質(zhì)量分析。

2.3.2 執(zhí)行結(jié)束后的檢查

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

2.4 迭代的改進(jìn)部分

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

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

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

3.1 迭代計劃會議(計劃)

每輪迭代啟動前，團(tuán)隊共同討論本輪迭代詳細(xì)開發(fā)計劃的過程，輸入是產(chǎn)品需求列表，輸出是團(tuán)隊迭代目標(biāo)和任務(wù)分配。

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

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

每日工作前，團(tuán)隊成員的例行溝通機(jī)制，全體成員站立參加。每日站立會議的好處有：及時暴露風(fēng)險和問題，促進(jìn)團(tuán)隊內(nèi)成員的溝通和協(xié)調(diào)。

圖6 改進(jìn)計劃模板

圖7 復(fù)雜問題的分析改進(jìn)模板

圖8 迭代計劃范例

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

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

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

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

迭代回顧會議是促進(jìn)團(tuán)隊持續(xù)改進(jìn)的有效手段，在每輪迭代結(jié)束后舉行會議的目的是分享好的經(jīng)驗和發(fā)現(xiàn)改進(jìn)點(diǎn)，促進(jìn)團(tuán)隊不斷進(jìn)步，形成的改進(jìn)方案會在下一次迭代開發(fā)中實施。

3.5 可視化管理

敏捷管理強(qiáng)調(diào)可視化，敏捷項目一般都建立一個實體的物理看板，用來做信息輻射，暴露問題和瓶頸。把待檢查內(nèi)容和待改進(jìn)的問題都進(jìn)行可視化，并指派專人負(fù)責(zé)跟蹤解決。

4 結(jié)語

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

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

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

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