每日站會已經成爲許多團隊的常見儀式,特別是在敏捷軟件開發中。然而,有許多微妙的細節能夠幫助咱們區分是在有效的開會仍是在浪費時間。html
每日站會(也稱爲「每日Scrum」、「每日小會」、「早晨點名」等等)描述起來很簡單:java
整個團隊天天都會開會快速更新狀態。站起來是爲了保持會議的簡短。
就是這樣。web
但這個簡短的定義並無真正告訴你經過哪些細節來區分團隊是在有效的開會仍是在浪費時間。segmentfault
那你怎麼能知道呢?安全
對於有經驗的從業者來講,當站會出現問題時,他們會本能地知道該如何調整來解決這個問題。架構
可是對於新手來講,當進展不順時,他們不太可能知道該怎麼作……並且更有可能的是,在沒有外在幫助的狀況下,他們會乾脆徹底放棄這一實踐。echarts
若是出現這種狀況那將是很不幸的,由於運行良好的站會會給團隊帶來巨大的價值。less
爲了解決這個問題,重要的是要明確每日站會經常使用模式的收益和問題。這些每日站會的模式能夠幫助經驗不足的從業者,也能夠提醒經驗豐富的從業者關注他們直覺背後的緣由。ide
隨着音樂的想起,就像巴甫洛夫的鈴聲同樣,團隊會在沒有任何額外提示的狀況下起身走到貼滿卡片的看板前站好。這首特定的歌曲會在天天早上同一時間循環播放。一些人將卡片移動到工做流的正確位置,或者在不一樣顏色的便利貼上貼上附加說明。一些對項目感興趣的項目組以外的人也在這裏徘徊,查看工做的進展狀況。wordpress
注意到你們都在看板牆邊準備就緒,團隊負責人啓動了團隊以前購買的一個大屏計時器:他們對每日站會實際花費的時間很感興趣。
一個團隊成員站出來談論看板最右側最靠近部署點的卡片。他的部署腳本仍然存在一些問題。另外一個小組成員說她能夠幫助解決這個問題。人們按照從右到左,從上到下的順序闡述每一個工做項的狀況,若是其餘人能幫助解決障礙他們就會自行發言。另外一邊,團隊負責人正在改進板上記錄提出的障礙。
有一次,你們在探討如何處理一個特定問題時討論的時間略長。注意到有一個停頓,團隊負責人正準備舉起手指打斷他們……就在這以前,其中一個團隊成員建議他們應該線下再討論。
不久以後,全部的卡片都被覆蓋到了,團隊負責人問還有沒有人要補充。有人提出她有一個關於新功能的有趣想法,該想法可能會使一些計劃中的需求變得更好。這激起了老是試圖參加站會的產品經理的興趣,他們都贊成在會後繼續討論這個問題。
當團隊開始進行傳統的結束儀式時,你們齊喊口號:「1…2…3…精益求精!」團隊負責人翻了個白眼,這不是他的主意,但他不得不認可,這讓站會在愉快中結束。
人們分散開並開始討論提出的各類事情,包括障礙、新想法以及關於某些工做項的問題。
當一羣人試圖做爲一個團隊一塊兒工做時,每日站會是一種針對一系列特定問題的重複性解決方案。
每日站會是一種按期同步的機制,以便團隊…
每日站會的模式經過回答如下問題來給出:
如下人員和表明均可出席:其餘領域(如市場、生產支持、高管、培訓師等)的人、但願瞭解項目狀態和進展的人、在必要時能夠貢獻出本身一份力量的人。在多個會議和報告中傳達項目狀態須要大量的重複工做。
所以
用每日站會來取代部分或所有會議和報告。任何直接參與或想了解項目平常運做的人都應該參加這惟一報告項目狀態的會議。
可是
若是有人以前沒有參加過每日站會,他們可能不知道會議的流程,他們可能會作出一些擾亂站會秩序的行爲。這能夠經過提早告知新參與者和觀察員預期的行爲規範來解決。
並不是全部形式的報告內容都會(也不該該)被站會所涵蓋。例如,項目的總體進展能夠經過一個大型可視化圖表[1]進行溝通,這個圖表能夠是燃盡圖[1]、燃起圖、累積流圖等等。
也被稱爲:以故事爲中心的站會
若是故事對項目相當重要,它們就應該在站會上發言。
——Brian Marick, Latour 3: Anthrax and standups[2]
人們有時會過分專一於跑者,而忽略了指揮棒。也就是說,每一個人都很忙,但工做項卻沒有取得應有的進展。
所以
與其把每日站會視爲是人的儀式,不如把它視爲是工做項(例如,敏捷開發中經常使用的用戶故事)的儀式,人們參會只是爲了替工做項發言……由於很顯然工做項是不會說話的。
昨天-今天-障礙的問題仍然能夠使用,但會從工做項而不是人的視角來使用。這也意味着可能並非每一個人都會發言,咱們沒有義務說任何與工做進展無關的事。
由於有了更清晰的焦點,人們才更有可能在沒有提示的狀況下提出障礙,並登記和解決障礙。
可是
不要求全部人都發言可能會掩蓋那些害羞或不肯意說話的人的問題[3]。這在以工做項爲重心的狀況下更難發現。
也被稱爲:三個問題
有些人很健談,而且傾向於在講故事的時候發散不少東西。還有些人在聽到一個問題後就想當即解決這些問題。時間過長的會議每每會致使你們注意力不集中,與長時間討論沒有直接關係的參與者每每就會分心。
所以
能夠用如下的格式來組織每日站會:
這些是知足每日站會目標的最小子集的問題。其餘的討論話題(如討論設計、閒聊等)應該推遲到會議結束後進行。
Olve Maudal建議,這些問題的順序應該倒過來,以突出問題的重要性:
- 哪些障礙阻礙了你的進展?
- 你今天在作什麼?
- 從昨天開始你完成了什麼?
——Olve Maudal,每日站會-也許第三個問題應該先說?[4]
Lasse Koskela以另外一種形式提出了這些問題,他強調團隊成員不該該向領導彙報:
每一個團隊成員依次向他的隊友提供3條信息:
- 自昨天會議以來我所作的事情
- 我今天要完成的事情
- 我須要別人幫忙解決的障礙
——Lasse Koskela,關於Scrum和三個問題的詛咒[5]
Jonathan Rasmussen提供了不一樣的措辭,以改變站會的態勢:
- 你昨天爲改變世界作了些什麼?
- 你今天打算如何將其完成?
- 你打算如何清除那些擋在前進道路上的障礙?
回答這類問題會徹底改變站會的態勢。之前你只是站在那裏並介紹一些近況,而如今是向全世界宣佈你的意圖。
——Jonathan Rasmussen,《敏捷武士》[6]
也有一些團隊增長了額外的問題:
- 你昨天完成了什麼?
- 你今天承諾作什麼?
- 你的阻礙/障礙是什麼?
- 你昨天發現了什麼代碼壞味道/缺失單元測試/…?
- 你昨天對代碼作了什麼改進?
——Mark Levison,每日站會的變量[9]
可是
每日站會問題的結構只是手段,在站會上同步進度、問題、風險、障礙等項目信息纔是目的。若是經過這些結構化的問題咱們收集不到想要的信息,那麼就要考慮換一個問題清單了。隨着團隊的成熟,你可能會發現你想調整這些問題的結構,這也反映了這種模式是如何演進的。
更嚴重的問題是,昨天-今天-障礙可能會形成對我的承諾的過多關注,而不是關注正確的事情……這個問題能夠參考「走板」。
也被稱爲:阻塞板、障礙板、改善報(Kaizen Newspaper)
在站會中提出的障礙沒有被及時解決或以其餘方式解決。
所以
將提出的障礙張貼到改進板上。這是一個公開可見的白板或圖表,用於記錄已提出的障礙,並跟蹤其解決進度。改進板能夠在站會以外進行更新,並做爲一種更直接、也許對抗更少的方式來初步提出障礙。一個常見的錯誤是描述障礙的字寫得不夠大,致使人們沒法從遠處閱讀它。
把一個問題寫下來並明確地認可它,這個行爲是減小冗長討論的很是簡單、可靠的方法。所以,即便不是每一個人都贊成某個特定事項是一個障礙,也值得把它簡單地記錄下來,以便在會後討論。
在每一個提出的障礙上能夠包括一個發生次數的統計,這樣能夠突出哪些問題一般更重要,須要首先處理。
改進板的設計能夠有幾種不一樣的方式。例如,一個板的結構以下:
問題 | 計數 | 抑制 | 對策 | 狀態 |
---|---|---|---|---|
問題名稱 | 持續發生的次數 | 短時間解決方案 | 基於根因分析的長期解決方案 | 計劃(Plan)-執行(Do)-檢查(Check)-行動(Action) |
另外一種風格更像是一個任務板:
待處理 | 處理中 | 已完成 |
---|---|---|
索引卡表明提出的障礙 | 當咱們開始處理障礙時,它們會移到這裏 | 當咱們解決了障礙時,它們會移到這 |
可是
若是在改進板上提出了太多團隊沒法解決的障礙,那麼改進板就有可能演變成一個抱怨板。
在站會開始前,與會者須要知道誰應該先發言。由主持人決定誰應該先發言是一種微妙的、但確定是反自組織的模式。團隊應該知道誰先發言,而無需任何干預。
所以
贊成最後到達的人最早發言,這是一個簡單的規則,同時它還有一個好處,就是鼓勵人們準時出席站會。
可是
最後到達的人也多是最沒有準備好開始會議的人。
在站會期間,與會者須要知道接下來應該由誰發言。由主持人決定誰下一個發言是一種微妙的、但確定是反自組織的模式。團隊應該知道下一個發言的是誰,而不須要干預。
所以
使用一個預先肯定的簡單規則(如順序發言)來肯定下一個發言的人,順序是順時針仍是逆時針並不重要,重要的是由團隊主持會議,而不是由主持人或經理主持。
在簡單的、可預測的排序機制下(如順序發言),與會者很容易忽略其餘人的發言,直到接近輪到本身時纔會集中注意力。在沒有輪到本身時,他們可能會想一些其它事情,而不是注意別人在說什麼。
所以
引入一個不可預測的排序機制,好比使用發言令牌(好比,一個球)來決定接下來誰應該發言。有了發言令牌,也就簡化了決定誰先發言的過程,由於這將是碰巧拿到令牌的人(或他/她將令牌扔給的第一我的)。
傳遞令牌爲每日站會帶來了一些樂趣,同時避免了你們注意力可能不集中的問題。
我第一次瞭解到這種模式是在我和Simon Stewart合做的一個項目中。咱們當時用的是一個小雜耍球,但幾乎任何東西均可以用做令牌。其餘團隊也用過橄欖球,甚至是毛絨玩具。
可是
對於較大的團隊,可能很難記住誰已經發言了。在這種狀況下,繼續使用像順序發言這樣的簡單機制可能會更容易。
根據組織甚至團隊的文化,拿一個球傳來傳去看起來可能不太專業,而且可能會讓人對每日站會這個基本儀式產生沒必要要的負面見解。
在站會期間,與會者須要知道誰應該先發言,以後誰應該接着發言。由主持人決定誰應該發言是一種微妙的、但確定是反自組織的模式。團隊可能並不熱衷於傳遞令牌,由於一般他們手中拿着咖啡杯。
所以
可讓每一個團隊成員拿一張卡片來決定發言的順序[10]。想象一下,有一疊卡片,每張卡片上都有一個數字,當每一個團隊成員來到會場時,他們能夠選擇一張卡片,而後告訴他們以什麼順序發言。
又稱做爲:走牆
站會讓每一個人都忙碌起來。走板使每一個人都集中在最重要的事情上。
——Bret Pettichord經過推特發送
傳統形式的另外一個問題是,任務或工做流的討論並不連貫;相反,每一個主題都會隨着團隊成員發言的順序而短暫地出現。這可能令人很難分辨出到底發生了什麼。
——Dave Nicolette,每日站會的另外一種形式[11]
人們更專一於繁忙的工做,而不是真正的工做進展,因此這促使你切換到了讓工做項出席而不是人出席的模式。然而,即便採用了這種專一於工做項的站會,在使用了諸如順序發言或傳遞令牌等排序機制時,仍然很難理解項目的狀態如何。
所以
走板,即經過走過可視化看板/任務版上的每一個工做項來組織站會。
大多數敏捷和精益團隊都會使用一個可視化管理系統來展現正在處理的工做。對於敏捷軟件開發來講,這個可視化管理系統可能被稱爲「任務板」、「故事牆」或「看板」。這些板將展現工做項將流轉的流程。進展一般是經過在板上移動卡片來表示。理想狀況下,工做項的上下位置將表示優先級。
有了這個板,參加站會的人會從流程結束到流程開始(例如,從右到左)以及從最高優先級到最低優先級(例如,從上到下)的順序檢查工做項的進度。你甚至能夠在板上明確指出應該使用什麼順序。
Pawel Brodzinski提出了一個默認順序[12]:
可是
顯然,擁有一個看板/任務板是一個先決條件,但這並非全部的團隊都會有的。在這種狀況下,逐人發言的模式會更合適。
若是不採用輪流主持或其餘自組織的模式,走板更容易走向向領導彙報的泥潭。
在工做現場開會,而不是在會議室。
——Marc Graban,Everett診所的每日聚會視頻[13]
工做場全部許多關於正在發生的事情的記憶觸發器。
咱們也不但願這種每日會議須要大量的精力來查找、預約並走到會議室。
所以
在工做現場開會,而不是在會議室。若是你有一個「故事牆」或「看板」,最好就在它前面開會。
可是
在「故事牆」或「看板」前面開會,會議的噪聲可能會打擾到附近的人。這一般代表工做空間的設計是有問題的,但必須認可這個問題的存在。
咱們但願團隊對會議有一種主人翁的感受。咱們也但願感興趣的利益相關者可以前來觀看站會,以免安排另外一個相似的狀態同步會議,若是容許某個團隊成員隨意推遲時間或改變地點,這些好處都將難以實現。
所以
讓團隊達成一致並在同一地點、同一時間舉行每日站會。不要等待遲到者,包括架構師和經理。會議是爲整個團隊開的,而不是爲某個特定人開的。若是你使用站會做爲一天工做的開始,這一點尤爲重要。
一些更嚴格的團隊可能會對遲到者處以罰款。我傾向於對任何形式的懲罰機制保持謹慎,而是更喜歡把這些事情拿出來公開討論。
可是
同一地點,同一時間並非盲目地僵化。這裏要重點強調的是,開始時間要基本一致,從新安排時間的狀況應該會不多。若是須要常常從新安排會議時間,這多是一個跡象,代表開始時間應該調整。若是一個特定的地點對每一個人來講都很不方便,這可能也是一個跡象,代表這個地點應該調整。
每日站會提供了對未決問題的關注和覺察。若是站會發生在一天的晚些時候,這種關注和覺察就會被浪費掉。
所以
使用站會做爲一天工做的開始。因爲不少公司採用彈性工做時間,並非每一個團隊成員都會在同一時間趕到工做地點,應對「彈性工做時間」的一個常見作法是使用一組核心工做時間,即在某個時間段內團隊成員是都在公司的(例如,中午12點到下午4點)。站會開始時間應該是在這組核心工做時間的開始。一樣,若是團隊成員因我的緣由常常須要晚一點到達(例如,須要送孩子上學),那麼開始時間應該設定在一個讓全部人都能參加的時間。
可是
在站會以前,人們可能會傾向於不處理任何與項目相關的任務。若是站會很晚纔開始,工做時間的浪費可能就很嚴重。通常狀況下,人們可能只會用來作一些檢查電子郵件、填寫時間表等工做。但將站立做爲「一天的開始」,並將其安排在一天的晚些時候,這個實踐或許值得研究一下。
站會每每做爲設定一天工做焦點的儀式,特別是若是你使用站會做爲一天工做的開始。正由於如此,團隊成員每每在站會以前不會去作開發工做。當站會開始較晚時,這種傾向可能會對生產力產生重大影響。
所以
不要使用站會做爲一天工做的開始。不要把每日站會安排在早晨舉行,這樣就不會在心理上把它當成一天的開始。
可是
若是每日站會不是一天的開始,那麼它就不能再用做在一天開始時設置團隊工做焦點的共同的儀式了。根據團隊的不一樣,這個代價可能抵不上效率的明顯提升。
當有不少項目使用站會時,可能會有多個站會同時舉行。對多個項目都感興趣的觀察者可能但願改變站會時間,以便他們都可以參加。這是有問題的,由於若是觀察者能夠強迫站會調整成他/她的時間表,這會危及團隊的主人翁意識。儘管如此,在決定何時舉行每日站會時,這也必須是一個考慮因素。
我常常看到的一個問題是,人們傾向於將每日站會當作簡單的我的報告。「我作了這個…我會作那個」——而後轉向下一我的。更爲理想的方法是更接近於橄欖球的抱團。
——Jeff Sutherland,每日站會的起源[14]
說話的音量會影響注意力以及溝通的有效性。物理距離會改變溝通所需的音量大小。有些人不會大聲說話,並且以爲這樣作不舒服。
所以
站會的時候應該更像是一個抱團,而不是一個會議。若是難以聽清,就讓每一個人都靠近一點。除了容許更輕鬆的說話音量外,身體的距離每每會使參與者更加專一。可以站得更近也是團隊成員彼此信任的一種表現。若是你們還不熟悉站會,一般只需用手勢招呼人們,並說一些相似「讓咱們圍成一圈」的話就能夠開始站會了。若是圈的大小已經有一段時間沒變了,在試圖縮小圈子以便讓人們靠得更近以前,能夠考慮解釋一下縮小圈子的緣由。
可是
團隊必須平衡好親密關係和我的隱私。即便在一個彼此很是信任的團隊中,也存在人們因站得太近而不溫馨的狀況,症狀每每是參與者緊張和/或煩躁不安。
有些人很健談,而且傾向於在講故事的時候發散不少東西。還有些人在聽到一個問題後就想當即解決這些問題。時間過長的會議每每會致使你們注意力不集中,與長時間討論沒有直接關係的參與者每每就會分心。
所以
讓全部與會者在會議期間站起來。利用站會將身體與感受聯繫起來,當會議時間過長時,身體的不適就會提醒與會者。鼓勵這樣作的一個簡單方法是在沒有椅子的地方舉行會議。
可是
站起來每每會使會議縮短,但並不能保證會議縮短到最佳長度。人們可能會慢慢適應這種不適,而不是嘗試去縮短期。另外,若是會議不會花費太多時間,也不會偏離主題,那麼站起來就是一種沒必要要的儀式了。
大多數人在開長會時都會精神恍惚。以冗長的會議來開始一天的工做,這將是一種可怕的、耗費精力的方式。一個具體的時間要求有助於提醒咱們什麼時候應該考慮減小會議的時間。
所以
將每日站會的時間控制在15分鐘或更短。通常來講,15分鐘後,普通人的注意力就會飄忽不定,這不利於設定工做的重點。
可是
15分鐘對於較小的團隊來講可能仍是太長了。因爲注意力的影響,即便對於較大的團隊,15分鐘也是一個很好的限制。另外,也要注意有可能由於會議時間過短,在會議結束時,與會者仍然不知道發生了什麼事,也不知道該和誰談以瞭解狀況。
在最後一我的發言後,團隊可能不會當即意識到會議已經結束。當人們逐漸意識到會議結束而各自離開的話,這不能讓會議在愉快中結束,反而會致使低能量。
所以
用一句話(例如,好了,你們享用午飯吧。[15])或其餘一些動做來表示站會的結束。
很難定性地判斷一個會議是否耗時過長,尤爲是當它的長度逐漸增長時。
所以
爲會議計時並公佈結果。大多數時候,與會者並無意識到講故事的影響、沒有準備好「線下解決」或者沒有準備好會議須要多長時間。咱們最好讓會議時間可量化。
可是
與全部措施同樣,除非因爲精力問題而又要完成實際的目標,不然不該該強制約束會議的時間安排。一旦目標完成,就應該放棄度量。沒有特別緣由的度量會致使懷疑和對度量指標的冷漠。
時間是精力、注意力和節奏的表明。比起時間,更要注意這些東西。
有些人在聽到一個問題後就想當即解決掉這個問題。時間過長的會議每每令人精力不足,與長時間討論沒有直接關係的參與者每每會分心。認可須要線下進一步討論以解決提出的問題是很重要的。不過有些人會以爲經過打斷別人的發言來維護站會的時間可能讓人不舒服。
所以
使用簡單而一致的短語(如「線下解決」)提醒此類討論應該在每日站會以後進行。若是討論的內容就是閒聊,就不須要再作什麼。若是討論的是問題的解決方案,主持人(最終只應有團隊)應確保提名或登記合適的跟進人,以便稍後處理問題。
另外,有些團隊使用更多的間接信號。
例如,Mike Cohn描述了一個使用橡膠老鼠來表示「咱們正在進入一個老鼠洞」[16]的例子。
Benjamin Mitchell描述了一個兩手法則(Two Hand Rule):
...若是有人認爲當前的談話已經偏離了主題,或者再也不有效,那麼他們就能夠舉手。一旦有第二我的舉手,那麼這就是中止談話的信號,這時咱們就要中止談話並繼續站會的其他部分。站會結束後,發言者能夠繼續討論。
——Benjamin Mitchell,陷入冗長的敏捷站會中?試試兩手規則[17]
可是
解決問題和澄清問題之間是有區別的。不被理解的信息是沒有用的。容許澄清問題的程度應取決於團隊的規模以及是否會影響「15分鐘或更短」。
團隊成員傾向於向領導彙報,也就是說,他們只與會議主持人交談,而不是相互交談。只有會議主持人在提出和解決與站會有關的流程問題。咱們但願團隊可以擁有站會的全部權,這就須要消除對單一主持人的依賴。
所以
輪流擔任主持人。輪流擔任主持人的角色,負責確保人們參加站會並遵照商定的規則。
可是
沒有站會經驗的團隊能夠從有經驗的教練中學到不少有用的知識。可是更重要的是,應該讓團隊對站會有更大的主動權。在某些時候,應該根本不須要明確的主持人。
團隊成員傾向於向領導彙報,也就是說,他們只與會議主持人交流,而不是彼此交流。咱們但願團隊可以掌握站會的主動權,這就須要消除對單一主持人的任何依賴。
所以
做爲一種巧妙的提醒發言者的方式,主持人應該斷開眼神接觸[18],讓他/她對着團隊而不僅是對着主持人講話。這樣作的一個方法是四處走動,使當前發言者看不到主持人[19]。
我忍受了三年的按期站會。最使會議痛苦的是個人老闆(我叫他Wally)。他召開站會的主要緣由不是爲了提升效率或擁抱XP,而是爲了縮短與產品直接相關人員的互動時間。……然而,對於Wally來講,站會(就像週一早上7點的會議和週五下午5點的會議)是一個忠誠度測試,旨在增強僱主和僱員之間的關係。
——Phillip A. Laplante,站會和交付:爲何我討厭站會[20]
有一些「味道」是站會出問題的良好指標。須要注意的是,即便沒有「壞味道」,也並不意味着站會會順利進行。這只是意味着它不「臭」。
下面的大多數「味道」都與以前的模式有關。對於那些不在意站會模式的團隊,潛在的問題每每更微妙,這超出了每日站會的範圍,人們必須提出本身的解決方案。
人們過於關注他們正在作的事情,卻忽略了他們的努力是否真的在推動工做。從新組織站會,讓你們開始關注工做項。
團隊成員面向經理或會議主持人說話,而不是與團隊交流。這代表每日站會是爲了經理/主持人而開的,但實際上站會應該是爲了團隊而開的。有多種方法能夠打破這種依賴性:輪換主持人,斷開眼神接觸,改變昨天-今天-障礙的形式,使用傳遞令牌,等等。
這個問題由同一地點、同一時間直接解決,但如前所述,頻繁出現這個問題可能代表站會的時間或地點是錯誤的。
有其餘的模式能夠用來應對這種狀況,例如罰款。然而,我通常不會推薦這種作法,由於它們暗示問題與外在動機有關,而問題更多是由其餘緣由引發的。
由於站會被認爲是一天工做的開始,因此不少人在站會以前不會作什麼工做。根據早上站會的時間,這可能會對可用的工做時間產生重大影響。這就引出了不要使用站會做爲一天工做的開始。
站會的目的之一是增長團隊的社交活動。然而,每日站會並非爲了讓團隊成員在與項目無關的事情上互相「敘舊」。很難提供一些例子來講明社交活動究竟是提升了團隊建設的水平仍是分散了團隊的注意力。但每日站會上社交活動的效果,能夠從沒有直接參與社交活動的參與者的行爲中發現。若是他們的注意力仍然很高,那麼可能只是團隊建設;若是他們的注意力降低了,那麼就線下解決,也許還能夠提供另外一個討論會來充當冷水器[21]。
我昨天作了什麼?…我不記得了…我今天在作什麼?…我不知道…
缺少準備會致使站會節奏變慢,從而致使能量下降。這也有可能致使15分鐘或更短的失敗,從而進一步下降能量水平。
避免這個問題的一個好辦法是改變站會的方式,讓工做項出席,經過走板更新工做項的狀態。
不然,想讓每一個人都能知道昨天-今天-障礙的答案只能指望每一個人都頗有責任心了。
參與者沒有提供問題的簡要描述,而是提供了足夠的細節和背景,這會致使其餘人的注意力被轉移。站會的通常的規則是隻在站會期間識別障礙,在站會後討論細節。這能夠概括爲「描述標題,而不是整個故事」或「線下解決」。
如今是提出問題和闡明想法的時候,而不是深刻解決問題的時候。
——Marc Graban,Everett診所的每日聚會視頻[13]
將站會保持在15 分鐘或更短的關鍵是限制講故事,不要在會議期間屈服於解決問題。讓他們線下解決。
低能量可能意味着因爲講故事、解決問題等緣由而致使的節奏減慢。在這種狀況下,請引導團隊成員線下解決。低能量可能還意味着團隊規模太大,亦或是站會開始的時間較晚,建議嘗試不使用站會做爲一天工做的開始來替代使用站會做爲一天工做的開始。
也被稱爲:遊記[22]
沒有提出障礙可能有幾個緣由:不記得了,容忍度很高,對提出問題缺少信任(由於障礙沒有被解決),沒有方便的提出問題的方式,等等。主持人應注意鼓勵人們提出障礙。
引入改進板能夠提供一種低對抗的媒介。回顧會[23]是發現障礙沒有被提出的根因的有效途徑。
除了指責的環境影響以外,阻止人們提出障礙的最可靠的方法就是不解決它們。爲了令人們難以忘記和/或忽視障礙,能夠用改進板公開跟蹤它們。
站會能夠做爲兜底障礙的安全網,在最壞的狀況下,障礙也會在一天以內被傳達給整個團隊。然而,站會並非爲了阻止問題在一天內隨時被提出和解決。引入另外一種實踐(如改進板)來提出障礙可能會有所幫助。若是作了改進依然沒有效果,能夠經過回顧會來分析根本緣由。
但願這篇文章能爲你提供一些關於有效站會實踐的細節和問題常見指標的更多方法。咱們應該清楚,每日站會不只僅是天天站在一塊兒。
最後,重要的是不要太在乎每一種模式,甚至是擁有一些「味道」。記住咱們要解決的問題:人們是否精力充沛?人們是否在分享問題和想法?人們是否專一於咱們的目標?人們是否做爲一個團隊一塊兒工做?每一個人都知道發生了什麼嗎?
若是你能對這些問題做出確定的回答,那麼會議可能會進行得很順利。畢竟,這真的只是天天一塊兒站起來而已。
參考資料:
來源:小船哥說敏捷
做者:adoudou
聲明:文章得到做者受權在IDCF社區公衆號(devopshub)轉發。優質內容共享給思否平臺的技術同伴,如原做者有其餘考慮請聯繫小編刪除,致謝。
6月每週四晚8點,【冬哥有話說】開心一「夏」。公衆號留言「開心」可獲取地址