今年我最想要報名的鐵人賽主題莫過於 Agile 了。
從去年年底僥倖地被好公司看重我軟體工程出身的背景,開始我人生的第一份正職。從一開始不斷地摸索自己的角色定位,到開始嘗試導入 Scrum,逐漸將一些敏捷開發的精神透過 Scrum 導入到組織裡,雖然不一定所有的元素都適用,但卻也有看到成效,讓我感到成就與無比喜悅。所以今年鐵人賽洽有 Agile 主題,我就不禁野人獻曝的將自己的感悟與經驗發表上來。
本系列文的主題是《為團隊與組織導入敏捷的經驗分享》,雖然我嘗試導入的是 Scrum,但是我卻沒在系列文標題裡講到 Scrum,主要原因是因為我擔心從 Scrum 開講會讓讀者被這個框架給束縛住了,或是被裡面的專有名詞弄得頭昏轉向、望之卻步。事實上,我更想講的是透過導入 Scrum 學到的敏捷精神,尤其是團隊意識和 Retrospective,這也恰是我認為 Scrum 中最值得抽出來講的概念,也是最難的部分,就連現在我也沒有把握引導團隊完全做到。
在傳統的工作環境,我們講的都是分工而不是合作,職責分得很細,一群人的組成頂多叫做群組、部門,就不能稱之一個團隊。我很喜歡 Scrum 裡面團隊的概念,我也認為這是一個能凝聚彼此並且一起扶持向上的動力,如果所有成員都把心思放在團隊的進步上,就不容易發生對人不對事,或是推託責任的情境,因為成敗都是以團隊為單位,一起榮耀、一起負責。
正如我在另一篇系列文 《軟體開發隨筆談》 的最後一篇文〈不只解決客戶的問題,也要解決開發流程上的問題〉 所提到的:
但身為開發現場的我們,也會遇到許多與開發流程上相關的問題,卻常常顧著解決客戶的問題,而沒有餘力再去處理我們遇到的問題。但是這些問題長期積累下來,會直接或間接的導致軟體品質下降以及團隊產能的穩定輸出,我們應該要和主管或是組織其他部門協商,除了解決客戶的問題以外,也要留點時間解決開發團隊在流程上遇到的問題。
Retrospective 就是一個用來讓團隊回顧衝刺、自我省思的一個很棒的空間,也讓團隊成員透過這個機會將自己對於團隊的不滿表達出來,並透過 Retrospective 想要解決、改善問題的目的,引導彼此將討論聚焦在事情上,而不是譴責。我認為,一旦團隊學會自省、學會逐漸改善團隊本身的流程與文化,那團隊就算打開了敏捷世界的大門,透過 Retrospective 我們可以不斷地將適合自己團隊的敏捷元素,透過活動中的討論取得共識一一導入到團隊中。透過活動中的討論、質疑、思考,我們也能真正學會敏捷開發真正的精神、文化,而不是形式上的照單全收,這也是我認為最好的導入敏捷的方式。
在這一年為組織和團隊導入敏捷的過程中,我最先導入的正是 Retrospective。很感謝我的夥伴們願意讓我嘗試,並一起摸索會議的進行方式,討論如何不掉入敏捷的形式,並信任我、讓我一一主持每一場會議,從 Retrospective Meeting 開始,到 Planning Meeting、Review Meeting、Daily Meeting,這之中我得到了很多經驗,也才因此能在這邊與大家分享這些心得。
本系列文最初的方向就是想著重在 Retrospective,所以初期我透過盡量避開專有名詞的方式,單純把概念和心得寫成一篇篇的文章,這些概念是我認為可以單獨存在、看重的敏捷精神。後來也順帶講了我們團隊最愛的 Planning Poker,並透過這個活動講解了規劃的估算。也隨著講到規劃,分享了團隊如何一起進行規劃衝刺的經驗,以及組織如何對產品進行規劃的概念,這的確都是我在這一年導入的元素,也希望能讓這系列文多元一點。到了後半段,回到了團隊精神以及 Retrospective,經過前半段的鋪陳,我已經先將 Retrospective 的精隨講了大半,所以後半段就比較偏向實務,也就是透過活動向各位講解 Retrospective,並在最後分享我對 Retrospective 活動設計的心得作為收尾。
我這幾天會再陸續審閱本系列文的內容,可能會修正錯字、補充內容、稍微調整文章架構。並在之後會再找時間重新整理,把這系列文發表到 Blog 上,讓本次分享更有連貫性的提供給其他需要的人。有興趣的朋友可以訂閱我部落格的 RSS。
也歡迎看看我在這次鐵人賽的另外兩門主題的系列:
對,我今年發瘋似的報名了三個主題,這 30 天真的既痛苦又快樂著。我已把對於這次參賽總感想另外發佈在本系列文裡,若有興趣可直接參閱〈2019 鐵人賽完賽總感想〉
最後,感謝這 30 天瀏覽、訂閱、喜歡本系列文的朋友們,你們默默的給了我完成的動力。每一次有人訂閱和按讚,都讓我有如跑鐵人馬拉松時在休息站喝到水、吃到食物一樣,彷彿活力又回來了,謝謝你們的鼓勵,讓我更有動力完成這次的鐵人競賽。
本文有針對整系列文作重新構成的目錄,讓大家好針對自己想知道的部分做選擇性地閱讀,希望大家還喜歡我今年的分享。 = )