敏捷交付項目中的依賴關系管理

黃冬梅

【摘 要】在軟件的敏捷交付項目中，依賴關系是極其常見的，比如在業務需求的層面即定義好的工作流強制依賴，或是交付團隊的前后端依賴等。依賴關系的管理對于項目能否按時交付起著至關重要的作用，而一個未能按時向市場交付價值的軟件項目，就是一個失敗的項目。本文將從業務層面和組織層面分析，如何對交付項目中的強制依賴進行管理，降低交付風險。

【關鍵詞】敏捷交付；依賴關系；項目管理

依賴關系是什么？

把大象放進冰箱需要幾步？我們都知道，三步嘛。第一步，打開冰箱；第二步，把大象放進去；第三步，把冰箱關上。這三步是必須的，而且先后順序不能顛倒，否則事情就沒辦法完成。我們把這種活動之間的先后順序叫做依賴關系。

按照依賴的程度，依賴關系大概可以按如下方法分類：

1.可選依賴：一般人做西紅柿炒雞蛋會先炒雞蛋，而先炒西紅柿味道也不錯。這種可以顛倒，無傷大雅的依賴關系，就是可選依賴。

2.強制依賴：蓋房子必須先蓋第一層才能蓋第二層，這種固有的，沒辦法避免的先后順序關系，叫做強制依賴。

可選依賴一般比較容易處理，而強制依賴往往考驗一個人或一個團隊的組織應變能力和管理能力。在敏捷交付項目中，依賴關系幾乎是無處不在。比如業務層面，一個審批流中，一方如果沒有提交成功，另一方就沒有辦法審核。比如組織層面，在前后端分離的團隊中，前端的功能交付和后端是強依賴關系，后端API沒有準備好，前端往往不能開始開發和測試。依賴關系對項目管理來說，影響最大的就是交付時間。而一個沒辦法按時向用戶交付價值的項目，就是一個失敗的項目。所以，依賴關系的管理對于項目的成功與否至關重要。那么，在敏捷項目中，業務層面和組織層面的強制依賴關系，我們該如何處理呢？

一、業務層面強制依賴關系的處理及案例

筆者在經歷的第一個敏捷交付項目就遇到了業務強制依賴的情況。這是一個澳洲電信的項目，團隊收到一個修改流量套餐的需求，大致工作流和設計如下：

這一工作流程中的各個步驟環環相扣，頁面之間層層遞進，沒辦法省略其中任何一步，是強依賴關系。而這個功能的開發工作量相對比較大，放在一個用戶故事中很有可能沒辦法在一個迭代中完成。那么在依賴關系無法避免的情況下，如何盡量減少依賴，讓幾個團隊成員同時工作，在一個迭代里完成這一功能的開發呢？

方法一： 通過合適的故事卡拆分，將依賴降到最低

考驗業務分析師（Business Analyst）技能的時候到了。很多人都知道，用戶故事的拆分需要遵循INVEST原則，其中I代表的就是Independent（獨立的）， 即盡可能的減少各故事卡之間的依賴關系，讓其相互獨立。故事卡的拆分方式有很多種，筆者經過慎重思考選擇了下圖的拆分方法。即，將頁面之間的強依賴關系抽離出來，體現在故事卡1、2和3中。當3完成以后，故事卡4和5就相互獨立開來，互不影響了。這樣能一定程度上減少該功能的開發時間，盡早交付其業務價值。

方法二： 將有依賴的故事卡按順序完成的時間考慮到迭代計劃中

在新項目啟動，或團隊接到新的業務需求時，往往會需要進行工作量估算，再按照團隊速度大概估計需要多少個迭代來完成，即排迭代計劃。排迭代計劃有個簡單粗暴的公式，即總故事點數/團隊每個迭代能完成的故事點數（團隊速度）=所需迭代數，這是理想情況。那如果業務需求內部有非常強的依賴關系，就要另當別論了。

參考項目管理中的關鍵路徑法，相互依賴的故事卡從第一張卡開始到最后一張卡結束的時間，將影響整個功能何時交付。例如，上面案例中從用戶故事1開始到用戶故事4（關鍵路徑）的所需時間如果超過一個迭代，盡管他們的故事點數總和看上去可以完成，在進行迭代計劃時，也需特別考慮，延續到下個迭代去完成。

二、組織層面強制依賴關系的處理及案例

敏捷交付崇尚面對面溝通的全功能團隊，即從需求到設計，從開發到測試的角色，都一個團隊，所有問題當面溝通解決。好處之一就是從組織層面減少依賴關系，提高交付效率。

理想很豐滿，而現實往往特別骨感。我們常常碰到前后端團隊完全分離，而且不在一個國家的項目，前端開發完強依賴于后端API的開發進度。也有的項目UX設計師和團隊不在一起，而且設計進度跟不上開發進度，團隊每天猜測UX會如何設計，然后苦等UX上線催進度。。。

筆者最近參與的一個電信施工類APP項目就是前后端團隊完全分離的，產品負責人在歐洲，客戶方的后端開發在加拿大，需求分析，交互設計以及前端開發在中國。項目在需求分析，設計確認上強依賴于產品負責人的輸入，而前端開發強依賴于后端開發的進度，而由于時差的關系，每天只能在有限的一兩個小時內和對方遠程溝通，未溝通到的點只能等到第二天。開發團隊每天不是正在被阻礙，就是在擔心即將被阻礙。這些依賴關系都太痛了！那可以如何解決呢？

方法一： 識別關鍵活動，提前規劃時間節點

以某一功能需求的實現為例，從需求到設計，從前端到后端，可謂是端到端的強依賴。任何一個環節進展受阻，都會影響下游工作的按時完成，給功能的按時交付帶來風險。為了更好的把握風險，需要將全流程中的關鍵活動識別出來，規劃出時間節點，在交付過程中不斷審查每個時間節點下的活動完成情況。

例如，某個功能需求需要在12月15日上線，那么我們可以根據各個前期活動的工作量倒推出用戶驗收測試需要完成的時間，后端和前端開發需要完成的時間等等，并可視化出來，作為參照來衡量目前的進度是否有風險。

方法二： 可視化具體的依賴關系，及時跟進

對于關鍵活動，我們需要把握時間節點，而對于具體問題，則可以進行工作拆分，將依賴關系一一對應，并可視化。

例如，對于前端開發依賴于后端API進展的這一問題，可以通過工作的拆分，將后端API和前端用戶故事的依賴關系梳理出來，并面向全體成員可視化。按照依賴的嚴重程度，識別出優先級，優先級解決影響最大的依賴鏈，并實時跟進依賴源頭的進展，比如在每日站會中追蹤后端開發的工作情況。

方法三：識別和解決問題風險，適時向上升級

如果識別到關鍵活動不能按時完成，或后端進展不理想，前端開發即將被阻礙的風險，則需要及時明確出來，找到解決方案或推動風險的解決。而如果效果不理解，則需要適時向上升級，尋求更高層面的幫助。

例如，通過每日站會來明確風險，尋求幫助；部分敏捷項目會有Scrum of Scrums站會， 就是產品負責人，技術負責人，交付負責人等關鍵角色一起開的站立會，這是一個升級問題和風險的最佳場合。當然也可以通過郵件，slack群聊等各類方式將風險和問題提出來，群策群力，或者升級給各個負責人，依靠更強大的力量來解決。

三、結語

你也許會發現，傳統項目管理的很多方法論，比如關鍵鏈和時間節點管理，還有敏捷管理中提倡的可視化等，在處理依賴關系上都非常好用。我常常說，不管是白貓還是黑貓，能捉到老鼠就是好貓。靈活運用各類方法，管理好依賴關系，你的敏捷交付項目就成功了一半了啦。

【參考文獻】

[1] Jim Highsmith. Agile Project Management[M]. Qinghua Pubshiing House， 2005，7.

[2] Fowler， Martin， and Jim Highsmith. The Agile Manifesto. Soft-ware Development 9[C]. No. 8 （August 2001）： 28-32

[3] Project Management Institute. A Guide to the Project Management Body of Knowledge[R]. 2000 ed. New Square. PA： Project Management Institute， 2000.