如何用敏捷消除專案風險？

weixin_33806914發表於2015-03-16

你是否曾經參與過範圍或需求定義糟糕的專案？如果一個專案已經有大量的技術債務或者有你以前從未使用過的技術怎麼辦？如何處理團隊、平臺、時區、甚或是上述所有方面的依賴關係？作為一名敏捷教練，我會經常遇到所有這些型別的挑戰。現代軟體開發的現實是我們每天都會面對這些挑戰，而及時降低風險的技巧使我們仍然可以以一種及時且可持續的方式為使用者創造最大的價值。親愛的讀者，我聽到了你們的問題，我們如何才能實現那個目標呢？我沒有銀彈，但我確實有一種系統方法，可以幫助你們更及時地處理風險。

風險和敏捷

為了能夠準確地計劃我們的工作，並能夠在一個合理的時間段內交付工作，對於敏捷計劃和評估（關於這點，任何型別的專案皆是如此），我們有多個型別的風險必須瞭解。根據我的觀察，在任意一項工作中，最常見的風險型別通常可以歸結為以下幾類：

需求風險：例如，故事定義糟糕，工作範圍/故事很大（通常，任何一個使用者故事都有大量的驗收標準），或者對客戶價值/優先順序缺少了解；

實現風險：例如，使用新的或不熟悉的技術，處理遺留程式碼庫，缺少流程/自動化測試，或者其它技術債務；

依賴風險：例如，任何跨團隊/產品/平臺的依賴關係，跨（多個）時區工作，或者任何外部依賴關係，如客戶、合作伙伴或者外包開發。

你說的好極了，現在我們有了一些常見的風險模式，但我們能用那些資訊做什麼呢？我們對風險有了很好的理解，但如果我們不能及早識別風險，然後落實某種規避計劃，那麼我們最終的狀況將和現在一樣保持老樣子。接下來，我們需要落實一些方法，幫助我們在“釋出計劃（release planning）”過程中及早識別風險。

釋出計劃

（點選圖片檢視大圖）

計劃多個迭代的概念並不複雜。大規模敏捷框架已經針對（但未提交）多迭代為我們瞭解工作設計了一個很棒的視覺化系統，並且在凸顯更高階別的工作風險方面做的不錯。這個迭代對映的輸出是未來五個迭代的工作的一個粗略的計劃，該計劃基於先前的速度和團隊能力將故事對映到迭代，讓我們對未來的迭代輸出和可能獲得的故事有一個不錯的構想。

需求實現依賴（RID）風險

在這個迭代對映的過程中，我們可以推敲目標故事（在邏輯上最近開始的），識別需求風險、實現風險和依賴風險（RID）的風險級別，對於任意一個故事，均簡單描述一下我們是否面臨著或高、或中、或低的風險。這有兩個影響：首先，它會影響評估，因為風險更大的故事自然會被估計得更大（高風險會降低產出）；其次，我們瞭解了風險級別後就可以設法降低風險。

\\\\

在釋出層面，我們可以基於識別出的風險型別——需求、實現或依賴——做許多事情：

針對需求風險，我們也許可以將故事分解成多個部分，保證工作優先順序有良好的定義，而且這個優先順序應該在整個過程中不斷的進行完善（例如，使用MoSCoW系統，故事對映，或者獲取一個功能優先順序），並設法保證我們正在處理的使用者故事定義良好——它們描述向誰交付價值，交付什麼價值以及我們為什麼想要交付那種價值了嗎？它們是符合INVEST模型的好的使用者故事嗎？解決這些問題有助於消除需求風險。

針對實現風險，我們需要了解現有問題：我們正在處理大量的技術債務嗎？如果是，在開始另外一項工作之前，我們要努力減少債務嗎（在這種情況下，技術債務故事將在我們的待辦事項列表上進一步上移）？對於新技術，我們需要引入“探究故事（spike story）”以便理解如何進行並做出最佳決策嗎（在這種情況下，我們可以增加探究故事，並將實現風險高的故事向後推，直到風險降低）？

針對依賴風險，我們需要了解依賴的型別和產生的原因。為了降低依賴風險，可以使用另外一種方式劃分工作嗎？可以使有依賴關係的團隊更高效地合作嗎——例如，留出專門的時間用於團隊合作？我們需要將某個故事進一步推遲，以便其前繼故事能夠得到專心處理並在我們開始工作之前完成嗎？如果我們在等待合作伙伴或客戶，我們如何保證能及時獲得我們需要的東西？我們越早提出這些潛在的障礙，就越可能獲得一個令人滿意的解決方案。我們需要確保我們與合作伙伴和客戶的合作儘可能的高效。

在釋出計劃階段識別出所有這些風險可以為我們提供更長遠的眼光，我們可以據此調整我們的計劃，並引入降低風險的辦法。然而，我們的工作性質不是靜態的，需求自然會隨著時間發展變化。在釋出計劃層面上做的這些工作是其中的一部分，但我們還需要比這個更經常地考慮風險。在迭代計劃階段考慮就太晚了，因為在那個階段，我們實際上已經投入到工作中去（沒有時間去降低風險了）。那麼讓我們進入待辦事項梳理會議。

待辦事項梳理

在迭代計劃階段，有幾個我在敏捷團隊中經常遇到的問題：

故事定義糟糕（尤其是驗收標準）\\t
故事有太多或太複雜的依賴關係\\t
故事過大\\t
故事難度增加（引入新技術或新增團隊成員）\\t
團隊被過度使用（由於諸多因素的影響）\\t
對於需要完成的工作糟糕的理解\

準確指出這些問題背後的哪怕一個因素也是不可能的，但在計劃之前檢查需要完成的工作有助於我們面對這些問題中的一部分，即使不是全部。待辦事項梳理是一個檢查工作及減少這些問題的機會。

對於做這項工作的團隊而言，待辦事項梳理是一個發生在迭代中段某個節點上的一次會議。其想法是讓團隊展望就要進行的工作，並確保它已經準備好，可以新增到我們的迭代待辦事項。我們如何知道工作什麼時候準備好？當滿足我們的就緒定義的時候。因此，在這個會議中，我們在一個相對細粒度的層面上檢查每個故事，確保RID風險因素都是低（或者勉強是中等）風險的。

我遵循的工作流程大致是這樣的：

產品經理向團隊粗略地介紹按照優先順序順序排序的待辦事項（直覺上，大約一個半迭代的工作似乎是最理想的）；\\t
從優先順序最高的故事開始，將RID風險等級分為高、中、低；\\t
對於任何高風險的故事，識別風險原因，然後努力降低風險（按照前文的描述）。對於風險無法降低的故事，要麼引入一個任務項，並在下一個迭代開始之前執行，要麼重新排定優先順序；\\t
重複上述過程，直到所有故事滿足DoR（如果它們很可能包含在接下來的衝刺中）；\\t
作為一個全面檢查，確定故事大小（如果故事太大，那麼可能有一些風險因素沒有考慮到）。\

RID工作流程圖——Boost Agile

如果我們在開始迭代計劃的時候遵循這個工作流程，那麼團隊不僅對將來需要完成的工作有一個很好的理解，而且對於我們而言，團隊也會處於一個理想的狀態。這使得產品經理對優先順序更加確定，意味著他們可以就面臨的任何問題與干係人、客戶等等進行更加有效地溝通。遵循這個工作流程還能極大地增加計劃的精確度，使團隊在實現迭代承諾方面覺得更自信。簡單的會議，巨大的收穫。

下一步

希望現在你已經看到了對承擔的工作進行風險評估的價值。雖然RID可能不是對每個團隊而言都恰好合適（你對自己所面對的風險的理解應該比我更好），但有一個執行緒的過程，確保你只接收高質量、定義良好的工作加入待辦事項，這有助於我們實現一個更加可靠且可重複的流程。

從團隊的角度來說，高質量的工作意味著他們在實現迭代承諾方面更自信，處理質量差的工作所帶來的挫敗感減少了。從產品經理的角度來說，他們可以在與團隊共同制定的計劃中找到更多信心，對團隊面臨的風險有更多的瞭解，對與業務人員和其他干係人共事所必須的長遠計劃更有信心。最重要的是，團隊和產品經理有一個共同的理解，這對培養一個高效團隊是不可或缺的。

我們花了很多時間去思考，如何為開發團隊提供支援，確保他們可以開發出高質量的產品，但沒有花足夠的時間去思考，如何為產品經理提供支援，確保只有高質量、高價值的工作才能達到團隊。這是一個正確的前進方向，為什麼不今天就邁出這一步呢？

關於作者

Jacob Creech是一名敏捷教練兼培訓師。他是總部位於中國上海的Boost Agile的聯合創始人。這是一個為亞太地區的組織提供支援服務的敏捷培訓與輔導組織。他還是上海敏捷與精益創業使用者組的創始人。作為一名生活黑客狂熱分子，他總是在尋找（和建立）更快更高效的工作方式，而且他是生活全方位敏捷的支持者，其寫作和應用敏捷的領域已經同“乒乓球與攝影（Table Tennis and Photography）”一樣多樣化。