Scrum每日站會成了浪費時間的戰鬥會？

Scrum 是目前最流行的靈活軟體開發 實施架構。

Scrum 起源于軟體開發項目，但它适用于任何複雜的或是創新性的項目。

可能有的小夥伴并不熟悉 Scrum ，我們先看下 Scrum 中文網的描述：

Scrum 是一個用于 開發和維護複雜産品的架構 ，是一個增量的、疊代的 開發過程。在這個架構中，整個開發過程由若幹個短的疊代周期 組成，一個短的疊代周期稱為一個 Sprint（疊代），每個Sprint的建議長度是2到4周（網際網路産品研發可以使用1周的Sprint）。

Scrum 使用産品 Backlog（一個按照 商業價值排序 的 需求清單） 來管理産品的需求，清單條目的展現形式通常為使用者故事。Scrum 團隊總是先開發對客戶具有較高價值的需求。

為了挑選出 最高優先級的需求進行開發，Scrum 團隊在Sprint 計劃會議經過讨論、分析和估算，得到相應的任務清單，我們稱它為 Sprint Backlog。在每個Sprint（疊代）結束時，Scrum 團隊将遞交潛在可傳遞的産品增量。

Scrum 流程如下圖：

每日站會 是 Scrum 實踐中最具代表性的一個形式，也是我們今天讨論的話題。

每日站會的目的

Scrum 的團隊是一個 自組織 的團隊。每日站會，是團隊面對面溝通，和團隊自組織的展現，是 Scrum 過程，進行 每天的檢查和調整 的環節。以期達到：

1. 團隊商量決定誰做什麼（不能有上司人物指派），為當天做出一個計劃
2. 團隊溝通狀态，了解現狀，發現障礙
3. 團隊回顧昨天的工作，做調整，持續改進

基本規則

相信所有踐行過每日站會的人，都對如下規則印象深刻：

1. 會議最好在 15分鐘内 完成（或者每個人的時間不超過一分鐘）
2. 每個人回答三個問題：
   • 我昨天完成了什麼任務
   • 我今天打算做什麼任務
   • 我遇到了哪些障礙或困難
3. 同一時間隻能有一個人發言，任何跑題的讨論，需要被 Scrum Master 阻止

健康站會的效果

據說，一個有效執行 Scrum 的團隊是這樣的：

早上 scrum 站會前，團隊是安靜的。站會結束後，團隊很活躍，中午飯前慢慢沉寂下來。午飯後，團隊再度開始活躍，直到下午下班前又慢慢安靜下來。

我的實踐是怎麼演變成雞肋的

單看以上對健康站會的描述，我會以為，我曾經經曆過的 Scrum 實踐是非常有效的——完全符合上文的描述。但實際情況并非如此。

第一天站會

上司沒有說話，大家也都很沉默，低頭看地闆或者盯着白闆，面無表情。

上司說：“那就從小A開始吧！”

小A：“我昨天做的事情是：1，2，3；今天計劃做：4，5，6。但是我昨天下班前發現了一個 bug，這個 bug 會導緻我的 4，5，6 都沒有辦法開始。這個 bug 所在的部分之前是由小B 負責的，小B 今天把 bug 改好了，我的工作才能開始。”

小B：“怎麼可能呢？這部分之前都測過的，如果有這個 bug，測試根本不可能通過，我最近也沒動這部分代碼，怎麼可能會有 bug 呢？ 再說我今天計劃好了三件事情，時間排的滿滿的，根本沒時間解 bug。小C 這兩天在做某某功能，和這部分相關，是不是小C 做的新功能引起的？”

小C 馬上很警覺：“什麼bug？抱歉剛才沒聽仔細。”

小A 把 bug 現象又重新描述了一遍。

小C：“怎麼可能會抛出這個錯誤呢？你用的是什麼資料？哪個浏覽器，什麼版本？”

小A一一回答。

小C 做沉思狀：“你說的這個情況有點奇怪，我的代碼應該不會引起這個問題。你有沒有 debug？Log 上怎麼說？”

小A 剛要回答，上司擡手看了下表：“是這樣啊，我們 scrum 的目标是平均每人控制在1分鐘左右，現在光讨論小A 的問題已經用了6分鐘。接下來每個人隻說：昨天做了什麼，今天計劃做什麼，遇到了什麼問題。不過多談論細節，好吧！”

小A 作罷，上司說：“小B，該你了！”

小B 按照上司的要求，快速做了更新，包括自己遇到的困難。但是鑒于小A 的經驗，沒有人對小B 的困難做任何回應。

然後是 小C，小D，小E……

所有人更新完，上司又看了下表，“很好，我們今天的時間控制在了15分鐘，雖然比一人一分鐘多了點兒，總體還是不錯的。大家還有什麼問題嗎？”

小A：“那我剛才說的那個 bug 怎麼辦？那個問題不解決，我今天的工作沒法開展。”

上司：“你找小B，小C 讨論一下吧。發揮下大家的主觀能動性。”

小A喊：“小B，小C，你們能過來看一下嗎？”

小B：“等會兒，手頭有個急事兒處理一下。”

小C：“我去接個水噢。”

十分鐘後，小B 站在了小A 的電腦後，說：“到底是什麼問題，再重制下？”，小C 抱了個大水杯也站過來。

兩人在小A 身後，一會兒要求打開這個檔案，一會兒要點下那個按鈕……，大概一個小時後，倆人都搖着頭，表示這個問題很奇怪，跟自己那部分代碼都沒關系。最後語重心長地對小A 說：“你自己再看看吧，實在不行，找大牛幫你看看。”

小A 絕望地扭頭，正要喊大牛，卻看到他頭帶着耳機正和國外的同僚開會，隻好作罷……

第二天站會

仍然沉默，過了半分鐘，上司說：“還是從小A 開始吧。”

小A：“我昨天看了下那個 bug，找小B，小C讨論了，可是沒有頭緒，現在還在debug，任務4，5，6也沒辦法做。”

上司：“這樣下去，我們這個 Sprint 安排的工作風險很高啊。老D（大牛），你幫小A 看看吧。”

老D：“今天跟美國的架構師約了個會，昨天的問題還沒讨論完，今天還得繼續。這個不讨論完，我們下個 Sprint 的任務沒辦法安排啊。我盡量擠時間幫小A 看看吧。”

上司：“好的，辛苦你了老D。小A，你今天再花兩個小時 debug 問題，還找不出原因，就先去幫小B 或者小C 的忙吧。”

小A 低下頭：“好吧”。

一個星期後，Sprint 結束。

上司：“今天是 Sprint 最後一天，我剛看了下我們這個 Sprint 的進度，落後了很多。是什麼原因呢？大家分别說說，自己的任務完成情況。小A，還是你先說。”

小A……

你的破法

你參與過 Scrum 實踐嗎？

對每日站會有什麼想法？

如何破解上面的這種雞肋實踐？

歡迎在本文後留言，說出你的看法。