回顧會議的重要性 (The importance of retrospectve meeting)
上週五, 我們團隊招開了第一次回顧會議, 個人覺得效果很好, 把平時沒說的話都說了出來, 或許不見得沒有保留, 但至少跨出了第一步.
你可能會很驚訝, 為何會是第一次? Scrum不是每次sprint完後都要舉行一次回顧會議?
是的. 這是目前我們的困境. 我們專案是由兩個小組所組成, 平時溝通並不是很密切, 兩個小組在不同樓層, 不同的軟體開發流程(一個waterfall like, 一個scrum like), 不完全相同的老闆, 因此彼此累積了不少問題.
很多時候我們都急著想要去交付東西, 急著趕上進度, 可是卻沒有時間思考. 沒時間問問自己, 做這些事情有幫助我們的產品大賣嗎? 那些是顧客要的嗎? 或者如何驗證那些是客戶要的?
回顧會議可以要幫助團隊, 在忙碌的時候, 停下來看看, 到底發生的甚麼問題.
在這次會議中, 大家有個共識, 那就是都忙得不得了, 忙, 好忙, 超忙, 忙到無法回報自己的進度, 忙著無法進行design review, 忙到只能測試happy path, 忙著救自己前一版所放的火...
主因是為了趕上進度, 大家犧牲了軟體的品質, 可是在出貨後帶來更多的問題. 因此在下一個sprint, 不但要處理做不完的功能, 還要去解決上一版所遺留下來的問題, 因此只有靠犧牲品質和加班來解決.
很慶幸地大家願意停下腳步, 花兩小時的時間, 說出目前的窘境....
至於第一步呢? 就是先減少每次交付的功能, 保留適當的測試和修復問題的時間.
接著將tech debt排入product backlog. 有計畫和慢慢地, 將之前所欠的債還掉.
很慶幸地, 大家都很成熟, 沒有太多情緒性的談論, 也沒人身攻擊. 這次是第一次, 所談論的問題和解法都還是很high level, 希望下次能更深入, 更有進展.
留言列表
