2017-02-09

[筆記] 從限制理論看敏捷開發

今天參加 Agile Meetup 2017/02 聚會
主題是從限制理論看敏捷開發
講者是 William Yeh

我就來提提其中幾個點吧

[經驗主義 vs 理性主義]

敏捷的背後理論主要來自經驗主義
講求根據自身經驗去做修正
所以大神說的話 未必能套用在自己的團隊
但是經驗主義的極端就是 懷疑論
懷疑一切理論
懷疑一切教條

反觀 理性主義
用邏輯思考去推理什麼才是對的
所以理性主義的極端就是獨斷

敏捷的鼓勵失敗 從錯誤中學習 看似Open mind
但其實我也很擔心 Team或是老闆對敏捷失去信心及耐心

所以如果用理性主義去推理經驗主義的可行性
可以降低我們導入敏捷的錯誤機率

[樂高限制遊戲 workshop]

第一階段
假設有4個member 要實作6個feature
假設每個feature不可分割
如何在最短時間做完6個feature ?

這階段用排列組合就能完成了
我們直接跳到第二階段

第二階段
假設member技能不可轉移
於是工作開始出現互等的現象
這真的超符合現實情況的
QA 要等Developer 寫完程式 
Backend 要等 Frontend
Developer  要等 UX 畫出mockup

所以在planning時 其實不單單只是把點數相加
還要考慮各個工作的Dependency

[瓶頸處理9原則]
(4) 關鍵地方有損失 代表整個專案的損失
(5) 絕對不可以浪費瓶頸的時間
      e.g. 插件 不能讓現在處理瓶頸的人來處理
(9) 管理重點要在流量 非個別的產能
      有點像Kanban的WIP 要盡量流動

我這邊就不一一列了
但最主要就是找出 “瓶頸”
然後你就會知道 處理瓶頸是最重要的事
瓶頸才是影響專案進度的地方
其他地方就算閒置 就算delay 也不影響專案進度

[聚焦五步驟]

1. Identify 確認瓶頸
2. Exploit 決定如何充分利用瓶頸
3. Subordinate 其他一切遷就以上決定
4. Elevate 鬆綁制約因素 (學新技術或是加人)
5. Prevent inertia 避免惰性 回到步驟一 聚焦持續改進

根據William提的例子
假設瓶頸前期在UX 後期在Tester
那麼前期 其他人在閒置的時候
我們決定充分利用這個瓶頸 
於是只是調整大家的工作習慣
讓Developer 與QA提早與UX一起討論mockup
為了讓瓶頸專心處理
如果此時有插件進來 讓別人去處理
行有餘力再來思考 投資member 讓更多member學到UX 
能夠幫忙cover 瓶頸的部分

其實這個例子讓我想到之前在CM的時候
一開始我們也是在Sprint中設很嚴謹的 設計->開發->測試
原本也是有互等的情況
但後來我們在設計階段 就將Developer與QA一起來拉進來與UX一起討論SPEC
不僅釐清需求也有助於縮短開發與測試的時間

[總結]
用理性主義去推理經驗主義的可行性
來試試看 TOC 吧

0 意見: