新任務不斷添加進來,Scrum團隊應該如何應對?

新任務不斷添加進來,Scrum團隊應該如何應對?

團隊至少會有協調計劃和控制時間的能力。他們能夠說:「我們將在接下來的迭代中完成這些事情」,並對這一情況有一定的合理預期。

我們看到很多Scrum文獻中描述了一類團隊——這類團隊進行迭代計劃並且避免計劃改變。

但是如果這些變化無法被排除在迭代計劃之外,團隊成員應該如何應對?

在這篇文章中,我們將針對兩種不同類型的團隊談談這個話題:

  1. 偶爾有中斷、但不多的團隊
  2. 高度中斷驅動的團隊

計劃要有安全緩衝邊界

許多敏捷團隊受益於在每個迭代中加入適量的安全區。總的來說,團隊不能假定,他們可以將所有的變化排除在迭代之外。例如,當他們計劃完成如下事情時,團隊可能想離開迭代範圍:

  1. 修復關鍵操作問題,比如伺服器斷電。
  2. 修復高危Bug。
  3. 做一級或二級技術支持。

有很多其它類似的例子。想想你自身所處的環境。試著為一個迭代中有價值的中斷設定一個較高的臨界值。當團隊有大量不會被打擾的專用時間時,團隊會做到最好。

為了適應這樣的工作,一個團隊需要做的就是在迭代計劃中留下一些緩衝時間。讓我們看看緩衝時間是如何運作的。

每個迭代需包含的三類時間

我認為每個迭代需要包含三類時間:企業管理消耗的時間,可計劃的時間和計劃外的時間。如圖1所示:

圖1

企業管理消耗指的是一些事情所佔用的時間,如全公司會議、郵件回復關於過去的項目、參加人力資源敏感性培訓等等。這些活動可能是必要的,但是在許多企業中,它們消耗了大量的時間。

我將Scrum會議(計劃會議、每日站會等)也放入企業管理消耗類別中。

可規劃的時間是迭代中的第二類,屬於集體的時間。

但是團隊不想將迭代的剩餘時間都被可計劃時間佔滿。團隊需確認,要離開迭代的計劃外時間的範圍。

計劃外的時間通常針對三件事情:

  1. 緊急事件。
  2. 那些比團隊原本認為的大得多的任務。
  3. 那些在迭代計劃會議中沒有想起來的任務。

適當的百分比

我經常被問到,對於這三類,團隊應該使用怎樣的百分比?我不能回答這個問題,但是我可以告訴你應該如何解決這個問題:

在每個迭代後,思考一下,團隊分配的計劃外時間和團隊需要的計劃外時間的匹配度。然後在下一個迭代中,將計劃外時間進行略微的上調或下調。對於這個,團隊永遠無法做到完美。

相對而言,這是一個平均數遊戲。團隊需要在平均水平上節省計劃外的工作所需的時間。因為在一些迭代中會出現較多的計劃外工作,一些迭代會出現較少的計劃外工作。

當較少的計劃外工作出現時,團隊需要提前完成他們的工作。他們要為更多計劃外工作的出現做準備。

當一個團隊被高度中斷驅動時,該怎麼做呢?

前面的建議在大多數敏捷團隊——那些只受適量干擾的團隊很有用。但是,一些團隊是高度中斷驅動的。

再一次,我拒絕給圖1中的每一個區域一個確定的百分比,但是,我在正在描述的情況中,「計劃外時間」的面試比實際顯示的大得多。

我實際上想說的是,這些案例中,計劃外的時間會變為這三個區域的主導地位。這些團隊是高度中斷驅動的。

這些團隊在他們的迭代中仍然需要包含計劃外時間。但是如果你處於一個高度中斷驅動的團隊中,通常你還需要考慮一些其它的事情。

首先,你可以調整迭代的長度。一種選擇是進行一個長期的迭代。提高迭代的長度有助於更好地預測中斷率,因為從一個迭代到另一個迭代,中斷率的差異不會很大。

來看看這個是如何起效的,想像你選擇了一個為期一年的迭代。(不要這樣做!)想像這樣長期的迭代很容易,團隊短期迭代面對的波動將會被洗掉。當然,今年(這次迭代)可能比去年(上個迭代)有更多的中斷,但這是一個很長的時期,團隊有時間從任何過度波動中恢復。

另一種選擇是進行短期的、一周的迭代,適應這種不確定性。在給定的時間內,團隊將無法向老闆保證「我們將完成這些」,但是,我發現,這是一個非常值得的折中方法。

其次,一個高度中斷驅動的團隊應該讓迭代計劃成為一個非常輕量級的活動。

迭代計劃中,團隊應該努力快速抓住一些事情,團隊成員認為這些事情可以在未來的一周內完成。此時,迭代計劃會對於很多團隊應該是一個非常小的努力,15分鐘或30分鐘。

為了說明這一點,想像策劃一個派對,並且想像一個極端,策劃一個婚禮。這是一個相當重要的派對計劃。想像另一個極端,計劃邀請一些朋友在今晚觀看電視上的大型遊戲。為了這個計劃,我需要去檢查冰箱裡面的啤酒、預定一些匹薩。這是派對計劃的不同層面。

一個高度中斷驅動的團隊的迭代計劃應該更像後者——快速、簡單並且能夠成功應對計劃外的任務出現。


推薦閱讀:

對Scrum的認識
從零開始—SCRUM在軟體產品研發過程中的成功實踐歷程
如何評價網路熱文《 Scrum 行還是不行 》?
Scrum敏捷實踐: Daily Scrum Meeting

TAG:項目管理 | 敏捷開發 | Scrum |