社群分享 在瀑布底下玩Scrum

今天很高興被AgileCommunity.tw邀請來跟各位分享一下我們Team的Practice

身在一個大型軟體公司稍微傳統的部門下也是能夠玩SCRUM的
這場sharing將會和大家分享我們在瀑布底下碰到問題之後
如何採用一些SCRUM的Practice以及Tool的協助來幫助我們解決問題

內容包括:
Team Member的緊密配合
如何以JIRA視覺化我們的工作狀態
如何改善Standup Meeting的效率
如何在每次的Sprint結束後都能更進步 - Retrospective Meeting

我的場次被安排在第二場

所以先來聽聽第一場的David怎麼介紹SCRUM

我擷取幾張有趣的部分

敏捷大師們
沒有他們就沒有今天的敏捷
要感謝它們的努力阿~

最強的人不見得是能生存下來的人
但能生存下來的人 一定是最能適應改變的~
我們要有能夠因應改變的能力
所以不要再一直說需求,環境一直變了 因為這些一直在變
我們該改變自己 讓自己能夠適應變化

瀑布式的缺點就是需求到最後才會發現不是User要的
SCRUM的優點就是每個Sprint都能再Review一次需求到底是不是User要的

但是SCRUM的缺點就是沒有工程實踐
才會讓人覺得很難run 沒有效
我覺得真的很有道理 但是SCRUM提供了一個很好的Process
接下來就是團隊的努力了 如果團隊覺得真的需要幾個Practice把事情做好
那我們就把Practice補上吧

成功者會養成開始的習慣
所以聽到什麼 看到什麼 就開始做吧
從自己開始做起

SCRUM真的只是個Framework而已
他建議我們該做什麼 但沒有說要怎麼做
我認為我們應該要先採用Retrospective蒐集一下團隊的想法
當團隊覺得哪邊有問題的時候 SCRUM是否能解決問題?
然後自己想出Practice

了解它 調整它

第二場 - 在瀑布底下玩Scrum

這場我跟大家分享我們Team的Practice

[Team Member的緊密配合]
Group Design
SCRUM的Team很講求跨功能 在我們公司因為分工明確很難達成這一點
但我們透過Group Design 把大家集合在一起討論 設計 思考
透過群體智慧的力量 把Spec確認清楚
基本上我認為這還蠻符合SCRUM大家一起努力打拼的精神

[如何以JIRA視覺化我們的工作狀態]
原本JIRA是一套Bug的tracking system 但我們發現他還有agile board可以用
所以我們就拿來管理開發的工作項目
將我們傳統每個人要填寫的WBS 轉而填到JIRA的ISSUE上
Board仍是沿用我們以前傳統白板的Column
但是我這次新增一個Column - Pending
無論什麼原因 只要你的task是被卡住的 你就放到Pending這個Column
用意是 希望被卡住的東西提早被團隊看到
這樣才能幫忙處理

執行上則是讓Member從過去的便裡貼轉變成JIRA的ISSUE
導入之後的效果蠻不錯的 專案進度公開透明
大家都清楚每個人的進度
甚至還有member反應說 現在他可以知道哪邊稍微落後 他可以主動幫忙

以前的白板便利貼

現在轉變成JIRA上的Board

[如何改善Daily Scrum的效率]
我們團隊是個30人的大團隊
原本的Daily Scrum希望大家怎麼報告呢?

• 昨天做了什麼?
• 今天預計要做什麼?
• 有沒有阻礙?

但是這類型的報告在30人團隊上實行會是個惡夢

SCRUM：用一半的時間做兩倍的事的作者Jeff Sutherland也強調
他覺得理想的方式應該是

團員們圍在一起討論戰術的景象 !!!

所以我們導入JIRA之後 在Daily Scrum的方式就變成了重點報告
我們變成針對Task討論 而不是每個人的進度報告

我們的遊戲規則是這樣
訂一個更新時間 e.g. 中午12:00
我就以這個時間當作分界點 去JIRA上抓每個Column的數據
然後在Daily Scrum前寄出通知信 通知member今天的情況
以及等下那些task要報告

這邊也加入視覺化的效果
列紅字的代表這個task有delay
列黑字的雖然沒有delay
但是他被放到Pending或是新增加到To Do的
也會拿出來討論

我們的白板從滿滿的便利貼，轉而填上目前專案的總體進度資訊；Daily Scrum也更著重於概述需要幫忙的項目並尋求協助。

如此這麼實行下來 Daily Scrum變得更有效率
專案資訊也更透明化
當然Member也能再透過JIRA看到更detail的資訊

[如何在每次的Sprint結束後都能更進步 - Retrospective Meeting]
如果你們還沒導入SCRUM
那我推薦第一個要實行的項目就是Retrospective Meeting了

透過Retrospective Meeting先蒐集大家的想法
我覺得一個重點在於
要大家真的覺得痛 覺得有問題了
我們再來討論要導入什麼Solution來解決

先有問題 再有Solution會比起你硬推Process來的有效喔

最後我跟大家分享幾點心得

從現在開始從自己開始做起吧

樂於分享才會教學相長

一切都以“win-win”的角度切入 要讓member覺得這是對他有幫助的

他才會接受

最後是真的有問題才是有問題 不要硬推 導入注定失敗

如果大家都覺得沒問題 只有你覺得有問題 是誰的問題?

最後送給大家一句話

其實還有更好的作法 只是你還不知道而已