Download to read offline
Uploaded by柏漢 吳
Light anddarkofagileprojectteam.agile neihu
本文件介绍了敏捷转型的旅程，包括转型的改变、带来的益处、所遇到的挑战以及团队在敏捷方法应用中的困难。作者分享了自己从传统开发方式到敏捷式开发的经验，强调了持续改进和团队协作的重要性。最后，表达了敏捷转型的过程并没有尽头，需要保持适应性和积极的尝试。
Light anddarkofagileprojectteam.agile neihu
- 1. 敏捷專案團隊的 光明與黑暗 Roy Wu, AgileNeihu, 2019.7.9
- 2. Who am I •Roy Wu @ CloudyBay • Experience • 2013 - 2014: 韌體工程師 • 2014 - current: 全端工程師 • 2016 - current: 流程改善員 • 2018 - current: 專案管理員 • Certifications • Certified ScrumMaster • Interests • 閱讀 ＆ 學習 • 足球 roywu@cloudybay.com.tw 2
- 3. 敏捷組織轉型之旅故事 敏捷轉型帶來的變化與好處 轉型中遇到的困難跟問題 專案團隊中，敏捷無法著力的地方 轉型後的組織未來何去何從 Agenda roywu@cloudybay.com.tw 3
- 4.
- 5.
- 6. 前後差異 2014 2019 工作型態 孤軍奮戰團隊協作 工作分派 指派工作 認領工作 責任歸屬 1人背1~2個 專案 共同開發維護所有專案 溝通時機 規格文件、 功能驗收 Scrum Events、Pair programing roywu@cloudybay.com.tw 6
- 7.
- 8.
- 9.
- 10.
- 11.
- 12. 改變，從自己開始 • 個人看板 • 定期參加社群 •嘗試軟體工程實踐 • Show. Don’t tell. 圖片出處：http://hungernwnc.org/blog/2016/06/07/take-action-child-nutrition-reauthorization/ roywu@cloudybay.com.tw 12
- 13.
- 14.
- 15. 團隊看板 (半年) • 分析設計 開發 測試 部署 • 分析設計幾乎都被跳過 • 文件或研究型工作項目不適用 • 工作拆分時機點抓不準 • WIP 很難訂 roywu@cloudybay.com.tw 15
- 16.
- 17. SCRUM 起步走 –Baby steps • 體驗敏捷在做什麼 • 每日站立會議 • 回顧會議 • Scrum 看板 • todo – doing – testing – done 圖片出處：https://innovationmanagement.se/2013/03/08/implementing-ideas-baby-steps/ roywu@cloudybay.com.tw 17
- 18. 每日站立會議 • 嘗試敏捷的第一步 • 建立透明化與團隊安全感 •讓工程師們練習說說話 • 檢視與調整工作 • Call for help roywu@cloudybay.com.tw 18
- 19. 回顧會議 • 改善的契機 • Action不分好壞，try it. • 打造輕鬆、不嚴肅的環境 • 每個人都是平等的 • 食物可以促進溝通 roywu@cloudybay.com.tw 19
- 20.
- 21. 邁向自組織化 • 加入Refinement、Planning、Review • 讓成員自己認領Task，大家一起維護專案 • Pair programming • 設置白板牆，讓 idea 發想與討論自然發生 • Scrum 看板電子化，讓資訊流與管理更輕鬆 • 透過日常工作體驗，導入敏捷思維 roywu@cloudybay.com.tw 21
- 22.
- 23.
- 24.
- 25. 前後差異 2014 2019 工作型態 孤軍奮戰團隊協作 工作分派 指派工作 認領工作 責任歸屬 1人背1~2個 專案 共同開發維護所有專案 溝通時機 規格文件 Scrum Events、Pair programing roywu@cloudybay.com.tw 25
- 26.
- 27. 經營層面 • 價值驅動，每個 Sprint依照經營策略調整 • 案子變多，但是花在開發時間變短，重做次數減少 團隊層面 • 資訊透明，團隊成員彼此信賴 • 組隊寫 Code，工程師交流與學習機會變多 • 團隊成員互相支援，休假壓力變小 roywu@cloudybay.com.tw 27
- 28. roywu@cloudybay.com.tw 28 轉型中遇到的困難跟問題 1.站立會議好像流水帳，不想說太多 2. 多專案跑 Scrum，適合嗎 3. 沒有SM，Agile mindset 難建立 4. 該怎樣帶領敏捷團隊 5. 敏捷開發後的維運如何進行
- 29. roywu@cloudybay.com.tw 29 Q1. 站立會議好像流水帳，不想說太多 •讓大家理解站立會議的目的 • 取消類似的會議 • 強調說出阻礙與困難的重要性 • 說說跟別人有關的資訊
- 30. roywu@cloudybay.com.tw 30 Q2. 多專案跑scrum，適合嗎 • 首先要有夠厲害的PO (PM) • context switch 很重，團隊需要很強的適應力 • 設計出好的 Scrum 看板很重要 • 私心覺得看板方法也許比較合適
- 31.
- 32.
- 33.
- 34. roywu@cloudybay.com.tw 34 Q3. 沒有人當SM，Agilemindset 難建立 • 資源不足時自己下海當那個人，不用明說我就是SM • 透過分享會與回顧會議，藉此傳教、Coaching • 鼓勵成員參加社群，獎勵、補助、拉人一起去 • 找到敏捷的火種
- 35. roywu@cloudybay.com.tw 35 Q4.該怎樣帶領敏捷團隊 • 首先，領導層的理解與支持是絕對重要的 •先不要有過多的名詞，用我們團隊內常用的名詞代替 • 建立一個安全可以說真話的環境 • 透過不斷的迭代的 Take Action，大家一起改善 • 用開放的態度面對成員的疑問與質疑
- 36. roywu@cloudybay.com.tw 36 Q5.敏捷開發後的維運如何進行 • 由於團隊性質的關係，維運大多交由甲方處理 •公司自己的專案，建立 CI / CD 機制，監控系統 • 維運工作由成員自主認領 • 由PO決定 Release 時機，工程師們建立 Release plan • 遇到 Bug 回報，依照嚴重程度與價值劃分優先級
- 37.
- 38. 專案團隊中，敏捷無法著力的地方 roywu@cloudybay.com.tw 38 • 隕石式決策開發 •影響合作夥伴的工作模式 • 範疇與時程硬梆梆的專案 • 面對客戶插單 • 資源問題，角色需多功能 圖片出處：http://eiki.hatenablog.jp/entry/meteo_fall
- 39.
- 40. roywu@cloudybay.com.tw 40 Summary • 勇敢跨出舒適圈，世界會不一樣 •改變其他人的思維困難，所以先改變自己吧， Take Action！ • 敏捷轉型，領導層的理解與支持 • 保持微小的嘗試，持續改善與前進，切勿躁進 • 敏捷不是銀子彈，有些事需要靠更多技能才能處理 • 以終為始，敏捷只是過程，能夠如期如質如預算的交付才是 最重要的 ($$$)
- 41. roywu@cloudybay.com.tw 41 加碼送 -敏捷工具箱🐶 • Tools • Time Box • 一音風鈴 • 故事骰 • Overcooked! • 白板牆 • Retrospective • Brainstorming • 大船進港 • ORID • 1-2-4-ALL • Planning • 估點數系統 • 自製雲灣 Trello Board • 需求探索 • USM • IM
- 42.
Editor's Notes
- #8 當年，我們公司發生一些事情，很多人在那時候離開了，剩下5個人，還是要維護與開發專案，所以面臨著嚴重的生存壓力
- #9 當時花很多時間學軟體工程，希望程式能夠寫得更好更有品質，上面這些軟體工程經典，都提到了一個開發方法，敏捷式開發
- #11 學習軟體工程，上網查資料一定會查到台灣的 pattern 大師 Teddy，泰迪軟體有組織一個技術社群叫 C.C.Agile，所以抱持著去觀摩學習的心態，參加社群，也順便看看敏捷到底在幹什麼
- #13 我選擇看板方法是因為它可以一個人跑，加上當時社群一直提到看板方法、限制理論等等，所以想先從自己開始玩玩看
- #14 當時我們的技術經理發現到我在玩看板方法，希望能在公司內做簡單分享 在當年結束的內部會議，決定開始改變公司的工作模式
- #15 我揣摩一下上層的想法，其實上層一直都有跑敏捷想法，但不知如何下手、如何推動，因為身上背負的責任太重，公司的生存啊，所以當時不太有能力再背負引領組織變革這件事，所以交付給我，讓我來推動變革，他們則在我旁邊協助。
- #18 當時用了狂熱者心態，基本教義優先，沒辦法接受滿滿的scrum but，導致推動寸步難行. 需要時間導正心態 小劇場：大家都是 do agile，根本不是 being agile
- #19 自古以來，文人相輕，覺得自己的解法才是最好的，不願意call for help 加上大多工程師個性比較內斂安靜，這個活動讓工程師願意說出口，跟大家同步資訊，是個很棒的改變
- #22 Scrum 看板電子化是我們的突破，將看得見摸得到的看板移動到雲端上，是經過大家多次討論後決定的，畢竟人還是喜歡看得見摸的到的東西 透過日常工作體驗成功與失敗，從每次回顧會議與分享會中，導入敏捷思維 花費時間很長，中間不斷持續檢視與調整，大概用了2年才比較有自組織的樣子出來
- #28 價值驅動，因為團隊性質的關係，每個 sprint 依照經營策略調整專案執行優先序，找到更好更有價值的idea時，就能動態調整，儘早執行
- #29 這邊列出三項我們在轉型中遇到的問題，以下逐一分享
- #30 1. 引導者需要couch大家敏捷的基本要素，讓大家理解站立會議的目的 2. 站立會議是為了檢視調整與同步訊息，但過去的週會月會等也是類似的功能，所以建議領導者應該取消類似的會議
- #31 先建立實體看板
- #36 不要太急著想要成果，全面導入容易造成全面毀滅
- #42 上面這些工具是目前我們有在用，甚至天天用的 大部分都是從社群偷來的 idea，現在持續擴充中