DevOpsDays Taipei 2017 敏捷思維分享

DevOpsDays Taipei 2017 議程分享
afu @ PIXNET {事業部, 行銷部, 經營部, 電商部, 廣告部} 2017.10.13

Transcript

1. DevOpsDays Taipei 2017 敏捷思維分享 研發中心前端組 Afu 2017.10.13 PIXNET 會議室
3. Agenda - 如何讓老闆願意接受敏捷？ - 從童軍健行看五步驟聚焦法
4. 怎麼讓老闆願意接受敏捷？ 陳仕傑(91) / Odd-e Agile Coach
5. 老闆在乎什麼 - 生存能力 • 生存能力不在乎你的 power 有多大， 而是你的生存能力有多強 • 恐龍 vs. 蟑螂
6. 複雜領域圖 (Stacy Complexity Matrix) • 把事物分為四個領域： 簡單、繁雜、複雜、混沌 • 軟體開發偏向複雜— 需求總是不確定 Image Credit: https://yanado.com/blog/top-4-project-management-methodologies-and-when-to-use-them/
7. 老闆在乎什麼 - 獲利能力 • 卓越/ 創造機會 有沒有能力創造獲利的機會 如果等待機會，要跟人家搶，要搶得贏人家，最後可能搶輸人家 • 優秀 / 掌握機會 • 平庸 / 等待機會 • 遲鈍 / 錯失機會
8. 獲利能力 / 價值 • 好的 Product Backlog 由價值排序 • Priority 是最大問題，有些需求端開的 issue 總是最緊急的 • 所有的需求都應該用價值來排序， 這是很重要的事情，最好是能轉換成收益 ◦ 絕大多的團隊是按照時程來排序 Image Credit: http://www.informit.com/articles/article.aspx?p=1928232&seqNum=3
9. 開發方式的迷思 Produce BackIog, Values Item1, $500 Item2, $400 Item3, $300 Item4, $200 Item5, $100 五個需求，價值依序是 $500 ~ $100
10. 開發方式的迷思 五個需求，有五個人可以做，團隊會怎麼執行？ 1. 第一種 集中火力，永遠都是五個人作循序的 item 2. 第二種有沒有很熟？ 平行開發（併行開發） 每個人各自作一個 • 20 天 v.s. 15 天
11. 開發方式的迷思 20天 vs 15天，PM 會選哪一個？ 結果：通常選 15 天的平行開發 PM 金三角：時程 品質 成本 … ? Image Credit: https://www.projectup.net/article/view/id/309
12. 開發方式的迷思 這兩個差異在於『能多快的賺到錢？』 • 第一個 item 做完就可以上線！ • 附帶一提，作產品的是指上去後每天可以幫你賺錢的這種，不是 作專案的 集中火力方式，第九天開始，每天賺的是 900 ！
13. 開發方式的迷思 • 儘快交付 -> 引發變化 • 在乎錢的話，上面的比較，幾乎是兩倍 • 敏捷不是加速完成 • 敏捷可以「快一點」賺到錢 • 敏捷在講的是價值高的需求先推上線 • 早餐店想賣很多東西，全部學完再開店嗎？
14. • 假如第七天市場發生重大變化 ◦ 當你發現做的東西是垃圾，市場不接受， item2, 3, 4, 5 還要作 嗎？ 敏捷是提升應變能力
15. Recap • 敏捷其實是反應能力，因應與擁抱變化 • 價值才是順序的根源 • 有多早能賺到第一筆錢是很重要的 • 減少半成品，半成品是競爭力很大的殺手 • 目標只有一個：把 lead time (前置作業) 最小化，提升反應速度
16. 持續改善：找出流程中的瓶頸與浪費 劉珮茹(Erica Liu) / 泰迪軟體 Agile Coach
17. 你會怎麼做？ • 你是童軍健行團的領隊，唯一的大人 ◦ 要帶 15 位小朋友在 5 個小時內抵達 15 公里外的營地 • 經過 1 公里後，你發現進度遠遠落後。 ◦ 隊伍也拉得很長 ◦ 有個走在隊伍中間的小朋友「賀比」，步伐特別慢 ◦ 賀比的後面還塞住了很多人 • 再不走快點，就來不及在天黑前抵達營地
18. 你會怎麼做？ • A：請中等腳程的朗尼拿地圖帶隊 ◦ 自己到最後壓陣，照顧到整個團隊，確保不會 有小朋友落單迷路 • B：讓每位小朋友依自己速度前進，在終點集合 • C：由腳程最慢的賀比領隊，手牽手大家一起慢 慢走
19. A：請中等腳程朗尼帶隊 • 每當有人走得比朗尼慢的時候，隊伍就拉長 ◦ 朗尼背後的大衛綁鞋帶 ◦ 若其他人跨出的步伐比朗尼短，隊伍的長度也會受影響 • 慢的人快不起來：負面偏差累積越來越多，落後的孩子沒有 後備產能彌補落後的進度 • 不能讓人力閒置，所以總是不斷趕路
20. B：讓每位小朋友依自己速度前進 • 隊伍間隔急速擴大，自行形成了新的行進順序 • 沒有一個人緊貼著別人的腳跟走路 • 賀比落後到最後面了（領隊前方） • 每個人都找到了自己理想的速度 ＝ 沒有人有空閒的時間
21. C：由腳程最慢的賀比領隊 • 其他人調整背包或綁鞋帶都能跟上隊伍 • 走得快的人開始抱怨 ◦ 領隊提示大家想辦法幫賀比走快一點 ◦ 賀比的背包非常大，裝了許多東西 • 大家分擔賀比的背包物品 ◦ 賀比前進的速度快多了
22. 回顧童軍健行的目標 • 健行是要一起抵達目的地 • 走得最慢的人決定最終產出（每小時步行速度） • 讓最慢的人帶頭，其他人才有鬆弛時間（Slack Time)，有機 會去發現團隊問題，拖慢速度的人發生什麼事？
23. 五步驟聚焦法
24. • 賀比與前方有一大段距離，他的後面累積很多人 • 技術/設計等待 Wireframe / User Story • 前端等待 UI 、後端 API • 測試等待前後端串接 • 測試等待前後端修復 Bug • 經營端等待開發團隊上線 • ... 不同的角色在不同的時間成為了瓶頸 步驟一，辨識 (Identify) 系統的瓶頸
25. • 有待辦事項積壓可能就存在瓶頸 ◦ 瓶頸可以是任何積壓的工作（進行中＆尚未開始） • 瓶頸的上游堆滿工作，但下游閒置 • 看看工作堆在誰那裡，下游就是空的 如何辨識瓶頸
26. 找到瓶頸，然後加人與加資源嗎？
27. • OO團隊的產能潛在地決定整個專案的交付速度 • 「在一個時程已經落後的軟體專案中增加人手，只會更加落後」 - 人月神話 • 立即加人花錢又花時間，先找到充分利用瓶頸資源能力的方 法 • 怎麼利用現有的資源？ 加人與加資源？ 人月神話書摘：https://www.slideshare.net/evave/ss-62268917 Ruddy 老師談人月神話： https://ruddyblog.wordpress.com/2014/09/29/正確提升團隊開發效能的方法 /
28. • 由賀比領隊，任何人都無法影響賀比前進（例如綁鞋帶或休息） • 讓瓶頸資源保持繁忙，上游一直有任務流向瓶頸 • 減少或消除對瓶頸資源的打擾，減少瓶頸的非增值活動 • 解決瓶頸資源工作的阻礙：例如每日站會 • 排優先級 步驟二，決定如何最大化挖掘 (Exploit) 瓶頸
29. • 手牽手，大家不能走太快而超越賀比， 聚在一塊使隊伍不會拉長。 • 所有在非瓶頸處的改進都是假的 • 透明化：使團隊感知到瓶頸 以及阻礙流動對整個系統造成的影響， 才會樂於聚在一起解決問題 • 可利用視覺化的團隊看板喚起意識 步驟三，全力配合瓶頸 Image Credit: http://www.strongandagile.co.uk/index.php/the-hourglass-scrumban-board/
30. • 眾人分攤賀比負擔，提升整體速度 • 非瓶頸資源跨職能，幫助瓶頸 ◦ OO 人員也可以作 XX 人員的工作 ◦ 有時候團隊成員沒有多技巧能力，所以不一定有辦法達成 • 自動化瓶頸工作 ◦ 長遠來看，投資在自動化上也是一種突破策略 步驟四，突破系統的瓶頸。 Image Credit: 转型敏捷，团队需要做哪些准备？
31. • 找下一個瓶頸 ◦ 規模越大、職能單位愈多的公司，瓶頸也會增加 步驟五，避免慣性， 假如步驟四打破了原有的瓶頸，那麼就回到步驟一 Image Credit: http://kojenchieh.pixnet.net/blog/post/457332635
32. 總結 敏捷思維： 可以幫你「快一點」賺到錢，跟專案完成是兩件事，專案完成是有好多好多需求 • 價值高的需求先推上線 • 價值優先，儘快交付，引發變化 TOC 五步驟聚焦法：找出瓶頸，全力配合不浪費，鬆綁瓶頸，找下一個瓶頸
33. 推薦閱讀 • DevOpsDay2017 大會第一天共筆 (共筆人：Afu, Anna, 哲任, Dennis, Win) • 目標：簡單有效的常識管理 • 鳳凰專案：看IT部門如何讓公司從谷底翻身的傳奇故事 • 人月神話書摘 • Ruddy 老師談人月神話 • 挖個敏捷坑給 HR • TOC 瓶頸處理九大原則
34. 感謝聆聽