去年在一家公司時我的 CTO keys 寫的 XP 項目管理方法,對 XP 感興趣的朋友可以參考一下。
采用 XP 方法進行項目管理
-------------------------
核心價值
-------------------------
1、溝通
缺乏溝通,是幾乎所有軟體問題的根源。通過直接,及時地與客戶溝通,就可以消除大多數的問題。
2、簡單
保持設計的簡單,為今天設計,永遠不要為明天設計。
不要将注意力放在軟體的最複雜難解的功能上。今天做簡單的工作,明天花點代價修改它要比今天做可能永遠用不到的複雜工作好的多。
3、回報
更早和經常來自客戶,團隊和實際最終使用者的具體回報意見将為項目提供更多的機會來把握住正确的方向,少走彎路。
通過自動化的單元測試來獲得系統的回報,通過回報告訴我們工作做得怎麼樣。
4、勇氣
要有勇氣嘗試新得的,不同的東西來大幅度減少項目時間。要有勇氣在即使面對巨額預算和截止期限壓力時仍能堅持做正确的事情。
-------------------------
規則和實踐
-------------------------
計劃
---------
1、編寫 User Story
通過 User Story 來描述系統需要為使用者做些什麼。一個 User Story 一般三句話左右,是客戶以他們自己的術語寫成的。
2、通過釋出計劃制訂時間表
對每個使用者素材進行估計,選出一些使用者素材在第一個釋出中實作,再分别選出随後幾個釋出中應實作的使用者素材,形成釋出計劃。
3、頻繁釋出小版本
經常将疊代生成的版本釋出給客戶。這樣客戶就能及早得到并使用這些功能。這對及時地收到有價值的回報并作用到以後的開發中去是非常關鍵的。
4、将項目劃分為疊代
每個疊代一到三周。
5、每次疊代開始前制訂疊代計劃
按照 User Story 對客戶價值的高低順序,從釋出計劃中選取出來的。User Story 和上次疊代測試失敗的部分都會轉化為開發任務,每個任務應該持續一到三個開發日。
6、Move people around
在每次疊代中,鼓勵每個人去嘗試接手系統中新的部分。結對程式設計能夠在不降低生産力并能保證思維連續性的前提下使之成為可能。人員的組合可适時進行調整。避免形成知識孤島。
7、每天上班後召開 stand-up meeting
站着開會的目的就是整個組内的交流溝通。在這個每天舉行的會上,交流所遇到的問題,一些解決方案和項目的焦點所在。大家圍成一個圈站着開會可以避免長時間的讨論。
8、遇到問題時修改 XP
XP 規則是應該遵循的,但對不能良好運做的部分應毫不猶豫地加以修改。
設計
---------
1、簡單
盡量用最簡單的方法去達到目的。在為一段複雜代碼浪費許多時間前,先找出簡單的方法肯定費時更少開銷也更低。盡可能地保持簡單,盡可能晚地增加功能。
2、在設計期間使用 CRC 卡
CRC 卡的目的是讓程式員脫離過程模型的束縛,而以面向對象的方法來考慮問題和交流思想。
3、盡可能地重構
嘗試更改現有代碼是否可以讓新特性的開發更容易。檢視剛剛寫好的代碼,看是否有方法可以對它進行簡化。
編碼
---------
1、客戶随時在場
需要在現場有一位客戶來明确素材,并做出重要的企業決策。開發人員是不允許單獨做這些事情的。讓客戶随時在場可以消除開發人員等待決策出現的瓶頸。
2、代碼必需符合相應的标準
通過編碼标準防止團隊被一些無關緊要的愚蠢争論搞的不知所措。目标應該是團隊中沒有人辨認得出是誰寫的哪一部分代碼。以團隊為機關對某一标準達成協定,然後遵守這一标準。
3、首先做單元測試
開發人員在編寫代碼前先編寫單元測試。單元測試及時告訴開發人員系統在某一點上是否工作。
4、實行結對程式設計
開發人員結對進行開發。
5、經常內建
經常進行代碼內建可以避免內建夢魇。
6、實行集體代碼所有權
小組中的任何人都有權對代碼進行更改來改進它。每個人都擁有全部代碼,這意味着每個人都對它負責。
7、将優化工作留到最後。
8、不要逾時工作
長時間地持續工作會扼殺工作績效。疲勞的開發人員會犯更多錯誤。讓開發人員每天早晨都感到有活力有激情,每天晚上都感到疲憊而滿足。
測試
--------
1、所有的代碼必需有單元測試。
2、所有的代碼釋出前必需 100% 通過單元測試。
3、當發現了一個 bug,必須要增加相應的測試。
4、經常運作單元測試并公布其結果。
-------------------------
項目開發過程
-------------------------
項目開發過程分為 3 個階段:調研,承諾,疊代
調研階段
----------
1、編寫 User Story,寫入項目主目錄的 doc/TODO.txt 檔案中,例如:
* 倉庫管理
對倉庫資訊進行維護
對倉庫進行分類,例如自有倉庫、中轉倉、虛拟倉、售後倉等。
2、由開發人員評估 User Story。對于不能評估的 User Story,由需求人員對 User Story 進行拆分,拆分後再由開發人員進行評估。每個 User Story 上的開發時間為一周、兩周或三周。
承諾階段
---------
1、對 User Story 按使用者價值、風險和開發速度排序,寫入項目主目錄的 doc/TODO.txt 檔案中,例如:
story value risk velocity
-----------------------------------------------------
user 高 低 15人天
customer 高 低 15人天
role_security 高 中 15人天
sales_order 高 低 6人天
data_encryption 中 中 12人天
data_exchange 中 高 15人天
data_backup 低 低 12人天
2、制訂釋出計劃,寫入項目主目錄的 doc/TODO.txt 檔案中,例如:
* version 0.1 : 90人天,2002.7.5 釋出
user,customer,role_security
倉庫,report,sales_order,進銷存分析
* version 0.2 : 97人天
客戶退貨,編碼對照,倉庫調撥,經營管理
資料同步,資料采集,data_encryption,data_exchange,data_backup
疊代階段
----------
1、制訂疊代計劃,每個疊代一般持續一至三周。疊代計劃盡量細分到每天。
疊代計劃寫入項目主目錄的 doc/TODO.txt 檔案中,例如:
* Disability Plan Redesign
Richard: 0.5 days: 45 Transaction input
Brain: 1.0 days: DAP Counter corrections
* Supplemental Unemployment Benefit
Ralph: 1.0 days: Take deduction bases on catalog
Ann: 0.5 days: Load UPGUA history tables
2、用 CRC 卡進行設計
CRC 設計文檔規範見 $CVSROOT/knowledge/management/CRCConventions.txt
3、編寫單元測試代碼
在編寫程式前,首先編寫驗證該程式的單元測試代碼。測試代碼放在項目主目錄下面的 test 目錄中。
4、按照代碼規範進行編碼
Java 代碼規範見:$CVSROOT/knowledge/management/CodeConventions.pdf
-------------------------
Team 構成
-------------------------
1、由 2-3 個程式員組成 pair,pair 為 team 安排工作和進行工作考核的最小機關。
2、由 2-3 個 pair 組成 group,并制定一位 group leader
3、由 2-3 個 group 組成 team,并制定一位 team leader
group leader 的職責
--------------------
1、每天上午上班後組織 group 成員召開 stand-up meeting 進行組内交流。
2、指導 group 使其按照項目管理的要求進行工作,在技術上和業務上對 group 成員進行幫助。
3、檢查 group 成員的送出到 CVS 中的代碼,每天下班前将發現的問題寫到 $CVSROOT/knowledge/management/GroupReport.txt 中。
4、需求分析和系統設計。
5、可接收性測試。
team leader 的職責
-------------------
1、在項目管理,技術和業務上對 team 的工作進行指導。
2、檢查各 group 的工作,每天下班前将發現的問題寫到 $CVSROOT/knowledge/management/TeamReport.txt 中。
3、需求分析和系統設計。
4、可接收性測試。
項目管理部的職責
-------------------
1、檢查所有的 team 是否按照項目管理的要求在工作。
2、檢查所有的 team 的疊代計劃。
3、每天将檢查的結果形成項目管理報告($CVSROOT/knowledge/management/PMReport.txt)
4、可接收性測試。
其他注意事項
1、源代碼就是文檔
在整個開發過程中的 User Story 是臨時的文檔,不會被長期保留,CRC 文檔和源代碼才是最終的開發文檔,将被長期保留。
2、不說悄悄話
通過 IRC 等工具進行交流,讓所有的人都知道你在怎樣思考,減少悄悄話。