2023-08-02|閱讀時間 ‧ 約 26 分鐘

Waterfall 陰魂不散

此為過去的舊文,2015 年 8 月 25 日初次發表於 logdown。
圖片來源:www.freepik.com

圖片來源:www.freepik.com

2015 年隨著團隊組織方式的改變,個人在團隊中的角色也有了改變,改變至今大概有三個多月,從不同的角度在看事情時,也能得到許多有趣的想法,加上幾次參加C.C. Agile也都能得到意外的驚喜,讓自己反省:自己真的Agile了嗎?真的了解scrum?

敏捷宣言 (Manifesto for Agile Software Development)可能很多人都能朗朗上口(事實上,若隨堂考我,書上或網路上能查到的東西,我通常背不出來,除非我是一個指導別人怎麼跑敏捷開發的顧問,不然背的滾瓜爛熟有什麼意義?),但其中一句:Responding to change over following a plan,就這樣的一句,都不見得是容易做到的,有時內心其實是在抗拒的,因為人本質(well,我不是心理學家,我可能無法證明這件事)上是有點害怕改變,因此做任何事前,都會有計畫並希望所有的事情都照計畫走。

過去的軟體開發便是想管控變化,很多團隊都使用瀑布模型、使用CMMI...,有趣的是,Royce在論文中提瀑布模型的目的,是要拿它當例子來說明軟體開發不能這樣做!有了完整的分析、設計和計畫,然後盡可能避免變化,但大家都知道這不可行,於是有人提倡了敏捷開發,但即便用了某某敏捷開發方法,擁抱改變依舊不是件簡單的事,因為內心還是有waterfall依舊陰魂不散地在很多小地方出現。在敏捷團隊中,還是有可能聽到這些對話:

  「因為沒有細部設計,到時候可能會重工...」
  「因為沒有細部設計,我無法決定...」
  「某某某又改了什麼設計,重工浪費很多時間...」

回頭想想,敏捷精神到底是什麼?我覺得最核心的部分是快速取得回饋並盡快做調整(或稱trial-and-error process),如果在這個核心上來看scrum的幾個活動、產出或實踐,也許就能知道自己是否做得好或不好?

Planning meeting - 重點不在於設計是否一定要細到如規格書一樣才能估時數,細節足於開工就夠了,重點在於團隊的理解是否偏離使用者的需求,一些細節在實作的過程中都還能跟PO確認與調整

Daily scrum - 重點不在於昨天做了什麼?今天要做什麼?還需要多少時間?重點在於我遇到什麼困難,是否需要援助,在會後,scrum master或團隊是否能幫助有困難的人解決問題

Burn down chart - 重點不在於進度是在線上或線下,重點是在線上時團隊能做出怎樣的調整?在線下時,是否有細節被隱藏,當提前完成時,是否還能再加入新的story

Review meeting - 前陣子曾在C.C. Agile聽到一個團隊,因為平時story一完成馬上就跟PO驗證,因此除非真的要展示給stakeholder看,或是要跟團隊討論product backlog的優先順序,不然是不舉行review meeting,若核心精神是快速取得回饋並盡快做調整,那當一個story完成馬上與PO確認,有問題在還有時間的情況下,可以調整不是更好嗎?所以重點還是在於如何快速驗證story是否完成

Retrospective meeting - 重點在於團隊是多認真看待持續改善這件事,願不願意說真話,能不能提出有意義的建言。更重要的是團隊能獲得多少自主調整的空間,在獲得這空間後,團隊是否努力改善自我

Continuous integration and regression testing - 這幾乎是最能反映核心精神的實踐,由於就是有持續整合與回歸測試,因此能快速取得回饋(建置失敗或無法通過測試),才能快速調整(修正)。

在原始的scrum中並沒有明確提到user story refinemenet meeting,但在後來很多scrum教材或實施上,都會有這個會議來釐清stakeholder的需求,團隊過去也在這個會議的進行方式上做過多次調整,在團隊分組後,到目前也調整了兩次進行方式,但運作起來總覺得哪裡卡卡的,最誇張的一次是分組後的第一次refinement meeting:全員加班到隔天凌晨,那一次對團隊士氣的殺傷力其實很大,個人認為PO與團隊之間出現了些小裂痕。

因為團隊成員或多或少對於設計有高度的興趣,因此後面的幾次調整還是讓團隊能參與what的設計,個人提出了一些建議,至今我仍然還在想:以我的角色,我當時應該出手建議嗎?後來這建議和其他團隊成員與PO的意見變成了一個新流程。即使是分組後新的流程,回頭看看過去執行的情況,腦海中浮現過去scrum master說過的一句話:我們該不會是mini waterfall吧

當refinement meeting的重點不在於釐清問題與背後的情境,不在溝通和確認需求,不在找出what,馬上投入到how的細節設計,這設計真的滿足stakeholder需求嗎?當設計細節已經細到UI上的某個元件如何呈現、要有哪些多國語系的key時,這和過去waterfall的差別又是什麼?當為了避免開始施工時發現問題,回頭大幅修改設計(這個自己可能也要反省,因為自己也曾抱怨類似的問題),因此希望能夠在refinement時確認所有細節時,這樣真的算是擁抱改變嗎?

過去我很喜歡《搶救貧窮大作戰》這個節目,節目尋找經營不善的店家,協助老闆到其他的店進行非常嚴苛的訓練,在獲得技能後改善原有的經營方式,這節目後來有回去追蹤過去參加受訓的店家,有的能延續好的成績,有的則變回跟受訓前沒兩樣,現在想想,這會不會是在守、破、離的成長過程中,其實並沒有在守的過程中,真正理解那些規則、教條背後的意義,並自以為是地進到破與離的階段?或是只在守這個階段原地踏步?

回到敏捷開發或是scrum的方法中,這些活動或教條,依樣畫葫蘆,反覆練習,直到熟練,但真的了解背後意涵嗎?當要根據團隊的情況對現行方法進行調整,進一步到破的階段時,是否沒有偏離原先的價值?是否能擺脫waterfall的心魔?這或許是轉換角色後,我思考最多的問題。當然,如果一開始抓住的核心觀念是錯的,那自然會練成九陰白骨爪或是逆練九陰真經。

分享至
成為作者繼續創作的動力吧!
© 2024 vocus All rights reserved.