Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

那些失敗教會我的事

117 visualizaciones

Publicado el

Agile Summit 2019

Publicado en: Ingeniería
  • Sé el primero en comentar

那些失敗教會我的事

  1. 1. 那些失敗教會我的事 Kuma Syu
  2. 2. About me…? Kuma Syu Java Lecturer Developer / Testing Addict / Blogger --- Lazy, Bad tempered Hate to do coding Hate ugly codes...
  3. 3. Software Engineering to Me...
  4. 4. Outline 五個真實發生的小故事、失敗的痛,以及我學會的事 給有志一同者的三個建議 給RD的五個建議 Q&A
  5. 5. 故事一 - 瞎子摸象的scrum
  6. 6. 故事要從那一晚說起…
  7. 7. 那就來搞Scrum吧! Scrum…感覺按表操課而已嘛,沒什麼學問,簡單! 書上說要cross-functional,那抓個QA進團隊吧 Enya身為PM,來當PO…應該差不多吧 Kuma在前公司跑過scrum,那他來當SM吧 那就開始吧!
  8. 8. However... 為什麼…Story永遠做不完 為什麼…站會老是有種例行公事感 為什麼…開的會好像沒什麼用 為什麼…不知道QA能領什麼工作 當團隊在plan時因實作細節起了爭執,而爭執 的兩人包含Scrum Master...
  9. 9. 太挫敗了… 我不是照做了嗎?
  10. 10. 那就讓專業的來吧! 為了不要有廣告嫌疑…
  11. 11. 喔,原來問題出在... 純後端團隊, 又有Unit Test,那QA…? 我們沒搞清楚… 我們要什麼, 我們有什麼, 我們的產品邊界在哪裡, 以及我們還缺什麼! 1/5
  12. 12. 喔,原來問題出在... 草率估算時數, 沒有落實排序, 我們沒搞清楚… 估時數與排序原意是要幫我們解決 什麼問題! 插件原來就有,而我們讓它更加惡 化 2/5
  13. 13. 喔,原來問題出在... 有了PO, 可是老闆還是習慣交代事給「 Team Leader」 PO根本不知道Team在忙什麼 我們沒搞清楚… 在我們的context下,每個角色 應該由誰擔任比較適合! E.x., PM跟PO根本兩碼子事 3/5
  14. 14. 喔,原來問題出在... 當Scrum Master兼任 Developer… 我們沒搞清楚… SM、PO、Team這三個角色重疊時 各會造成什麼樣的混亂! 4/5
  15. 15. 喔,原來問題出在... 當你的站會只是在回答「那三個問 題」!!! 我們沒搞清楚… Scrum各個會議 各自在鎖定什麼目標、 探索什麼範圍、 調適什麼內容! 5/5
  16. 16. 於是我們決定: (3)確實拆分Task、確實估算可用時 間 2週Sprint (5)公開Code Review (6)不管多忙, 都要開回顧會議 (4) 確實討論story狀況,適時調配人力 (2)確實撰寫User Story、慎重排序 (包含急件) (1) 團隊重組 PO、SM、QA
  17. 17. 所以這個故事告訴我們…? 「套用招式 就能解決問題」 花時間進 行會議 壓縮開發 時間 未達預期 效果 應知其所以然
  18. 18. 故事二 - 人生最後一個手動過版
  19. 19. 開始接觸維運,才發現… Admin Server Server 1 Server 2 Server N DB schema migration DB data adjustment Code Settings Settings Settings ... 我的筆電
  20. 20. 一波三折的自動化佈署… 「沒有Force,就沒有問題」 然後Force就來了… 「再撐一週,這週不出事就OK了」 然後就出事了… 總目標是要「一鍵佈署」 (設計對白)
  21. 21. 所以這個故事告訴我們…? 「熟能生巧」 腳本是死的, 人是活的 百密一疏 提早曝險 自動化要趁早
  22. 22. 故事三 - 專才專用的甜蜜陷阱
  23. 23. 團隊End-To-End總戰力 Pair + 學習 適應力 發大財 + 學習意願 個人End-To-End總戰力 End-To-End很重要,這我知道… + + ++ +
  24. 24. 然而有一天,速解從天而降…
  25. 25. 糖衣 團隊End-To-End總戰力 Pair + 學習 適應力 發大財 + 學習意願 專才專用 個人End-To-End總戰力 團隊對自己能力的認知 拉進Sprint的Story 各Component效率 + + ++ + + + + + -
  26. 26. 直到有一天,Force出現了…
  27. 27. 團隊End-To-End總戰力 Pair + 學習 適應力 發大財 + 學習意願 專才專用 個人End-To-End總戰力 團隊對自己能力的認知 拉進Sprint的Story 各Component效率 Delay
  28. 28. 所以這個故事告訴我們…? 「專才專用, 達到最快速度 」 離職 Single Point Failure 「慢慢」讓大 家會的事差少 一點
  29. 29. 故事四 - 這個不用測啦… 為了業務需求,做了某個功能,不出10行 「這段邏輯很簡單,不用測啦…」 為了安全,加了try-catch 「又沒動主邏輯,不用測啦…」 為了需求變更,重複執行數次 「一樣的事重複做而已,不用測啦…」
  30. 30. 直到有一天… 核心業務出了「一次」Exception Exception被catch住了, 沒往外丟 最外層迴圈始終等不到停止條件…
  31. 31. 所以這個故事告訴我們…? 「這裡不太會錯, 不用測啦…」 不以惡小而為 之… 至少「有修改 時」測一下
  32. 32. 故事五 - 都是你們那個什麼破scrum… 課本說:「你要去問客戶要什麼。」 客戶說:「接下來這段時間,我們所有產品裡面就是 A 最重要…」 課本說:「減少浪費,先做最重要的事。」 --- 一如預期… 原定要做三個月的產品,一個半月就做完上線了 開開心心去找客戶,結果… A1 B1 A2 C1 A3 A4 D1 A1 B1 A2 C1 A3 A4 D1A5 A5
  33. 33. 「你們花了我一個半月,只幫我做一個功能喔?」 「你們那個什麼破Scrum,只能開一條產線,這什麼破流程?」
  34. 34. 所以這個故事告訴我們…? 「客戶說重要 ,就是重要」 腦補「客戶 沒說出口的 話」 全部做完才 交付? 了解客戶真正需求 PSPI! PSPI! PSPI!
  35. 35. 給有志一同者的三個額外建議
  36. 36. 每個會議,都有它該有的長相 e.g., 站會…
  37. 37. 不要談Scrum,不要談Agile 你是要解決問題,但一旦你沒有成功,「Scrum」會為你背所有黑鍋! 你是要解決問題,但一旦你沒有成功,「Agile」會為你背所有黑鍋! 想辦法解決問題就好!
  38. 38. 依需要,建立你的技能樹 工作安排不順暢 套用Scrum流程 流程套用效果不好 「Scrum實作班」 回顧會議成效不彰 「回顧會議實作班」 維運做起來不太順暢 「程序員的維運課」 TDD卡卡的 溝通需求不太容易 「CSD」 對後續SM與PO的 培養不得要領 「SCM、SCPO」 想要擴大範圍,把scope放 大到company-wide 「看板方法實戰」 要溝通的對象變多, 內容變複雜了 「系統思考」「ORID」
  39. 39. 給RD的五個建議
  40. 40. 自動化是你的好朋友 1/5
  41. 41. 所有Test中,Unit Test最重要 Unit Test 不是 Test,是「功能的一部份」 一樣要Clean Code、一樣要重構 如此一來「改Test要很久」這件事… 不會是改Production Code猶豫的理由 而「沒時間寫Test」這件事… 根本不應該發生 (謎之聲:「寫快點就好啦!」) 為了不要有廣告嫌疑… 2/5
  42. 42. Pair Programming 是「1 + 1 > 2」的事 Pair Programming TDD SBE 都是你的好朋友 3/5
  43. 43. 不要當「敏捷工程師」 要當「在任何流程中都能發揮專業」的工程師 4/5
  44. 44. 永遠、永遠要避免在Production下手動指令!!! 5/5
  45. 45. 不要誤會了… 老闆不care你敏不敏捷,老闆只care你快不快!

×