如何高效地進行敏捷開發管理

敏捷開發其實也是企業的一種管理文化。

目前軟件行業敏捷開發管理最大的問題在于太看重具體的形式，而忽略了敏捷的初衷。

很多公司請幾個敏捷教練建立流程，把會議室的椅子都搬走宣布從今以后大家站著開會了，使用敏捷管理工具建立迭代、建需求、分任務，可是這真的就意味著敏捷了嗎?

因為敏捷，老板要求這個功能明天上線，怎么實現我不管，畢竟響應變化高于遵循計劃。

因為敏捷，我們希望每天至少發布一個版本，沒辦法，敏捷要求我們快速地交付可工作的軟件。

因為敏捷，雖然需求我們還沒想好，但是這個版本要保證本周內上線，敏捷宣言說得好，要欣然面對需求變化。

因為敏捷，我們項目一篇文檔也沒有，畢竟工作的軟件高于詳盡的文檔。

我們不禁要問，這真的是敏捷嗎?敏捷的初衷是團隊成員能夠更加緊密地配合完成工作，敏捷開發強調擁抱變化，但并不意味著可以隨心所欲地變更需求。敏捷開發的實質是通過迭代式增量軟件開發的方式，防止出現長期閉門造車嚴重偏離客戶需求，達到快速響應市場變化的目的。

下面我想分享下我們公司在近百人的開發團隊，同時進行十幾個項目開發的過程中，是如何使用CORNERSTONE管理平臺進行敏捷項目管理的。

一、角色劃分

杰夫·薩瑟蘭將SCRUM團隊中的角色分為三種：

開發團隊成員，負責開展具體的開發工作;

Scrum主管，協助開發團隊把事情做得更好;

產品負責人，決定應該做什么工作，擬定待辦事項清單的內容。

我們根據我們開發中的實際情況將系統中的角色分為以下四種：

項目經理：相當于Scrum主管，負責協調團隊內部合作，召集站立會議，把控項目整體進度。需要明確的是，項目經理并不是一個傳統意義上的團隊領導。用更流行的話說，項目經理更像是一個仆人式領導。項目經理不應該對團隊成員大吼小叫，也不會告訴研發人員該做什么以及如何開發一款產品，而是應該集中精力幫助研發人員清除前進道路上的障礙。

產品經理：相當于產品負責人，負責決定應該做什么工作，擬定待辦事項清單的內容，確定各個事項的優先順序。事實上，和很多人理解的不同是，確定各個事項的優先級幾乎是敏捷中最重要的工作。為什么?在軟件開發領域有一條根據數十年研究工作總結出來的原則，即在任何一款軟件中，80%的價值來自20%的功能。人們總喜歡說每個需求都是重要的，但產品經理需要問一下自己，究竟哪些需求能夠給整個項目帶來最大的價值?而這些能夠帶來最大價值的需求就必須優先完成。

開發人員：開發人員是項目開發任務具體的實施者。他們負責完成開發任務，及時反饋開發進度。

測試人員：測試人員是項目測試任務具體的實施者。他們負責制定測試計劃，編寫測試用例，創建以及回歸缺陷。

在CORNERSTONE中，我們可根據項目成員的具體職能設定不同的角色和權限。

二、收集需求(用戶故事)

在項目開始前，產品經理應該基于用戶或市場的需求，來編寫用戶故事，即CORNERSTONE中的需求。一個好的需求(用戶故事)一般應該滿足INVEST標準：

(一) 獨立性(Independent)——盡可能地使一個需求獨立于其他的需求。需求之間的依賴使得制訂計劃、確定優先級和工作量評估都變得很困難，通常我們可以通過組合需求和分解需求來減少依賴性。

(二)可協商性(Negotiable)——需求的內容要是可以協商的，需求不是合同。

(三)有價值(Valuable)——每個需求必須對客戶具有價值。

(四)可評估(Estimable)——開發團隊需要衡量需求，以便確定優先級和工作量，并便于安排工作計劃。

(五)規模小(Small)——一個好的需求要盡量維持小規模，至少要確保在一個迭代周期中能夠完成。需求越大，在安排計劃、工作量評估等方面的風險就會越大。

(六)可測試(Testable)——一個需求要可以測試，以便確定它是可以完成的。如果一個需求不能夠測試，那么你就無法知道它什么時候可以完成。

基于以上原則，CORNERSTONE支持在創建需求時，關聯其他需求(這樣我們便可以做到組合需求來控制單個需求的粒度!)，關聯測試用例(確認需求是可以被測試的!)，關聯迭代(確保需求可以在一個迭代中完成!)，設定優先級以及開始截止時間。

三、沖刺規劃會議(Sprint Planning Meeting)

在每個迭代開發正式開始前，我們都會舉行一次規劃會議，由產品負責人講解需求，由所有團隊成員一起負責將需求拆解細化成具體的開發任務。開發任務的顆粒度最好足夠細，以確保一名開發人員在一個迭代周期內可以開發完成。

一次沖刺規劃會議中的產物一般為：

(一)具體分配到每個開發人員的任務列表;

(二)會議紀要，CORNERSTONE提供了WIKI功能，可以在系統中保存每次會議的會議紀要;

四、每日站會

在迭代開始后，我們團隊一般每天上午固定15分鐘左右進行內部溝通。我們一般會打開CORNERSTONE任務的看板視圖：

每個團隊成員只需要用三到五句話說明以下三個問題：

我昨天做了什么來完成我的任務;

我今天打算做什么來完成我的任務;

有沒有什么可能的阻礙因素會導致我不能按時完成任務。

一般來說，項目負責人需要聚焦于幫助團隊成員解決阻礙因素，以幫助所有任務按時完成。

五、隨時關注團隊進度

在迭代的開發過程中，項目經理需要隨時關注項目的開發進度。我們的項目經理一般通過CORNERSTONE提供的項目儀表板來查看項目的整體完成情況;通過燃盡圖了解任務的完成情況;通過缺陷分布、缺陷累計來了解迭代完成的質量。

系統自帶的甘特圖能隨時查看迭代的具體進程以及每個項目成員的任務分工情況，做到分配合理。

除了以上統計外，還有一個“報表”功能屬于管理員專用，報表功能包含迭代燃盡圖、代碼提交統計、狀態分布統計、每日新增曲線，每日完成曲線、累計數量曲線以及成員工時列表等統計信息。

六、評估總結

在每一次迭代束之前，我們的研發團隊成員還要聚在一起開個評估會，向產品負責人演示在這個階段之內取得的成果，接受評估意見。研發團隊成員會評估一下列表上的工作任務已經完成了多少，自己是在這個階段的沖刺中認領了太多任務以至于沒有做完，還是工作任務認領得太少了。CORNERSTONE同樣提供了匯總視圖，用以在這類會議上展示說明。

最后總結一下，敏捷其實是一種管理方式，敏捷不會告訴我們具體每個項目應該怎么做，杰夫·薩瑟蘭有句話說得好，不要猜測，要規劃、執行、檢查、行動。我認為這句話道出了敏捷的本質。