【筆記文】全台敏捷大調查,Scrum Master 的三兩事

2021/09/28 的晚上,台灣敏捷協會 ACT 舉辦了一場線上直播【Agile Talks 敏捷論壇系列】全台敏捷大調查,Scrum Master 的三兩事。剛好那一天晚上有一些空閒,於是就來當了一下雅婷逐字稿,邊聽邊記錄了一些自己有聽見的重點,這些重點筆記當晚已經有直接分享於 FB 貼文,本文只是再做一次簡單的校稿與整理。 活動基本資訊 (基本資訊轉貼自活動報名頁面。) 敏捷是這幾年最熱門的話題,Scrum 也是台灣普遍使用的 framework。Scrum Master 這個角色,普遍對他的定位也充滿爭議。感謝 Josh 陳俊樺 佛心對敏捷在台灣社會的發展做了深入研究,並撰述論文發表。 這次 Agile Talks 論壇除了邀請 Josh,還邀請幾位 Scrum Master 一起來對話,來聽聽彼此的看法與研究。 與談人 敏捷實踐者 敏捷行者 / Josh 陳俊樺 魚尾 Agile Coach / Russi 王泰瑞 Jason 廖健勝 主持人 敏捷總舵主 / Hermes 張昀煒 直播影片網址 https://www.youtube.com/watch?v=UPNqzuJnPSQ 筆記 Q: 使用看板方法是否需要 Scrum Master? 要,因為看板有更多的資訊流與資訊需要解讀,如果有一個角色可以適度的幫助大家解讀,令團隊能有所改善是好的。(謎之音:但這樣的角色還叫做 Scrum Master 嗎?) Q: Scrum 的正確性? Russi:還是應該要回到為何要做這件事? 為了團隊自主管理、有助於團隊實現商業價值、對齊商業指標、響應變化的能力⋯⋯。敏捷可以運用在更多領域。 王泰瑞:組織有響應變化的能力不等於組織有能力賺比較多的錢。我當初認為 Scrum 是用來幫助團隊可以不再受到 Waterfall 的壓榨,避免不懂的人只知道壓時程。因為有很多時候,不懂技術、工程的人只懂的壓時程,這當然也不是他的錯,因為他有他要負責的考量。我認為 Scrum 只有適合不適合,沒有正確不正確。Scrum 是一種可以幫助團隊成長的框架。...

November 21, 2021 · Cheng Wei Chen

Agile Tour Taipei 2015 筆記與心得(五)| Scrum Estimation Model - Joey Chen (91)

在得到「欠筆記文欠過年」的成就之後,硬是擠出一個下午的時間,終於整理完 Agile Tour Taipei 2015 最後一場議程的筆記,壓軸場當然是非同小可,是由絕無冷場的 91 哥為大家帶來「Scrum Estimation Model」這個題目。 同系列所有文章可以點此連結前往《Agile Tour Taipei 2015 筆記與心得》 因為欠筆記文欠太久,91 哥早已將他分享的內容整理成兩篇文章: Scrum Estimation - 如何估算專案時程 Scrum Estimation - Scrum Estimation Model 既然講者都已經把內容寫成文章了,所以老實說我有沒有寫這篇筆記文好像也沒差,那本文就此結束吧。(揍飛) 筆記文由此開始,在一開場 91 哥就直接先用他自己今天的簡報總頁數當作範例,點出本場主題的三大關鍵重點「範圍」、「 時程」與「速率」。 範圍 = 簡報總頁數 時程 = 演講可用的時間 速率 = 每分鐘要講幾頁(才能不超時將內容講完) 基本上這是簡單的數學計算,由「範圍」除以「時程」可得出「速率」,反之你也可以由「範圍」除以「速率」得出「時程」,又或是由「時程」與「速率」得出「範圍」,總之這三個重點是彼此互相關聯的。 但實際上講者講話的速率有限,不可能提升至預期的速率,因此勢必只能延後結束時間或減少簡報頁數。這個開場白其實直接就比喻了專案執行的情況,因為專案執行時也同樣是在「範圍」、「 時程」與「速率」中不斷地協調。 透過開場白 91 哥很快的在聽眾們的心中埋下了「範圍」、「時程」與「速率」的基本概念,整場分享即是完全圍繞著這三大關鍵。 接著 91 哥繼續用「兩個人決定步行前往探視朋友的一段旅程」比喻說明了在專案執行中常見會導致「專案延誤」的意外狀況。 在這個小故事中一樣有「範圍」、「 時程」與「速率」: 範圍 = 交通距離 時程 = 與朋友約定的到達時間 速率 = 一天要移動多少距離 於是隨著小故事的發展,每一天都有不同的意外,但因為「範圍 = 交通距離」是無法變更的(但有可能會錯估),於是故事主角每天都在「 時程」與「速率」中不斷的協調與修正,嘗試要完成這趟旅程。旅程中就發生了各種突發狀況,例如: 錯估交通距離 = 錯估專案範圍 受傷導致行進速度變慢 = 開發速率下降 打電話通知朋友會晚幾天到達 = 嘗試延後 Due Time ⋯⋯等等 藉此案例 91哥再次強調這場分享就是一直圍繞在「範圍」、「時程」與「速率」這三個重點打轉,換句話說這場分享重點就是在講 Burn Down Chart 燃盡圖。 那「範圍」到底是啥?範圍就是專案要完成的工作項目有哪些,你的 product backlog 有多少,估算出來的 story point 有多少。...

February 29, 2016 · Cheng Wei Chen