l

2017年6月20日 星期二

當Pattern遇到Scrum(5):Sprint Retrospective

June 20 10:43~12:00

螢幕截圖 2017-06-20 11.51.22


Sprint Retrospective Pattern

今天談Sprint Retrospective,簡稱Retrospective。該模式的原文在此,有興趣想詳讀的鄉民可以參考。今天看Context、Problem、Force、Solution這四個元素。

Context:Sprint即將結束,你已經準備好繼續打拼下一個sprint。無論這個sprint進行的如何,你總是希望下一個sprint能夠越做越好。

Problem:如何持續改善開發流程?

Forces:

  • Daily Scrum提供了一個持續改善的機會,但由於每天周期太短不易發現改善之處也不易評估改善成效,加上Daily Scrum的主要目的在於讓團隊重新計畫以便達成Sprint Goal,所以不適合用來討論持續改善的議題。
  • Sprint Review用來評估產品,且可能有stakeholders參加,同樣不適合用來討論持續改善的議題。
  • Sprint一個接著一個,團隊傾向急著進入下一個sprint開發新的功能而忘了思索現有的工作模式可否有改善之處,因而導致相同錯誤一再發生。
  • 團隊在最近一個sprint做了許多改善,他們認為現狀已經很好沒什麼可進一步改善,更多對於改善的討論只是浪費時間而已,他們的時間要拿來做「真正的開發工作」。
  • 當團隊成員自我評量的時候他們可能會覺得不好意思、受威脅、不稱職,這可能導致防衛行為—否認自己的責任並且把問題歸咎於其他人。

Solution:在每個Sprint結尾舉辦一個活動讓Scrum Team可以評估它在Sprint中的工作狀況。

***

討論

Retrospective(自省會議)講起來簡單做起來不容易,畢竟持續改善本身就是一種「找自己麻煩」的做法,要讓團隊自我感覺良好很容易,要讓團隊自我感覺不良好卻很傷腦筋因此不少人選擇「閉上眼睛就以為看不見」,或是抱持著「改善是Scrum Master的責任,你來告訴我怎麼做,我覺得合理就配合,覺得不爽就不鳥你」的心態。

落實持續改善最基礎的做法是讓Scrum團隊有一個大家共同願意遵守的Definition of Done(DoD),一開始DoD不要訂得太嚴謹,最好跟團隊現況一樣或稍微增加一點要求即可。隨著每個sprint的進行,依據團隊的狀況再逐次慢慢加強DoD。

另一種方式是在〈高效率Scrum團隊的九個模式〉介紹過的Scrumming the Scrum模式:「找出上一個sprint中最重要的一個阻礙(impediment),把它寫成user story加上驗收條件放入下一個sprint的sprint backlog,確保在下一個sprint結束前把這個阻礙移除。」

也有許多團隊喜歡每次retrospective採用一種新的開會方式,例如心情曲線與各種形式的ORID等。這些做法原意是讓團隊可以透過不同的角度來「自己看到問題」,但套用這些方法很容易走火入魔,變成為了方法而方法,流於形式而忘了原本目的是要持續改善一開始團隊成員對於新的retrospective方法覺得很有趣,但是如果持續改善沒有發生,只有改善的方法持續改變,不久之後團隊成員也會覺得無聊而把retrospective視為浪費時間的活動。

很多時候持續改善無法發揮作用,並不是團隊不知道那些地方需要改善,而是團隊乃至於整個公司缺乏信任,因此團隊成員自然產生防衛心態。任何的改善建議都好像是衝著自己而來,不管是在檯面上還是檯面下,當然要抵死反對到底啊。

***

友藏內心獨白:實質重於形式。

沒有留言:

張貼留言