Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
10. 我們如何做sprint回顧
為什麼我們堅持所有團隊都要做回顧會議呢?
有關回顧最重要的事情, 是確保回顧會發生.
基於某種原因, 團隊傾向不太願意去做回顧. 沒有些溫柔的刺激, 我們大部分的團隊通常會跳過回顧, 然後移向下一個sprint. 或許這是瑞典文化的問題, 但我不太確定.
不過, 每個人看起來是同意, 回顧是極端有用的. 事實上, 我想說的回顧是scrum中第二重要的事件(最重要的是sprint規劃會議), 因為這是你去改進的最佳機會
當然, 你不用需要回顧會議去得到好的點子, 你在家裡的洗澡盆中就能想到! 但是團隊能接受的想法嗎? 可能吧! 但是如果這想法"來自團隊", 也就是在回顧會議上, 每個人都可以貢獻和討論一些主意, 這樣得到的想法會讓大家容易接受.
如果沒有回顧, 你會發現團隊, 會一而在的, 再犯同樣的錯誤.
我們如何組織回顧會議
或許大家的做法會稍有不同, 但是我們通常會這樣做
# 根據討論的範圍有多少, 我們會安排1-3個小時
# 參與者: 產品負責人, 整個團隊, 和我自己
# 我們會到一個封閉的房間, 或是有舒適的沙發的角落, 或屋頂庭院, 或是類似的地方. 只要我們能夠不受干擾的討論就好.
# 我們通常不會在團隊的房間內做回顧, 因為人們的注意力很容易被分散
# 會指定某個人當秘書.
# Scrum master會展示sprint backlog, 在團隊的幫助下, 對sprint做出總結. 包括重要的事件或是決定等等
# 我們會輪流發言. 每個成員在不被打斷的狀況下, 會有機會說出他認為什麼是好的, 什麼是可以做的更好, 以及什麼是下個sprint可以做的不一樣的.
# 我們會檢視預估和實際的速度. 如果有太大的差異, 我們會分析為什麼.
# 當時間快要結束的時候, Scrum master會試圖去總結具體的建議, 有關於下次sprint中我們什麼地方可以做的更好
我們的回顧會議一般來說不會太結構化, 太嚴謹. 但是潛在的主題都是一樣的: "下次sprint中, 什麼事情我們能做的更好?"
這裡是我們最近一次回顧會議的白板:
這裡有三行:
# Good: 假如我們再做一次相同的sprint, 我們哪些事情可以保持相同的作法
# Could have done better: 假如我們再做一次相同的sprint, 我們哪些事情的做法可以改變
# Improvements: 有關未來我們如何改進的具體方法
所以第一行和第二行是回顧過去, 而第三行是展望未來.
在團隊集思廣益, 列出所有的想法後, 他們會用"計點投摽"去決定, 哪些改進是下個sprint需要注重的. 每個團隊成員會有三塊小磁鐵, 可用來決定在下一個sprint中, 要改進項目的優先順序. 每個團隊成可以自行決定磁鐵要放在哪個項目, 或是三個都放在同一個項目上也可以.
根據投票的結果, 選出5個要著重的項目. 在下一個回顧會議中, 他們會追蹤這些項目的改進狀況.
重要的是, 不要過度貪多. 在每個sprint中, 只要著重幾個改進項目就可以了.
在團隊間散播所學到的教訓
在sprint回顧會議中, 所得資訊通常是極度的有價值. 團隊很難集中火力, 是因為銷售經理強押開發人員在銷售會議上充當技術專家? 這是非常重要的資訊. 是否其他團隊可能也有相同的問題? 我們是否應該教育產品經理更多有關於產品的知識? 因此讓他們自己可以做銷售支持(sales support).
一個sprint回顧會議, 不只有關如何讓團隊在下個sprint中能做得更好, 它還有更大的涵義.
我們處理的策略是十分簡單的. 有個人(目前是我)參加所有sprints的回顧會議, 充當經驗知識的橋樑. 相當不正式.
另外一種方法, 是讓每個scrum團隊公佈一份sprint回顧報告. 我們曾經試過這個方法, 但是發現沒有很多人去看這些報告, 因而導致更少的改進. 所以我們只是用上面這種簡單的方式.
對於充當"經驗知識橋樑"的這個人, 有些重要的規則:
# 他應該是一個好的傾聽者
# 如果回顧會議太安靜, 他應該準備去問些簡單, 但是目標明確的問題, 可以刺激團隊的討論. 例如:"如果時間可以到轉, 重新從第一天開始這個sprint, 那些事情你會用不同的方法進行?"
# 他應該自願花時間去參與所有團隊的所有回顧會議
# 他應該具有某種權力地位, 所以在一些團隊無法控制的改進建議, 他可以幫忙推動.
這種方法運作的相當好, 不過也許有其它方法能做的更好. 如果有的話, 請告訴我.
留言列表
