《項目管理之殤:為什麼你的軟體項目會失敗》內容簡介：為什麼70%以上的軟體項目會失敗？至今沒有人能給出系統且合理的解釋，《項目管理之殤:為什麼你的軟體項目會失敗》試圖探究其中的原因並給出解決方案。這是所有軟體開發團隊都應該反覆閱讀的一本經典著作，是一位擁有十幾年軟體開發和項目管理經驗的資深專家的智慧結晶，這其中有成功的經驗，更多的則是在項目中經歷的挫折和失敗的教訓總結，可以借鑑，發人深省。
基本介紹
- 中文名：項目管理之殤:為什麼你的軟體項目會失敗
- 外文名：Software Project Secrets:Why Software Proiects Fail
- 作者：斯泰潘內克 (George Stepanek)
- 出版社：機械工業出版社
- 頁數：168頁
- 開本：32
- 品牌：機械工業出版社
- 譯者：陳宗斌
- 出版日期：2014年1月1日
- 語種：簡體中文
- ISBN：9787111452874
基本介紹,內容簡介,作者簡介,圖書目錄,
基本介紹
內容簡介
《項目管理之殤:為什麼你的軟體項目會失敗》共分為兩個部分，第一部分通過比較軟體開發與其他行業的異同，介紹了軟體的12個關鍵特徵，正是它們使軟體顯得與眾不同。在這個基礎上，揭示了項目管理中對於軟體開發無效的10個隱藏的假設，並據此組織和展開內容，深入討論了這些假設導致項目失敗的原因。第二部分則著重介紹一些敏捷方法及其特點和具體套用，以及各種方法的長處和局限性。
作者簡介
作者：（美國）斯泰潘內克（George Stepanek） 譯者：陳宗斌
斯泰潘內克（George Stepanek），資深軟體師，架構師。擁有豐富的團隊領導和軟體開發經驗。擁有J2EE領域的架構師和NET領域的MCSD證書。曾服務於多家著名IT公司。最近在Unrays New Zealand工作。他熱衷於創建優質軟體，並且分享新鮮和有趣的觀點。他發表了許多極富有特色的文章，深受讀者喜愛。他擁有劍橋大學計算機科學和教育碩士學位。
斯泰潘內克（George Stepanek），資深軟體師，架構師。擁有豐富的團隊領導和軟體開發經驗。擁有J2EE領域的架構師和NET領域的MCSD證書。曾服務於多家著名IT公司。最近在Unrays New Zealand工作。他熱衷於創建優質軟體，並且分享新鮮和有趣的觀點。他發表了許多極富有特色的文章，深受讀者喜愛。他擁有劍橋大學計算機科學和教育碩士學位。
圖書目錄
譯者序
致謝
第一部分為什麼軟體項目會失敗
第1章簡介
第2章為什麼軟體與眾不同
2.1軟體是複雜的
2.2軟體是抽象的
2.3需求不完整
2.4技術在快速變化
2.5最佳實踐不成熟
2.6技術是一個龐大的領域
2.7技術經驗不完整
2.8軟體開發就是調查研究
2.9自動處理重複性工作
2.10構造實際上就是設計
2.11改變被認為很容易
2.12改變是不可避免的
2.13小結
第3章項目管理假設
3.1隱藏的假設
3.2範圍管理
3.3時間管理
3.3.1活動定義
3.3.2活動排序
3.3.3活動持續時間估計
3.3.4進度安排
3.4成本管理
3.4.1資源規劃
3.4.2軟體文檔
3.4.3開發人員生產率
3.4.4成本估計
3.5質量管理
3.5.1指標
3.5.2檢查表
3.6風險管理
3.6.1風險接受
3.6.2風險轉移
3.6.3風險避免
3.6.4風險緩解
3.7小結
第4章案例研究：計費系統項目
4.1需求
4.2規劃
4.3設計
4.4構造
4.4.1編碼
4.4.2集成
4.5測試
4.6後果
4.7小結
第二部分怎樣使軟體項目獲得成功
第5章新的敏捷方法
5.1所選的方法
5.2水晶方法
5.2.1頻繁交付
5.2.2反思改進
5.2.3密切或滲透式交流
5.2.4人身安全
5.2.5專注
5.2.6容易訪問專家級用戶
5.2.7具有自動化測試、配置管理和頻繁集成的技術環境
5.2.8使用水晶方法
5.3極限編程
5.3.1規劃策略
5.3.2測試
5.3.3結對編程
5.3.4重構
5.3.5簡單設計
5.3.6代碼集體所有權
5.3.7持續集成
5.3.8現場客戶
5.3.9小型發布
5.3.10每周40小時工作制
5.3.11編碼標準
5.3.12系統隱喻
5.3.13使用xP
5.4Rational統一過程
5.4.1階段
5.4.2疊代
5.4.3角色
5.4.4工件
5.4.5活動和工作流
5.4.6過程配置
5.4.7用例驅動的開發
5.4.8可視化建模
5.4.9使用RuP
5.5利用敏捷緩解風險
5.5.1不完整的需求和範圍改變
5.5.2工具和技術沒有像預期的那樣工作
5.5.3開發人員缺乏技能和專業知識
5.5.4新軟體有缺陷並且需要返工
5.5.5參與項目的員工離職
5.6小結
第6章規劃敏捷項目的預算
6.1軟體開發的預算
6.2持續開發
6.3按需編程
6.4SWAT團隊
6.5子團隊封裝
6.6特性權衡
6.7分診
6.8範圍研究
6.9結合這些技術
6.9.1主要的遺留系統
6.9.2次要的遺留應用程式
6.9.3主要的新系統
6.9.4次要的新應用程式
6.10敏捷離岸外包
6.11小結
第7章案例研究：再論計費系統
7.1方法
7.2初始階段
7.3範圍研究
7.4細化
7.5構造
7.6交付
7.7結局
7.8小結
後記
附錄敏捷宣言
術語表
參考資料
致謝
第一部分為什麼軟體項目會失敗
第1章簡介
第2章為什麼軟體與眾不同
2.1軟體是複雜的
2.2軟體是抽象的
2.3需求不完整
2.4技術在快速變化
2.5最佳實踐不成熟
2.6技術是一個龐大的領域
2.7技術經驗不完整
2.8軟體開發就是調查研究
2.9自動處理重複性工作
2.10構造實際上就是設計
2.11改變被認為很容易
2.12改變是不可避免的
2.13小結
第3章項目管理假設
3.1隱藏的假設
3.2範圍管理
3.3時間管理
3.3.1活動定義
3.3.2活動排序
3.3.3活動持續時間估計
3.3.4進度安排
3.4成本管理
3.4.1資源規劃
3.4.2軟體文檔
3.4.3開發人員生產率
3.4.4成本估計
3.5質量管理
3.5.1指標
3.5.2檢查表
3.6風險管理
3.6.1風險接受
3.6.2風險轉移
3.6.3風險避免
3.6.4風險緩解
3.7小結
第4章案例研究：計費系統項目
4.1需求
4.2規劃
4.3設計
4.4構造
4.4.1編碼
4.4.2集成
4.5測試
4.6後果
4.7小結
第二部分怎樣使軟體項目獲得成功
第5章新的敏捷方法
5.1所選的方法
5.2水晶方法
5.2.1頻繁交付
5.2.2反思改進
5.2.3密切或滲透式交流
5.2.4人身安全
5.2.5專注
5.2.6容易訪問專家級用戶
5.2.7具有自動化測試、配置管理和頻繁集成的技術環境
5.2.8使用水晶方法
5.3極限編程
5.3.1規劃策略
5.3.2測試
5.3.3結對編程
5.3.4重構
5.3.5簡單設計
5.3.6代碼集體所有權
5.3.7持續集成
5.3.8現場客戶
5.3.9小型發布
5.3.10每周40小時工作制
5.3.11編碼標準
5.3.12系統隱喻
5.3.13使用xP
5.4Rational統一過程
5.4.1階段
5.4.2疊代
5.4.3角色
5.4.4工件
5.4.5活動和工作流
5.4.6過程配置
5.4.7用例驅動的開發
5.4.8可視化建模
5.4.9使用RuP
5.5利用敏捷緩解風險
5.5.1不完整的需求和範圍改變
5.5.2工具和技術沒有像預期的那樣工作
5.5.3開發人員缺乏技能和專業知識
5.5.4新軟體有缺陷並且需要返工
5.5.5參與項目的員工離職
5.6小結
第6章規劃敏捷項目的預算
6.1軟體開發的預算
6.2持續開發
6.3按需編程
6.4SWAT團隊
6.5子團隊封裝
6.6特性權衡
6.7分診
6.8範圍研究
6.9結合這些技術
6.9.1主要的遺留系統
6.9.2次要的遺留應用程式
6.9.3主要的新系統
6.9.4次要的新應用程式
6.10敏捷離岸外包
6.11小結
第7章案例研究：再論計費系統
7.1方法
7.2初始階段
7.3範圍研究
7.4細化
7.5構造
7.6交付
7.7結局
7.8小結
後記
附錄敏捷宣言
術語表
參考資料
