iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 2
0

正如前言所形容,敏捷在近年來似乎被奉為救命神丹,似乎只要咬碎服下,各種關於團隊、組織的疑難雜症都可以迎刃而解。但是事情並沒有這麼簡單。這顆救命神丹,未必是一口服得下的。

就算在事前研讀過有關想導入的敏捷流程或是框架,想要一口氣導入都可能會噎到,因而窒息而倒。雖然經驗不多,但偶爾會聽過他人導入敏捷(通常是 Scrum),最後都淪為形式,或是根本無法執行的失敗情況,再繼續詢問下去,通常會發現很多都像是發現新大陸一樣興奮,於是興沖沖的要一口氣導入整個框架或流程,最後終於變動太大,頭尾難以兼顧,最後不了了之。

敏捷其中的一個價值觀就是「回應變化」[^1],意思在於快速響應變化並且持續發展。再白話一點,就是指要不斷聆聽回饋,然後根據回饋進行改變去適應、再持續聆聽回饋,繼續改變去適應、再聆聽⋯⋯。

套用在軟體開發就是指要持續和客戶溝通,確認需求,若是實作出來的成品不符合需求,就即時同步資訊,讓認知保持一致,並持續這個過程。而為了要能不斷接受回饋,所以軟體不會一氣呵成做完,而是定期或是一做完一小部分就找客戶展示、溝通、確認、紀錄,並回饋到下次開發的過程。

既然可以理解在軟體開發中套用敏捷,那導入敏捷的過程套用敏捷其實也是同樣的道理。若是一口氣導入所有流程,就像是軟體開發中的瀑布流一樣,看似計畫完美,但遇到幾個地方有問題就很容易崩盤,或是失去信心。既然都要導入敏捷了,那導入敏捷的過程也要敏捷。

可以先將想導入的流程進行拆分,判斷先導入哪部分對團隊來說價值最高,分析各個導入的難易度與成本,最後決定導入的排序。並隨著逐步導入的過程所收到的回饋逐漸修正這個排序,若是團隊還在消化新導入的政策,那下次想導入的部分可以挑選比較簡單、比較好推廣的,讓團隊在潛移默化下漸漸導入所有流程。最重要的是,透過這種方式也能讓團隊習慣改變

透過讓團隊習慣改變,也是敏捷一個很重要的元素。在團隊經營上,能讓團隊願意精益求精,不會被現有的流程僵化,會觀察在完成目標時遇到的阻礙,主動提出並且制定政策去改變。在軟體開發上,大家不安於現有的程式碼品質、不執著於既有的架構,願意嘗試重構去讓程式碼更好。在自我成長上,願意擁抱新事物,不斷學習更好的知識。習慣改變是一種值得保持的心態,是一股不斷注入的活水,讓團隊保持生命力。

稍微離題了,關於上段有機會可以再細談,話題回到敏捷地導入敏捷。

除透過上述的方式進行拆分,逐個導入外,另一個重點是讓團隊自發性的去導入,而不是單純由所謂的主管、敏捷教練或 ScrumMaster 強制導入,畢竟強制導入的東西還是只屬於自己,不會變成團隊的

在這部分,我會在導入政策前,先透過幾次主題分享,讓他們先暸解我預期想導入的元素,並在分享時強調「主題分享不代表要馬上導入這個元素」,而是先讓團隊暸解,並在沒有壓力的情況下進行交流,藉由分享激發他們的思考、想像,然後展開討論激發出更多想法,並記得在討論過程中接收回饋,暸解團隊對於這個元素的看法、疑慮等等,嘗試在討論中或是之後消除他們的顧慮,取得彼此的共識,最後才在團隊都認同下導入。

那有什麼辦法知道團隊都認同了,並願意導入呢?嘛,先別說這個了,你聽過回顧會議(Retrospective)嗎?


1: 敏捷軟體開發宣言


上一篇
前言
下一篇
團隊一起定期聊聊近況吧
系列文
為團隊與組織導入敏捷的經驗分享32

尚未有邦友留言

立即登入留言