敏捷開發生態系統系列之三：計劃跟蹤II（需求優先順序排序-迭代期內無變更-團隊承諾）

這是敏捷生態系統系列的第三篇（之一，之二，之三，之四，之五）。

產品負責人PO與團隊的互動一直是一個難題。典型的問題在於：敏捷開發倡導“迭代期內無變更”以換取“團隊承諾”，而實際上產品負責人卻會不斷地來提變更，打亂開發計划了。我們應該怎麼辦呢？產品負責人說“敏捷就是擁抱變化，我現在來提變化了，你們卻關門了。”團隊說“如果你總是變，下次我們怎麼給你承諾。”

敏捷開發中的計劃跟蹤生態II大致如此（黑體字即圖片中的元素）：

產品負責人（PO）與團隊的正確互動是自組織團隊正常運轉的核心機制之一。

產品負責人的權利是統一管理和講解需求以及需求優先順序排序，而義務則是接受Team Dev的估算，並承諾迭代期內不變更。

團隊的權利在於開發人員自己估算，而義務則是接受產品負責人所設定的需求內容、實現標準、優先順序排序，並對自己的估算做出團隊承諾，這種承諾會造成整個團隊受到激勵。

產品負責人不能干預團隊的估算，卻可以挑戰估算。挑戰估算可以通過對比兩個團隊處理同類任務、對比以往同類任務與本次任務等方式進行。團隊的榮譽感會令團隊產生團隊間的同行壓力（與其他團隊及與自己的過去相比），並進而產生受激勵的個體。

作為自組織團隊，產品負責人與團隊互相沒有領導關係，卻通過分權與承諾管理，使得兩者互相管理，從而產生更高的工作效率。

需求優先順序排序-迭代期內無變更-團隊承諾是這個生態的主線之一。

讓我們重新看一下前面變與不變的例子。

簡單粗暴的方法包括“一個強制性的變更或不變更制度”。即在高層領導的支援下（如果他們不支援，大家就放棄敏捷開發，你們說怎麼辦就怎麼辦，但別再提敏捷開發了！），團隊堅持每個迭代都不變更。這個聽起來很簡單，但實際操作是有難度的。畢竟變更經常來自客戶，團隊怕產品負責人，所以搬出高層領導；產品負責人怕高層領導，會搬出客戶。

另一種細膩一點的方法是制定一個“何為需求變更何為需求細化”的指南。畢竟有時候提前想的是一件事情，但具體做的時候才發現應該做成另外一個樣子。難道大家真的應該二話不說先把錯誤的東西做出來，到下一個迭代再變更？這不是純粹和自己較勁麼。所以興許我們不會把任務扔掉，但是卻可以把任務的描述改動一下，作為“細化”來接受。這種指南有其現實意義，但萬勿當作法律條文來辦，因為很快就會發現有處於模糊狀態的東西會引發爭議。

其實終極解決方案，是順著圖中的線條向下看：團隊承諾-迭代期內無變更-需求優先順序排序。最後一個才是重點。

有幾種原因會導致迭代期內變更，一種是發現了緊急的需求，一種是發現了更重要的需求，另外一種是發現需求和以前想的不一樣。

第一種在MoSCoW中提到過，可以通過優先順序分級的方法來容納之；另外事先商定只有比如70%的時間可用，也可提供額外時間來處理，這裡不多說了。

另外兩種，則都是與優先順序排序工作不到位有關的變更。

1. “來了更重要的需求”其實等同於“我們之前在做不重要的需求”。

儘管人們難以準確預測哪些需求真的最重要，但當我們從眾多需求中挑選了極其有限的自然也是極其重要的需求放在迭代中，卻能在短短的一個月內跳出一個更重要的需求（這個需求多半不在已知的“眾多需求”中），就應該意識到之前的需求收集和排序工作肯定出了問題。原因或許是我們挑選了不稱職的產品負責人，或產品負責人採用了錯誤的需求分析方法，或產品負責人工作在極端苛刻的環境中（比如客戶拒絕透露需求）等等。這些問題看似可怕，但一旦擺上檯面，解決它們比不知道原因地解決“迭代期內到底變更還是不變更”要容易得多。因為事關細節和具體環境，以後會有博文解決（部分已經計劃在《火星人敏捷開發手冊》的章節中）。

2. “需求和以前想的不一樣”聽起來是一種無法避免的問題，但其實我們有很多工作可做。

儘管人們難以準確預測所有需求的實際內容，但卻可以就部分內容做深入瞭解。具體實踐包括：

• 在縱觀大局的同時，產品負責人應時刻注意最重要的需求是否弄清楚了，應多就這些問題與客戶探討，防止被迫講不清楚的需求發放給團隊的情況。
• 應建立故事群的概念（在之一中有提到），即當零散的需求極難與客戶溝通和獲得反饋的時候，應就一組故事與客戶回函。這樣不容易遺漏故事，也不容易對故事的排序疑惑，因為故事之間有可比性和依賴性。客戶可能很難決定“一周節目單”重要還是“地區訪問碼”重要，但是卻很容易判斷“一周節目單”比“當月節目單”重要。

在具體工作時，團隊不應該徹底放棄對優先順序排序工作的思考，而是應該配合產品負責人做好這個工作，尤其是團隊中高層次的對業務有所瞭解的人。

與之相對應的，是產品負責人也不應該徹底放棄對計劃工作的思考，這就是下一篇將描述的Team Dev自己估算-PO挑戰估算-同行壓力的生態線。

 

 點擊下載免費的敏捷開發教材：《火星人敏捷開發手冊》