軟體快速開發
軟體快速開發
Rapid Development
http://www.tenlong.com.tw/BookSearch/Search.php?isbn=9861255729&sid=28194
好書一本, 雖然是鳥蛋文魁發行的, 譯文品質說實話也挺糟. 不過Steve McConnell大師還是大師, 好書內容打個八折也還是好書, 不過有能力的人看原文的應該會更好. 書裡寫的那幾個Case Study, 在在讓我想到我現在所處的環境. (上次想到是看到人月神話裡說的"焦油坑").
身為一個品牌公司的RD, 公司制度上比較沒有RD的process, 就算有, 我來了這兩年也沒有被訓練到. 做了幾個Project, 似乎都還靠著"人"的能力來管理整個專案. 沒問題最好, 有問題就得找人跳下去解. 成功是運氣, 失敗是正常, 成功模式無法複製. 整個Schedule只有deadline, 或是幾個milestone, 但schedule怎麼進行, 總是少了一份global view. 需要的時間都是用喊的, 沒有一點理論基礎, 到最後miss deadline, credit愈來愈差. 長久以往, 手邊永遠有做不完的事, 心裡總像是壓了一塊石頭, 都快有憂鬱症, 想去看精神科醫生了.
直到讀了這本書, 感覺又回來了... 雖然還沒有實行, 也不一定有能力在組織中推行. 但隱隱約約中好像看到一線曙光, 也許不會立刻讓整個環境變好, 但總是知道個方向, 怎樣能讓它往好的方向走. 目前擬定的方向很簡單, 只有兩項:
Rapid Development
http://www.tenlong.com.tw/BookSearch/Search.php?isbn=9861255729&sid=28194
好書一本, 雖然是鳥蛋文魁發行的, 譯文品質說實話也挺糟. 不過Steve McConnell大師還是大師, 好書內容打個八折也還是好書, 不過有能力的人看原文的應該會更好. 書裡寫的那幾個Case Study, 在在讓我想到我現在所處的環境. (上次想到是看到人月神話裡說的"焦油坑").
身為一個品牌公司的RD, 公司制度上比較沒有RD的process, 就算有, 我來了這兩年也沒有被訓練到. 做了幾個Project, 似乎都還靠著"人"的能力來管理整個專案. 沒問題最好, 有問題就得找人跳下去解. 成功是運氣, 失敗是正常, 成功模式無法複製. 整個Schedule只有deadline, 或是幾個milestone, 但schedule怎麼進行, 總是少了一份global view. 需要的時間都是用喊的, 沒有一點理論基礎, 到最後miss deadline, credit愈來愈差. 長久以往, 手邊永遠有做不完的事, 心裡總像是壓了一塊石頭, 都快有憂鬱症, 想去看精神科醫生了.
直到讀了這本書, 感覺又回來了... 雖然還沒有實行, 也不一定有能力在組織中推行. 但隱隱約約中好像看到一線曙光, 也許不會立刻讓整個環境變好, 但總是知道個方向, 怎樣能讓它往好的方向走. 目前擬定的方向很簡單, 只有兩項:
- 開會前有agenda, 開會後有meeting minutes, 開會有結論, 開會不亂扯
- 讓各部門有軟體工程基本的知識, 需求->設計->實作->測試->成品. 讓各成員知道一個改變發生在不同階段時的代價, 讓為所欲為的修改是不經濟的成為共識
假如您想要一個可靠安全的賭博, 到Las Vegas並且去玩吃角子老虎. 設計者將吃角子老虎的最大賠率定為97%, 即使您花一天時間, 往機器投入1000美元, 最多也只能贏回970美元. 如果您覺得吃角子老虎不夠冒險刺激, 可以去玩21點, 一旦贏了, 可以贏得更多(但輸的機率大大增加).
假使Las Vegas的賭博對您而言是"溫和的冒險", 那軟體開發所承擔的風險就可以稱為"高冒險, 高風險的賭博"了. 軟體專案所面臨的不斷改變的用戶需求, 差勁的計劃與估算, 不可信賴的承包商, 欠缺管理經驗, 人員問題, 悲慘的技術失敗, 政府政策的改變, 性能欠佳... 等等不勝枚舉的風險, 使得大型專案按時完成的機率幾乎為0, 大型專案被取消的機率和賭博一樣成敗參半.
留言