l

2016年8月31日 星期三

自省非自省

August 26 16:38~17:35

擷取

 

Scrum跑了一陣子許多團隊都會面臨「自省會議成果不彰」的問題。為了怕得罪人,有些人在自省會議變成「自我批判會議」,只提自己在這個sprint所犯的錯誤並且不斷道歉。有些人「有話直說」,不怕得罪「權貴」,例如在會議中直接挑明:「Product Owner所準備的user story太過模糊,害我們不斷修改程式浪費開發人員的時間。」

***

自省什麼?

Retrospective可以翻譯成自省也可以翻譯成回顧。自省並不是「個人行為的自我反省」,而是整個團隊針對「流程(做事情的方法)」的反省與改進。回顧這個sprint哪些做事的方法很好,鼓勵團隊持續維持。哪些做事的方式卡卡,找出最迫切的項目討論如何調整、改善。

鄉民甲:你們搞敏捷的人常說「自省會議是對事不對人」,但是事情就是人所搞出來的,討論到最後還會指涉到特定人士啊。

舉個例子,有團隊成員可能會覺得「Product Owner所準備的user story太過模糊,害我們不斷修改程式浪費開發人員的時間。」當腦袋想起這個念頭,其實已經對某個觀察到的現像作出結論了。換個角度思考,「不斷修改程式」是一個現象,但這個現象未必是因為「Product Owner所準備的user story太過模糊」所造成,也可能是因為開發人員遇到問題都不主動詢問Product Owner,導致程式寫好後才被要求修改。所以如果先描述現象,除了不斷修改程式以外,可能還有:

  • 這個sprint開發人員認為已經完成(Done)的story卻不斷被移回到Doing狀態,或。
  • 這個sprint原本預計完成五個story但最後完成3個。

這些都是開發過程中的「現象」,先溝通這些現象,接著再討論造成這些現象的可能原因,最後才擬訂改善計畫。

***

請ORID幫忙

有些敏捷團隊覺得在retrospective活動中使用「焦點討論法(Focused Conversation,又稱為ORID)」(請參考〈學問—100種提問力創造200倍企業力〉)可以避開「對人不對事」的問題。

  • 客觀(O):這個sprint發生什麼事件。
  • 反映(R):對這些事件的感覺如何,開心、喜悅、興奮、悲傷、生氣、暴怒、無奈。
  • 意義(I):這些事件背後代表什麼涵義?溝通不足、Product Owner太忙、團隊成員身兼多份工作、團隊成員遇到問題沒有立刻反應、不知道該如何反應、找不到人反應、不敢或不好意思反應、技術能力不足、團隊對於敏捷開發精神沒有共識、沒有定義Definition of Done(DoD)或沒有遵循它。 
  • 決議(D):把DoD印出來貼在taskboard旁邊,請每位團隊成員簽名;user story一完成立刻找Product Owner來驗收;sprint planning的時候讓團隊成員針對每一個user story撰寫驗收測試,拉近Product Owner與團隊成員對於user story內容的認知。

***

友藏內心獨白:Retrospective是持續改善的重要活動。

沒有留言:

張貼留言