Light anddarkofagileprojectteam.agile neihu
•Download as PPTX, PDF•
3 likes•158 views
Agile_Neihu_Sprint_27 敏捷專案團隊的光明與黑暗
More Related Content
What's hot
Similar to Light anddarkofagileprojectteam.agile neihu
Similar to Light anddarkofagileprojectteam.agile neihu (20)
Light anddarkofagileprojectteam.agile neihu
- 1. 敏捷專案團隊的 光明與黑暗 Roy Wu, Agile Neihu, 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
- 6. 前後差異 2014 2019 工作型態 孤軍奮戰 團隊協作 工作分派 指派工作 認領工作 責任歸屬 1人背1~2個 專案 共同開發維護所有專案 溝通時機 規格文件、 功能驗收 Scrum Events、Pair programing roywu@cloudybay.com.tw 6
- 12. 改變，從自己開始 • 個人看板 • 定期參加社群 • 嘗試軟體工程實踐 • Show. Don’t tell. 圖片出處：http://hungernwnc.org/blog/2016/06/07/take-action-child-nutrition-reauthorization/ roywu@cloudybay.com.tw 12
- 15. 團隊看板 (半年) • 分析 設計 開發 測試 部署 • 分析設計幾乎都被跳過 • 文件或研究型工作項目不適用 • 工作拆分時機點抓不準 • WIP 很難訂 roywu@cloudybay.com.tw 15
- 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
- 21. 邁向自組織化 • 加入Refinement、Planning、Review • 讓成員自己認領 Task，大家一起維護專案 • Pair programming • 設置白板牆，讓 idea 發想與討論自然發生 • Scrum 看板電子化，讓資訊流與管理更輕鬆 • 透過日常工作體驗，導入敏捷思維 roywu@cloudybay.com.tw 21
- 25. 前後差異 2014 2019 工作型態 孤軍奮戰 團隊協作 工作分派 指派工作 認領工作 責任歸屬 1人背1~2個 專案 共同開發維護所有專案 溝通時機 規格文件 Scrum Events、Pair programing roywu@cloudybay.com.tw 25
- 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 看板很重要 • 私心覺得看板方法也許比較合適
- 34. roywu@cloudybay.com.tw 34 Q3. 沒有人當SM，Agile mindset 難建立 • 資源不足時自己下海當那個人，不用明說我就是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 回報，依照嚴重程度與價值劃分優先級
- 38. 專案團隊中，敏捷無法著力的地方 roywu@cloudybay.com.tw 38 • 隕石式決策開發 • 影響合作夥伴的工作模式 • 範疇與時程硬梆梆的專案 • 面對客戶插單 • 資源問題，角色需多功能 圖片出處：http://eiki.hatenablog.jp/entry/meteo_fall
- 39. 轉型後的組織 未來何去何從 敏捷這條路 並沒有盡頭 保持微小的 嘗試，持續 改善 讓團隊擁有 AGILE 的 DNA 找到下一個 火種 以終為始 roywu@cloudybay.com.tw 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
Editor's Notes
- 當年，我們公司發生一些事情，很多人在那時候離開了，剩下5個人，還是要維護與開發專案，所以面臨著嚴重的生存壓力
- 當時花很多時間學軟體工程，希望程式能夠寫得更好更有品質，上面這些軟體工程經典，都提到了一個開發方法，敏捷式開發
- 學習軟體工程，上網查資料一定會查到台灣的 pattern 大師 Teddy，泰迪軟體有組織一個技術社群叫 C.C.Agile，所以抱持著去觀摩學習的心態，參加社群，也順便看看敏捷到底在幹什麼
- 我選擇看板方法是因為它可以一個人跑，加上當時社群一直提到看板方法、限制理論等等，所以想先從自己開始玩玩看
- 當時我們的技術經理發現到我在玩看板方法，希望能在公司內做簡單分享 在當年結束的內部會議，決定開始改變公司的工作模式
- 我揣摩一下上層的想法，其實上層一直都有跑敏捷想法，但不知如何下手、如何推動，因為身上背負的責任太重，公司的生存啊，所以當時不太有能力再背負引領組織變革這件事，所以交付給我，讓我來推動變革，他們則在我旁邊協助。
- 當時用了狂熱者心態，基本教義優先，沒辦法接受滿滿的scrum but，導致推動寸步難行. 需要時間導正心態 小劇場：大家都是 do agile，根本不是 being agile
- 自古以來，文人相輕，覺得自己的解法才是最好的，不願意call for help 加上大多工程師個性比較內斂安靜，這個活動讓工程師願意說出口，跟大家同步資訊，是個很棒的改變
- Scrum 看板電子化是我們的突破，將看得見摸得到的看板移動到雲端上，是經過大家多次討論後決定的，畢竟人還是喜歡看得見摸的到的東西 透過日常工作體驗成功與失敗，從每次回顧會議與分享會中，導入敏捷思維 花費時間很長，中間不斷持續檢視與調整，大概用了2年才比較有自組織的樣子出來
- 價值驅動，因為團隊性質的關係，每個 sprint 依照經營策略調整專案執行優先序，找到更好更有價值的idea時，就能動態調整，儘早執行
- 這邊列出三項我們在轉型中遇到的問題，以下逐一分享
- 1. 引導者需要couch大家敏捷的基本要素，讓大家理解站立會議的目的 2. 站立會議是為了檢視調整與同步訊息，但過去的週會月會等也是類似的功能，所以建議領導者應該取消類似的會議
- 先建立實體看板
- 不要太急著想要成果，全面導入容易造成全面毀滅
- 上面這些工具是目前我們有在用，甚至天天用的 大部分都是從社群偷來的 idea，現在持續擴充中