iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 12
0
自我挑戰組

再戰軟體工程系列 第 11

『你是在回顧,還是在驗屍?』 -- 談回顧會議的產出

回顧會議,大家都知道,指的是在一個Sprint結束後,大家回頭檢討看看哪裡做得好哪裡還有改進空間的一個『儀式』。然而,現實情況是,有在跑scrum流程的團隊之中,有舉辦過回顧會議的其實很少,有在固定舉行,並且可以藉此一步步改善流程的,更是鳳毛麟角。

『檢討了又改變不了什麼,有什麼用?』是不舉行回顧會議,或是在回顧會議中不說真話的最常見原因。為什麼?我們在抱怨公司不聽我們的建議之前,不如先回頭檢討:『你這是在回顧,還是在驗屍?』

Scrum開宗明義其實就說了,『不是所有團隊或企業都適合scrum。』為什麼?我們來看看scrum怎麼跑的:把一個長期的產品線切成一格一格固定長度的sprint,每一個sprint決定要做的事,並且只做最重要的。

注意到了嗎?我們做的是『長期產品』,而不是『短期專案』。因為產品的開發是沒有盡頭的,我們的事情不會有『做完』的一天,所以每次交貨後,我們賣出去的不是產品本身,而是這個產品此刻的『功能』。客戶也不是買斷我的產品後再來做售後服務,我們的功能和服務都是長期並且隨時在改善的。

這才是為什麼我們需要回顧會議。

如果你沒有長期持續改善的心,或是你的公司就是一直在做專案做專案,那麼,你不適合scrum,所謂的回顧會議自然也就沒有幫助了。硬是要跑scrum流程的話,那也就是為了scrum而scrum,開的回顧會議也就變成只是在驗屍而已。為什麼?啊你就只是把屍體翻過來看看哪裡有缺角啊,你又沒有要讓他起死回生,驗他做什麼呢?

如果你要做長期產品,並且想持續改善,那我們就可以繼續談下去了。

所有會議都要有產出,而且這個產出要在會議開始前就決定好形式,內容可以會議中慢慢填入。回顧會議的產出很簡單,就是一個改善行動。

不是5個,也不是10個,就是一個改善行動。

一個sprint改善一件事聽起來很簡單,但是做起來不容易。事實上,多不是重點,落實才是。你不可能要求一個極端集權的政府,一夕之間變成很民主。要不然也不會有92年的天安門屠殺事件了是不。(太敏感嗎?)工作習慣的改變也是一樣的,我們知道我們的問題很多,要全部改完才會痛快,但是,你不可能一聲令下就叫全體同仁一次改變所有幾十年來的工作習慣,那太為難人了。

所以,提出一個改善項目,不是五個或十個,並且從今天起就一定要做到。
想想,長期下來也是很可觀耶,你一年就可以改善工作上26個壞習慣,多有建設性啊!

持續改善不是口號,他應該要落實在每一天的生活中,而scrum的回顧會議,剛好就提共我們這個機會,讓我們以一個穩定的節奏,一個一個地,改善工作中令我們感到困擾與浪費生命的工作方式吧。

我更建議,不跑scrum的團隊,也可以定期大家坐下來審視最近一個月或半個月的工作狀況,把進度丟在一旁,花45分鐘至1小時,用腦袋思考,工作流程中有什麼不科學或是不方便的地方,具體而微地提出『改善方案』。這個方案不用100分,他只要60分就好。假設你認為現在的流程是不及格的話,這個60分方案就能讓你進步。

要有方案(Action)才是重點

如果沒有方案,回顧會議又變成抱怨大會,那你再過十年還是在用老方法管理工作,那就馬齒徒長了。就像我一直說的,老方法不是不好,只是你明擺著有更好的選擇,就應該讓自己更好不是嗎?

擁有一個60分的方案,絕對比什麼都不做而純抱怨,還來得有價值。

真的提不出什麼高明方案怎麼辦?那就看看有沒有老司機要開車啊!懂的就跟上,有你好處。
https://ithelp.ithome.com.tw/upload/images/20171226/20107429ENyzNYo04O.jpg


上一篇
『出來混,遲早要還的』 -- 工程師心中最軟的一塊:技術債 (下)
下一篇
『依賴注入(DI)』 -- DI做啥小?你才DI,你全家都DI!
系列文
再戰軟體工程30

尚未有邦友留言

立即登入留言