當團隊的才華無法支撐Scrum Master的夢想

1

「敏捷是靠人的，短期之內人是不能快速成長的。」

「預算是固定的，沒有辦法協調更優質的資源。」

這種觀點並不鮮見。

不過出發點是以限制為界限，限制了思考。因此能夠得到的解決方案也就有限。

套用一個流行的句式，這種問題就是團隊的才華無法支撐Scrum Master的夢想了。那麼Scrum Master的夢想是什麼？團隊的才華為什麼無法支撐這些夢想的時候，又該如何做呢？

首先，我們來看敏捷宣言。Scrum Master的夢想不管其表現形式，萬變不離其宗的還是這幾句敏捷宣言。

而團隊如果無法滿足上面的要求，其表現形式往往是：

· 估算需要的時間比預期要長

· 變更發生的時候表現抵觸

· 和客戶的溝通不夠及時有效

· 問題發現的時機比較靠後

· 質量問題層出不窮

· 進度比預期慢了

· 需求理解不到位

等等，不一而足。

那麼是否這些問題真的是無法短期之內奏效的呢？有沒有能夠立竿見影的方法來解決這些問題呢？

如果目光集中在這些問題上，似乎得出的結論就是團隊不夠優秀，所以，無法滿足Scrum Master的期望，而短期之內通過培訓、輔導是無法達到迅速提升的。畢竟編程功底這事兒是個日積月累的過程。但是如果能夠跳出這個框框限制，那麼就可以發現一片新的天地，豁然開朗。

就我的經驗來看，下面幾個問題可能是常見的因為上述問題的原因，而且是無需通過大量培訓、輔導或者訓練就能夠奏效的。這些也是經過實踐檢驗的。

2

缺少並行作業

【現狀】

開發必須要等需求說明到很詳細的程度才能夠開始，否則未來發生變更的可能性非常大，而團隊比較抵觸。

因此， 需求和開發之間採用的是瀑布式作業，仍然是上下游關係，缺少並行作業機制。

需求描述如果是用戶故事，對於開發來說，這是一個open命題，無法接受。開發需要就此用戶故事的的明確的界面設計，異常處理的描述才能夠開始。也不能在只有少量用戶故事的情況下就開始，需要整體圖，才能理清各個模塊以及各個實體之間的關係。這是一個重要的前提。

因此PO提出來的需求形式，最終仍然是呈現為Specification差不多的感覺的文檔。

【問題分析】

開發需要的並不是一份完整的文檔描述，而是更清晰的邏輯關係。最好是能夠指導開發編碼的文檔形式。這個描述需要保證全面性、可映射性（可以轉化為代碼的能力）、以及便捷性（能夠很容易的描述出來）。

【可行的方案】

決策矩陣

決策矩陣是一種用來幫助開發團隊能夠更好的梳理需求的各種條件組合的一個工具。它容易描畫、覆蓋全面、可以直接映射為代碼。可以有效地加速從需求轉化為代碼的過程。

比如，有這樣一個需求（我們不討論其合理性）。

· 作為公司的一員，我可以對其他同事的行為進行拍照，並且增加描述從而提起一個舉報。

· 作為一個被舉報人，我可以申訴，證明自己的清白。

· 作為一個被舉報人，我可以接受舉報。如果接受舉報，則扣分，而舉報人加分。

· 作為一個被舉報人的上司，如果員工申訴，我可以進行二次申訴，證明自己員工的無辜。

· 作為一個被舉報人的上司，如果員工申訴，我可以接受舉報，如果接受舉報，則扣分，而舉報人加分。

· 作為審理委員會，如果接到二次申訴，我們有權判斷該舉報是否被採納。對於採納的情形，舉報者有獎勵，被舉報者有懲罰。對於被否定的情況，舉報者有懲罰，被舉報者不做懲罰，也沒有獎勵。

這裡面有若干個角色，有若干個流程步驟。傳統的方式是描述為流程圖。讓開發團隊根據流程圖開發，然而，流程圖當中並沒有細節，比如獎勵多少分，扣掉多少分。而且對於判定條件，什麼時候由什麼人來進行什麼操作也是需要詳細的描述才能夠進行的。這是因為流程圖給開發工程師帶來的信息就是這樣的，引導了開發工程師的思考往這個方向走。

因此開發工程師編程的時候按照需求描述的方式書寫代碼，採用了大量的if-else來處理整個流程，代碼複雜度也就自然上升了很多。

而決策矩陣則給開發工程師完全不同的信息。下圖是就上述需求的決策矩陣。

上述矩陣，左側為該業務中的所有狀態，頂部為所有的操作按鈕。中間的矩陣部分是，哪個按鈕可以操作，哪個按鈕不可以操作。具體的操作後的動作也在矩陣中進行了描述。繪製這樣一個矩陣只要幾分鐘就可以了。而它覆蓋了所有的情形，流程圖的形式會有一個重要的遺漏，就是那些業務描述中「不可能發生的」情況。

在實際業務中，還有一種情況，就是並發操作。當一個人打開了他可以操作的數據之後，離開座位，這時候他的瀏覽器認為這個數據是當前的狀態A。另外一個人在自己的電腦上也打開了同一條數據，然後進行了某個操作，這時候數據變成了狀態B。然後第一個人回來之後接著操作，上述矩陣中的「-」部分就在這種情況下出現了。而如果採用流程圖的描述形式，由於隱藏了這部分的信息。代碼中的處理就會有遺漏，從而產生了bug，在測試階段中暴露出來。這是常見的問題之一。

上述決策矩陣採用了過去式描述各種狀態，這樣讀者也不會因此而產生歧義。

那麼決策矩陣是如何和代碼映射的呢？

簡單的說：每個狀態映射為一個類，每個按鈕操作映射為類的一個方法。

比如上述的矩陣就可以作如下映射：

默認的處理都是不能操作，只有少數能夠操作的部分才有對應的代碼。剩下的都交給基類來處理就可以了。然後每個按鈕配套一個is~Available方法，比如：isAppealAvailable，這樣該按鈕是否顯示，點擊之後是否能夠處理，就由對應的類做出判斷和處理。

由於上述例子中需要處理的部分很少，因此這段代碼也就個把小時之內可以完成，而且它的可變更性、可擴展性、可讀性以及代碼質量本身都遠高於基於流程圖書寫的if-else式的代碼。

3

擁抱變化能力不足

當上述代碼寫完之後，PO提出，按鈕是否可以用是和角色掛鉤的，不是每個角色都可以看到該按鈕的。基於if-else風格的代碼需要遍歷所有的按鈕，每個都要書寫一遍條件，包括：按鈕的顯示部分，按鈕的提交部分的處理。萬一有個遺漏就是Bug。而且這種複雜業務，會很容易有遺漏。

而採用決策矩陣為依據的代碼需要增加角色判定的時候，只要在每個is~Available方法中補充對應的條件即可。

4

有太多的等待

正如前文所說，由於需求的描述方式的差異，採用流程圖的描述需要等待很久才可以開始理解，理解透徹了才能夠開始編碼。而採用決策矩陣的形式，無需等待，可以立即編寫，每個方法的長度都不超過10行，因此，也不存在理解上的障礙。

引入決策矩陣之後，仍然是原來的團隊，沒有做深度技能提升，團隊的生產率卻達到提升了，代碼質量也得到了顯著的改善，代碼的維護成本也大幅度縮減了。

資深敏捷教練王洪亮的《高級代碼訓練營》，通過實戰的方式，經過一個虛擬項目，幫助團隊更好的梳理需求，加快交付，提高質量，還有更多的實用工具助力敏捷團隊迅速成長。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！