Transcript 下載/瀏覽

軟體工程
第三章典型錯誤
大綱
3.1 典型錯誤案例研究
3.2 錯誤對開發進度的影響
3.3 常見的典型錯誤
3.4 逃離Gilligan島
3.1典型錯誤案例研究
• Mike 估計工作將需要 12 個月，他不認為有多
大可能在 6 個月內完成。
• Chip是 Jill 和 Tomas面試的，建議不宜雇用，但
Mike 急於用人， Chip 有通信經驗，所以 Mike
還是雇佣了他。
• 計畫的修改意味著測試和區域代理商的培訓必
須同步進行。 Stacy 抱怨沒有給QA（軟體品質
保證部門）足夠的時間作軟體測試，但 Bill駁
回了她的說法。
• Jill 和Tomas 都不喜歡 Chip， Sue 也抱怨
Chip 不讓任何人靠近他的程式碼。
• Chip告訴Mike他已接受了另外一家公司
的合約， Mike另外找到了 Kip負責Chip原
本的工作 ， Kip 發現程式中存在一些嚴
重缺陷，Kip 被迫重新設計編寫。
• 最終 Giga-Quote產品花了 13 個月才得以
交付，而不是計畫的 6 個月，時間超過
了計劃 100 ％。
• 開發人員的工作量，包括加班，總計98
個人月，超過了計畫 36 個人月的 170 ％。
• 最終的產品不包括空行和注解，超出
Mike當初的粗略量 33 ％。
3.2錯誤對開發進度的影響
• 把一些事情做對並不能保證快速開發，
你同時必須避免做錯事。
• 使用現代程式設計實踐：
• 任何最佳實踐的使用只是必要條件，而
不是實現開發速度最大化的充份條件。
• 有可能做了一件錯事，使得前功盡棄。
3.3常見的典型錯誤
•
•
•
•
人員
流程
產品
技術
人員
1. 挫傷侵蝕積極性 – 管理行為挫傷人員的
積極性。
2. 人員素質低落 – 雇用能力欠佳的人員極
大地影響快速發開。
3. 對有問題的員工失控 - 不能很好地處理
有問題的員工將威脅開發速度。
4. 英雄主義 – 若自信的態度遠勝過於精確
的報告，會削弱專案經理人員改善錯誤
的能力。
5. 專案後期加入人員 – 當專案工期拖延，
加入人員想要提高生產力是為火上加油
的典型錯誤。
6. 辦公室環境擁擠嘈雜 – 擁有安靜、隱蔽
的辦公環境往往會有更好的工作績效表
現。
7. 開發人員與客戶之間發生摩擦 – 衝突的
主要原因是缺乏溝通，最壞的情形是客
戶拒絕接收已完工的產品。
8. 不切實際的預期 – 不切實際的預期不會
拉長專案週期，但會助長認為專案開發
週期太長的風氣。
9. 缺乏有效的專案支持 – 缺乏有效的高層
支持注定了專案的失敗。
10. 缺乏各種角色的齊心協力 - 所有主要角
色必須全心投入於專案中。
11. 缺乏用戶的介入 - 沒有用戶早期參與的
專案充滿需求誤解的風險。
12. 政治凌駕於專案本質 – 政治家型專案強
調管理至上，政治加諸於專案之上的結
果對於快速開發是致命的。
13. 充滿想像 – 專案初期充滿想像會導致專
案結束時的大崩坍。
流程
14. 過於樂觀的進度計畫 – 破壞了有效的專
案計畫，施加了額外的壓力，為失敗畫
出底線。
15. 缺乏足夠的風險管理 – 不主動管理風險，
只要一件事做錯，就會使得快速開發變
成慢速開發。
16. 承包商導致的失敗 – 若對承包商不加以
認真管理，非但不會加快速度，反而降
低。
17. 缺乏計畫 – 若不編制計畫進行快速開發，
是不會到達目的的。
18. 在壓力下放棄計畫 – 專案失敗的原因不
在於放棄計畫本身，而是沒有制定替代
措施。
19. 在模糊未明的專案前期浪費時間 - 專案
開始之前的時間所能節省的時間將比開
發進行時來得容易。
20. 前期活動縮減 – 跳過前期活動的專案通
常在後期會以10至100倍的代價完成被
跳過的工作。
21. 缺乏足夠的設計 – 沒有足夠的設計時間，
往往導致設計失敗。
22. 缺少品質保證措施 – 專案前期砍掉1天
的品質保證活動，到專案後期需要3到
10倍的處理代價。
23. 缺乏管理控制 – 在保證專案可追蹤前，
必須能說出它所處的階段跟位置。
24. 太早或過於頻繁的整合 - 額外的整合不
利於產品，僅僅是在浪費時間，延遲專
案進度。
25. 專案估算時遺漏必要的任務 – 如果不能
仔細記錄專案情況，遺漏可視性較差的
任務會導致延長專案時程20~30%。
26. 追趕計畫時程 – 重新評估進度所出現的
錯誤是對時程拖延的不適當反應。
27. 魯莽程式設計 - 只想用時程計畫掩蓋編
碼的問題，幾乎無法成功。
產品
28. 需求的鍍金 – 複雜的功能所導致開發進
度延長的時間簡直是不成比例。
29. 功能蔓延 – 需求變更將使增加進度時間
25%。
30. 開發人員的鍍金 – 使用新技術而不顧需
求，將延長專案進度。
31. 又推又拉的協商 – 專案順延卻又加入新
功能時，反而破壞專案進度。
32. 研究導向的開發 – 要求發明新的資訊技
術倒不如做軟體研究，而不要做軟體開
發。
技術
33. 銀彈綜合症 – 專案鎖定新方法、新技術
或嚴格的流程上，並期望解決進度問題
時，將不可避免的要失望了。
34. 高估新工具技術或方法帶來的節省量 –
新方法的優點部份被重新學習掌控所抵
消，通常可提高10%而不是1倍。
35. 專案進行中更換工具 – 對新工具不熟而
導致無法避免的錯誤通常會抵消原本帶
來的好處。
36. 缺乏自動化的程式碼版本控制 – 將無法
重現使用者報告的錯誤，人工控制程式
碼難以維持程式碼改變頻率。
3.4 逃離Gilligan島
• 大部份的公司在專案結束時發現他們還
是犯了那些典型錯誤。
• 注意典型錯誤，建立自己的最差實踐清
單表，可以避免以後的專案中犯相同的
錯誤。
報告完畢
End