思考傳統利用甘特圖作為軟體開發專案計畫的盲點

1. 敏捷與專案計畫
為什麼甘特圖幫不了軟體專案？
1

2. 甘特圖的問題 -未蒙其利，先受其害
2
如果只是將工作跟時間排列呈現，其實沒有真的需要用甘特圖
只是讓計畫看起來更專業而已

3. 甘特圖最強的應用是
 要徑 (critical path) 的尋找 (包含資源的分配)
 最長的路徑
3
3
B
F
C
A
I
E
DG H
H
28
166,194
J
J
45
149,194
E
21
173,194
90,105
90,115
90,120
105,110
115,129 129,149
149,170
149,177
149,194
D
20
0,90
129,149
G
14
115,129
I
30
119,149
A
90
C
5
110,115B
15
95,110
F
25
90, 1150,90

4. 軟體開發專案的要徑 (critical path)是？
4
如果考慮退回修正的話，是無限長

5. 但我們做計畫時腦袋想的卻是
 最短路徑-> 任何一個工作項目延遲就會造成專案
的延遲
5

6. 6
不修正才是例外
 軟體開發唯一不變的事情就是改變，所以軟體專
案的成功率才會那麼低

7. 有經驗的 PM 會在專案中放入緩衝
 如果把每個專案的完工時間，在計畫的時候都提
前一個月，這樣是不是就能夠避免延遲？
 問題是有可能專案時程跟資源根本沒有緩衝的空
間，已經需要加班才能完成，不能也非不想也
 計畫寫的漂亮不代表可以執行
7

8. 再來看看不確定角錐，其實也有提早完成的可能啊?
8

9. 但問題是人性在估算時的選擇，你會選擇什麼樣的預估？
9
非常可能會高估
因延遲會受到責備

10. 根據常態分配，有提早有延遲，最後還是會打平啊
10

11. 一般專案管理的建議作法
11

12. Plan Driven 的後遺症 – TOC 限制理論
 要求準時完成一個專案
 產生一個計畫 (可能有很大的誤差)
 要求每一個工作都能夠準時 <- 準交率 KPI
 每一個工作都能準時 -> 專案就能準時 ？
 人的行為
 為每一個工作都留下緩衝時間
 每一個工作都會花光緩衝時間，就算它比預估要早 4 倍完成
 原本可作為整個專案的緩衝時間消失 -> 任何一個工作發生問題就
造成專案的 Delay
 時間不夠時，先有做完就好
 產生技術債，造成專案後期的延誤
 一直補洞一直到無法補時才爆出來
 一直加班到專案結束或中途就離職

13. 把整個專案時間切成一小段一小段
每一段都盡力衝刺
13

14. 再把高風險，高價值的東西先做

15. 美國聯邦調查局(FBI)案例
 $575 million dollars wasted on the first two
attempts at the project
 Scrum Studio was set up in the basement of the
Hoover Building
 Staff reduced from 400 to 40, and in 1 year
and $30 million, they were code complete, at
a cost savings of more than 90 percent
 If an organization like the FBI can do this, why
can’t yours?
15
http://www.scrumcasestudies.com/fbi/

16. 另一種重工 – 錯誤的開發順序
 先開發底層？共用 ? -> 想像中的共用是很脆弱的
 共用應該是在系統發展過程中逐漸建構完成的
16
A B
C D E
F
G

17. 切割/分工 過細
 每一塊由不同的人來開發 -> 錯誤的分工、無法補
位
17
A B
C D E
F
G

18. Value driven
plan driven
18
或是子系統最後要串在一起時才出問題

19. Scrum 的作法
 在每一個週期中，由 User Story 出發，從完成到
可用的成果
 讓會出問題的地方在早期就被面對與處理
 團隊成員各有專長，但也有處理其他工作的能力
 如：分析、設計、開發、測試等
 在週期中，不再做工作的時程安排，做完就可立
即認領另一個工作，並每日同步溝通
19

20. 參考資料
 Scrum
 Scrum 官方指南
 Scrum 懶人包
 兩萬字談敏捷開發
 其他
 重新發明組織演講 – 無主管組織
 工具：Slack - 找到正確的團隊溝通之道
20

21. 謝謝聆聽
Q&A
www.gss.com.tw www.gsscloud.com