這是昨天來不及聊到的故事,一樣是在就讀碩士時期在實驗室進行軟體開發的故事,所以主題一樣是三探敏捷囉。
在我開始承接實驗室的專案後,我一直努力要改善整個開發文化。我認為「工欲善其事,必先利其器」,在個人部分可能是建立自己習慣的開發環境,在團隊部分就是有好的流程、文化。經歷過實習後,就更加深這樣的價值觀。
昨天有聊到在無法改變資深的夥伴後,我開始對新進的夥伴進行嘗試,包括建立 Code Review 文化、制定 Coding Style 標準等等。這些都在當下與日後收到好的回饋,改善了專案的體質。
除了技術類的事情外,我也有導入一些團隊合作面的政策。一個就是建立共同使用的文字通訊平台、另一個我開始嘗試的就是每日會議。今天我們就來聊聊每日會議的部分吧。
會想要導入每日會議的原因,嘗試回想當時的動機,或許就只是因為看到敏捷開發有,好像很不錯,覺得可以試試看。但其實當下的我,並不懂得每日會議到底是為了什麼、該怎麼進行比較好。講難聽一點,就是跟風。這樣造成這個實驗到後來以失敗告終。
當時的我對每日會議的了解,網路上常提到的三個問題:
對,甚至還不是 Scrum Guide 上完整的三個問題問法,而是這樣的簡答。
當時原本有嘗試要在每天固定時間進行這樣的對話,但是如同大學時期遇到的障礙,每位學生選課時間不同,很難這樣進行。後來就變通改成每個人在每天下午一點前寫在 Hackpad 上,然後彼此瀏覽。
一開始在這個專案的三個人都很努力在寫,也都會去看寫了什麼,甚至用註解去詢問。但在一個月之後開始逐漸地就開始漏寫,最後變成每個人都沒寫,不了了之的結束這樣的實驗。
嚴格來上,或許這是我第一次嘗試要導入 Scrum?
儘管只是其中一個元素,而且以失敗告終 XD
當時對於失敗倒是沒有什麼想法,原本也就是想試試看。就算不了了之,其實也不知道為什麼會這樣。但現在回想起來倒是有些看法。
現在的我,會認為 Daily Scrum 是為團隊建立一個每日固定進行互動的機會,而這樣的互動式需要基於我們的目標為主題進行討論。正如 Scrum Guide 真正提到的三個問題是:
會發現每個問題都緊緊扣著「Sprint 目標」(Sprint Goal)。但就當時的我們來說,通常沒有所謂的目標、會是目標過大難以聚焦。所以這三個問題的答案很容易就會變成流水帳,未答而答。甚至在障礙上的答覆上充滿了私人事務:
而前兩個答覆也很多與專案無關:
所以與其說是在表述那三個問題,不如說是在寫工作日誌罷了。在內容越多與專案較無關係的內容後,就不會感到這樣的流程有所幫助,最後當然也就不會去做了。
我想在沒辦法定時定點進行面對面的每日會議,而硬要用共筆服務執行的案例,就是典型的重視流程與工具高過於個體與互動的反模式吧!也是一個為導入而導入,不去探究某種流程或政策是為了達成什麼目的、解決什麼問題的失敗案例。
正如同我在上面所說,我認為 Daily Scrum 是為團隊建立一個每日固定進行互動的機會,我們透過這個機會去建立共同理解。我們去理解現況是什麼、而現在距離目標還差多遠、我們打算在未來一天做些什麼拉近現況與目標的距離。
少了目標就算是失敗了,缺乏互動更是徹底的失敗。
透過文字儘管能揭露部分資訊,但仍有其限制。比如說固定時間能揭露的資訊量不如言語、每個人對相同文字的理解不一定相同、文字表達更多是單向的,很難當下去釐清與探詢。
而釐清與探詢就是互動中重要的部分,我們針對我們不確定的部分去釐清、我們透過探詢讓更多資訊可以揭露出來。面對面的互動更能降低這些問答的反應時間,更快達到我們建立共同理解的結果。
稍微做個延伸,尤其是最近 WFH,在不能見面的時候,我們很多時候是更依賴文字訊息做溝通。但若是一場對話透過文字溝通難以在十分鐘有結果時,或許更好的方式是直接語音通話,然後再把結果文字化給透明出去。從這邊我們可以發現到,面對面、語音通話都是一種能快速交換資訊的方式,但缺點是只有在對話裡的人才能接受;而文字更多是作為儲存訊息的載體,雖然來回反應速度慢,卻能重複被利用。所以這兩種方式並沒有優劣,而只有適合的情境。
在每日會議這樣的情境,我們期待的是透過互動、溝通的方式,迅速建立共同理解,並簡單對接下來的一天進行規劃。這些資訊可能只會被用到一次,過了今天就沒有用了。所以我會認為這樣的情境更適合面對面對話或者是語音通話,而比較不適合文字。
今天聊到我碩士期間導入每日會議的經驗,以及現在對當時經驗的反思。希望能帶給各位一點啟發。其實每日會議是 Scrum 裡面看來最簡單的事件,但卻也是最難做好的事件,聊到每日會議就會有很多細節可以交流,但在討論下去就會偏離主軸了。對每日會議有興趣的夥伴,可以去瀏覽我們威士忌打字機另外一位 Scrum Master —— Sam 的主題,他這幾日也對每日會議做了些探討。
明天我會在淺聊建立共同使用的文字通訊平台的經驗,並針對「三探敏捷」的故事做個總結。祝大家新的一週愉快~