編輯推薦
快速軟體開發 本書重要主題：
1.一個快速開發策略（可以套用於任何一個項目）和27個使此策略發揮效用的最佳實踐。
2.以客觀角度討論優秀和一般快速開發實踐：估算、原型化、強迫加班、激勵、團隊合作、快速開發語言、風險管理等。
3.列出快速開發項目應該避免的典型問題，包括需求蔓延、質量低下和銀彈綜合症等。
4.以豐富的案例生動地描繪了錯誤是怎樣發生的，如何糾正，如何把握項目前進方向。
本書旨在幫助開發人員和項目經理理解什麼是可行的，幫助經理和用戶認識哪些是可實現的，同時也講述了開發人員、項目經理和用戶之間可行的溝通方式與方法，從而使得他們能夠共同找到一條最佳的途徑以滿足項目計畫、成本、質量與其他目標的要求。
本書的主要特色：以“軟體開發人員的直覺”，圍繞“為什麼我們常見的快速開發方法都基本失敗了”這一中心來構思本書的。書中講述的所有實踐活動都是特定環境下開發人員實際工作的真實寫照，正是這個原因，本書提倡在學習使用書中的方法時，應根據自身情況，做一些自己的小小變革。
.
內容簡介
進度失控，幾乎是每一個軟體開發項目揮之不去的噩夢。如何從容趕急，如何通過正確的開發策略和原則，避免典型錯誤，有效地進行風險管理，從多個方面貫徹執行快速軟體開發，都可以從本書中找到答案。本書藉助於實際案例和數據，闡述了快速軟體開發方法的要領和精髓。本書前兩部分描述快速開發的策略和理念，其中的案例討論有助於讀者清楚地領略到策略和理念在實踐中的作用。第三部分則由27個快速開發實踐構成，對於技術領導、程式設計師和項目經理具有重要的參考和指導意義。
作者簡介
SteveMcConnell，軟體行業最有影響力的三大人物之一，與BillGates和LinusTorvalds齊名，曾兩度獲得《軟體開發》雜誌優秀震撼大獎。SteveMcConnell是Construx公司的首席軟體工程師，負責領導客戶軟體項目，講授課程和著書立說。他還是IEEESoftware雜誌的總編和軟體工程知識體（SWEBOK）項目構建知識領域的領導。Steve曾先後就職於微軟公司、波音公司和西雅圖地區的公司。他擁有惠特曼大學學士學位和西雅圖大學軟體工程碩士學位。
圖書目錄
第1部分有效開發第1章歡迎學習快速開發
1.1什麼是快速開發
1.2實現快速開發
第2章快速開發策略
2.1快速開發的總體策略
2.2開發速度的四維
2.2.1人員
2.2.2過程
2.2.3產品
2.2.4技術
2.2.5協同
2.3快速開發的一般分類
2.3.1有效開發
2.3.2側重於最佳進度的有效開發
2.3.3全面快速開發
2.4哪一維更重要
2.5快速開發的權衡策略
深入閱讀
第3章典型錯誤
3.1典型錯誤案例研究
3.2錯誤對開發進度的影響
3.3典型錯誤一覽
3.3.1人員
3.3.2過程
3.3.3產品
3.3.4技術
3.4逃離格里甘島
深入閱讀
第4章軟體開發的基本原則
4.1管理原則
4.1.1項目估算和進程安排
4.1.2計畫編制
4.1.3跟蹤
4.1.4度量
4.2技術的基本原則
4.2.1需求管理
4.2.2設計
4.2.3構建
4.2.4軟體配置管理
4.3質量保證的基本原則
4.3.1易錯模組
4.3.2測試
4.3.3技術回顧
4.4按照指導來做
深入閱讀
第5章風險管理
5.1風險管理要素
5.1.1風險評估
5.1.2風險控制
5.2風險識別
5.2.1最常見的進度計畫風險
5.2.2進度計畫風險的完整列表
5.3風險分析
5.3.1風險暴露量
5.3.2估計損失的大小
5.3.3評估損失發生的機率
5.3.4整個項目的延期和緩衝
5.4風險優先權
5.5風險控制
5.5.1風險管理計畫
5.5.2風險化解
5.5.3風險監控
5.6風險、高風險和冒險
深入閱讀
第Ⅱ部分有效開發
第6章快速開發中的核心問題
第7章生命期計畫
第8章估算
第9章進度計畫
第10章面向客戶開發
第11章激勵機制
第12章團隊合作
第13章團隊結構
第14章功能限定
第15章生產率工具
第16章項目修復
第Ⅲ部分最佳實踐簡介
第17章變更委員會
第18章日創建和冒煙測試
第19章變更設計
第20章漸進交付
第21章漸進原型
第22章目標設定
第23章檢查
第24章聯合應用程式開發
第25章生命期模型的選擇
第26章度量
第27章小型里程碑
第28章外包
第29章原則談判法
第30章高效開發環境
第31章快速開發語言
第32章需求提煉
第33章重用
第34章簽約
第35章螺鏇型生命期模型
第36章階段性交付
第37章W理論管理
第38章捨棄型原型法
第39章限時開發
第40章工具組
第41章前十大風險清單
第42章構建用戶接口原型
第43章自願加班
參考文獻
書摘插圖
第1章 歡迎學習快速開發
本章主題
什麼是快速開發
實現快速開發
相關主題
本書適用對象：參閱“前言”本書主要特色：參閱“前言”
為何編寫本書：參閱“前言”
快速開發策略：參閱第2章
快速開發要點：參閱第6章
某產品經理告訴我，為改變現狀，他想建立一套產品開發許可權控制體系，該體系要更注重產品質量、防止功能蔓延、控制項目進度，並能夠按計畫交付產品。
但是，當實際運作項目時，他又不由自主地把將產品迅速推向市場放在了最優先的級別上。如何保證產品的可用性？我們沒有足夠的時間。如何保證產品的性能指標？可以等等再說。如何保證產品的可維護性？下一個項目再說。如何進行產品測試？我們的用戶現在就要產品，馬上送貨。這個產品經理並非只是某個特定的產品經理，他幾乎是我為之工作的所有產品經理的化身。這種情形在整個軟體業日復一日地重複著。開發時間已經變成頭等重要的問題，以致忽略了其他應考慮的因素，甚至那些最終會影響開發時間的因素。
1.1 什麼是快速開發
對有些人而言，快速開發是通過使用一個得力的工具或方法實現的；對黑客而言，快速開發可能意味著36個小時連續不斷地編碼；對信息工程師而言，快速開發就是RAD——CASE（計算機輔助軟體工程）工具、積極的用戶參與和緊湊的時限（timebox）的集合；對縱向市場的程式設計師而言，快速開發就是利用微軟的最新版本的VisualBasic或Delphi快速建立原型的過程；對項目經理而言，無論最近一期商業周刊發布的實踐亮點是什麼，快速開發就是拚命縮短項目周期。
每種工具或方法都可能在特定的場合完美運行，並有助於提高開發速度，但要完全發揮它們的功效，則必須將它們作為周密完整策略的一部分合理編排。沒有任何一種快速開發工具或方法適合所有快速開發場合，即使對只有一定速度要求的非快速開發實踐，也沒有任何一種快速開發工具或方法就肯定能滿足它在速度方面的要求。
就本書而言，並不是要介紹具體的方法或工具，“快速軟體”開發只是一個相對於“慢速和典型開發”的描述性說法。它並不是有註冊商標的快速開發方法——一個不可思議的短語或行話。本書所說的“快速開發”是個普通的術語，與“快捷開發”或“更短的開發周期”具有相同的意義，它意味著能夠以比你目前更快的速度開發軟體。
總之，一個快速開發項目就是任何一個需要強調開發速度的項目，以今天的業界環境，可以說很多項目都是快速開發項目。
1.2 實現快速開發
本書的目的是為你進行快速開發提供一條捷徑，雖然切換到這條捷徑似乎存在著風險，但採用目前的開發方法則會導致成本增加、項目計畫時間拖延、質量低下、項目失敗、大量反覆，造成項目經理、開發人員和用戶的衝突，並出現其他我們本可以避免的問題。
如果你是在採用常規開發模式的組織中工作，則採用本書中的實踐做法，你能夠將開發時間大大縮減，可能多達50%，並能大大提高勞動生產率，而不會危及產品質量、性能、可維護性和項目投入。但這種改變不會因你採用了某種新的工具或方法而立刻實現，也不會因你採用某種封裝軟體而立刻奏效，實現快速開發需要時間與努力。
我們都幻想能有一個簡單的方案可以解決開發速度問題，但簡單的方案只能解決簡單的問題，軟體開發並不是一個簡單問題，快速軟體開發更不是一個簡單問題。
如圖1-1所示，所有可能的軟體實踐集合是巨大的，在這樣的集合中，有效實踐這一子集中的實踐數量也是相當大的，在某個特定項目中，你可能只用到這些實踐中的一小部分。從總的執行層面看，快速開發的成功取決於兩個要素：
選擇有效的實踐而不是無效實踐
選擇有利於完成項目進度目標的實踐
你可能認為這是顯而易見的，但就像第3章所解釋的那樣，各組織機構往往選擇的是無效實踐，他們選擇的實踐已經證明是失敗的或者是失敗多於成功。當他們需要確保項目進度時間時，他們選擇的是那些其實降低了達成計畫目標機會的高風險實踐。當他們需要降低成本時，他們選擇的是那些反而導致成本上升的基於速度的實踐。這些組織改善開發速度的第一步是管理好他們選定的無效實踐，然後開始選擇有效的實踐。
