出版時間:2007-12 出版社:電子工業(yè)出版社 作者:麥克康內(nèi)爾 頁數(shù):324 字數(shù):420000 譯者:宋銳
Tag標簽:無
內(nèi)容概要
在《軟件估算——“黑匣子”揭秘》一書中,著名的軟件開發(fā)書籍的作者Steve McConnell揭開了圍繞在軟件估算周圍的層層迷霧。作者在深入淺出地介紹了與軟件估算有關(guān)的主要概念之后,深入、全面地介紹了與軟件估算有關(guān)的多種估算方法?! ”緯闹饕獌?nèi)容包括:估算與計劃和項目控制,以及估算與目標和承諾之間的關(guān)系;不確定性錐與估算中的誤差來源以及影響估算的各種因素;先計數(shù)、再計算,無法可想時才依靠判斷的基本估算原則;用于估算軟件項目的三個重要部分——規(guī)模、工作量和進度估算的基本方法;與規(guī)模、工作量和進度估算有關(guān)的特殊問題;估算的概率論觀點以及如何采用適當?shù)姆绞絹肀磉_估算結(jié)果中的不確定性;如何進行與估算有關(guān)的溝通,從而使技術(shù)人員和非技術(shù)人員達成共識。 本書主要面向軟件開發(fā)項目中要進行估算的開發(fā)人員和技術(shù)管理人員。但本書所涉及的與軟件估算有關(guān)的背景知識,以及有關(guān)估算談判和表達方式的討論,對于非技術(shù)人員出身的主管和項目的其他有關(guān)人員同樣大有裨益。
作者簡介
Steve McConnell是Construx Software公司的首席軟件工程師,負責(zé)監(jiān)督該公司的軟件工程實踐。Steve是軟件工程知識體(SWEBOK,Software Engineering Body of Knowledge)項目的構(gòu)造知識領(lǐng)域(Construction Knowledge Area)的負責(zé)人。Steve在微軟、波音以及西雅圖地區(qū)的其他公司也從事過軟件項目方面的工作。他是Construx Estimate和SPC Estimate Professional項目開發(fā)的負責(zé)人,后一個項目獲得過Software Development雜志的生產(chǎn)力大獎(Productivity Award)?! teve是Rapid Development(1996)、Software Project Survival Guide(1998)、Professional Software Development(2004)和Code Complete, Second Edition(2004,《代碼大全,第2版》)等書的作者。他的著作曾兩次獲得過Software Development雜志的年度卓越軟件開發(fā)書籍震撼大獎(Jolt Product Excellence Award)。Steve還是SPC Estimate Professional的開發(fā)負責(zé)人,該產(chǎn)品獲得了軟件開發(fā)生產(chǎn)力大獎(Software Development Productivity Award)。1998年,Software Development雜志的讀者們把Steve選為軟件行業(yè)最有影響力的三個人之一,另外兩人分別是Bill Gates(微軟公司的創(chuàng)辦人)和Linus Torvalds(Linux的作者)。 Steve在惠特曼學(xué)院獲得了學(xué)士學(xué)位,在西雅圖大學(xué)獲得了軟件工程碩士學(xué)位。他現(xiàn)在居住在華盛頓州的貝爾維尤市?! ∪绻雽Ρ緯岢鋈魏卧u論或疑問,請通過steve.mcconell@construc.com或通過www.stevemcconnell.com網(wǎng)站聯(lián)系他。
書籍目錄
第一部分 估算的關(guān)鍵概念 第1章 “估算”的含義 第2章 你的估算水平如何 第3章 準確估算的價值 第4章 估算誤差的來源 第5章 影響估算的因素 第二部分 基本估算方法 第6章 估算方法概述 第7章 計數(shù)、計算和判斷 第8章 估算校準和歷史數(shù)據(jù) 第9章 專家的個人判斷 第10章 分解和重組 第11章 類比估算 第12章 基于代理的估算 第13章 專家小組判斷法 第14章 軟件估算工具 第15章 使用多種估算方法 第16章 獲得良好估算的軟件項目中的估算流程 第17章 標準化估算規(guī)程 第三部分 特定的估算挑戰(zhàn) 第18章 規(guī)模估算中的特殊問題 第19章 工作量估算中的特殊問題 第20章 進度估算中的特殊問題 第21章 計劃參數(shù)的估算 第22章 估算結(jié)果的表達方式 第23章 政治、談判和解決問題 附錄A 估算合理性檢查 附錄B 第2章“你的估算水平如何?”測驗的答案 附錄C 軟件估算提示 參考文獻 索引
媒體關(guān)注與評論
中文版引言 對于軟件項目管理,“坊間”流傳著一個經(jīng)典的“六拍”黑色幽默,如圖1所示。在此我略做演繹:在項目開始之前,你總是先“拍腦袋”得出進度和成本的承諾;在開工大會上領(lǐng)導(dǎo)“拍拍你肩膀”,是那樣的語重心長、充滿期待;而小酒剛下肚、春風(fēng)正得意時,你不由得“拍胸脯”以表決心和能力;但在項目進展過程中遇到這樣、那樣的困難時,客戶和業(yè)主不能不“拍桌子”了;這時充滿悔意的你,只能“拍大腿”以示自責(zé);而到了一切都腹水難收時,恐怕也只能“拍屁股”另謀高就了;不過卻也總能夠重新找個地方東山再起,再“拍腦袋”去了?! ∪缟纤镜牧摹肮秩ψ印币呀?jīng)將尚顯稚嫩的軟件行業(yè)折磨得心焦力竭,如何才能沖破這個行業(yè)的“緊箍咒”呢? ? 從業(yè)人員敬業(yè)精神不高?非也!雖然拍屁股走人后總能夠再次上崗,一則因為軟件項目成功率本來就不高,二則因為大家實際上“已盡人事”了?! ? 項目經(jīng)理們不思進???非也!每當遇到項目超期、成本失控時,項目經(jīng)理大凡都會真心地“拍大腿”,都不愿意自己的苦心最終收獲苦果?! ? 項目過程監(jiān)控管理不足?不全是!沒有過程數(shù)據(jù)、沒有中間管理,哪能會有人半道“拍桌子”?另則,大多失敗的項目也并非源于大家不夠努力。 ? 項目經(jīng)理經(jīng)驗技能不足?不全是!“沒有金剛鉆,不攬瓷器活”,敢“拍胸脯”的項目經(jīng)理,絕不會都是紙上談兵的趙括吧! ? 各種所需資源投入不足?也不全是!“拍拍你肩膀”的人恐怕也絕不會讓你一個人獨自承擔所有的問題吧! 那么問題在哪里?顯然最為核心的問題就出在“拍腦袋”上,在軟件項目管理中缺乏有效的估算方法與過程,一直以來是業(yè)界的心頭之痛!那又是什么原因?qū)е逻@個大家都意識到的問題,長期以來卻處于“無解”的狀態(tài)呢? 也許“規(guī)劃規(guī)劃全是糊話,計劃計劃全是鬼話”這一說法從另一個側(cè)面道出了從業(yè)人員的無奈,計劃情況與實際情況的嚴重偏離導(dǎo)致整個行業(yè)對“軟件估算”產(chǎn)生了不信任感,高級管理人員不敢采用,項目管理者也不愿意把時間花在軟件估算這個“黑匣子”上。幸運的是,Steve McConnell在本書中打開了這個潘多拉之盒背后的秘密?! ∪绻闶且幻芾砣藛T 如果你是一名管理人員,相信對“財務(wù)預(yù)算表”不陌生吧,雖然財務(wù)預(yù)算也從來沒有準確過,但它卻總能夠為管理提供一個范圍。對于業(yè)務(wù)管理、軟件項目而言,其道理也是相同的,戴明博士在TQM理論中提出的管制圖(如圖2所示)就高度概括了這一思想: 管理層的合理預(yù)期是使軟件估算結(jié)果在一個可以控制的范圍之內(nèi),即管理下限和管理上限之間。如果今后的項目執(zhí)行情況都能夠落在這個區(qū)域,那么就意味著是可控的;而如果有大量的數(shù)據(jù)點都落在管理上限之上,或管理下限之下,就意味著控制性很差?! ∥蚁胗兄S富管理理論的你,當從項目經(jīng)理那里聽到整個項目需要35.2個人月的估算時,你的理解可能是類似于“需要30~40個人月”的概念吧!鬼才相信一開始就能夠給出如此精確的估算值哩?! ∧憧隙ㄖ溃椖康墓烙嫓蚀_度是隨著項目進展而不斷提高的,是一個“瞄準靶心”的過程,一開始要做的是確定出“1環(huán)”和“脫靶”之間的邊界,然后才能確定“2環(huán)、3環(huán)、…、10環(huán)”,這種被Steve McConnell定義為“不確定性錐”的理念是使軟件估算有意義的基礎(chǔ)。但項目經(jīng)理似乎沒有發(fā)現(xiàn)這種“觀念”,這就讓問題從一開始就深深埋下了,因此你該告訴他!本書就能夠完成這個任務(wù),因為它圍繞著這一觀念展開了有效、深入的講解?! ‘斎蝗绻阌袝r間翻閱本書,就能夠更深入地理解特定于軟件估算所遇到的困難,更好地理解諸如軟件開發(fā)人員產(chǎn)能不穩(wěn)定、不同軟件項目存在很大差異等特殊因素,以便為項目團隊的估算提供更好的行政支持?! ∪绻闶且幻椖拷?jīng)理 如果你是一名項目經(jīng)理,首先要理解在項目初期,估算的結(jié)果是一個靶子,而不是馬上給出一個靶心,也就是說得到的結(jié)果應(yīng)該是“需要30~40個人月,最可能的值是36個人月”,而不是精確的35.2個人月。如果對這個概念還有些模糊,建議你回頭看看上一小節(jié),理解理解“管制圖”的概念,不管怎么說你也是一個“經(jīng)理”,算是個管理崗位吧! 除此之外,還需要建立以下幾個關(guān)鍵的理念,而如果你開始有了點感覺,那么就不要等待,馬上翻開正文,讓自己接受一次全新的思維洗禮吧?! ?.總估算值不能談判,只對單個估算項進行修改 你向高級管理人員匯報,整個項目要5個月的時間,但卻被要求只能3個月完成!然后基于這個數(shù)字展開的討價還價的場景,怎么聽怎么像在菜市場。這既不是一個嚴謹態(tài)度,也沒有采用科學(xué)的方法! 問題出在哪里呢?想想工程預(yù)算(諸如家裝)時,你要調(diào)整整體造價時,不會直接修改總價吧!該怎么做,誰都知道應(yīng)該修改某個單項預(yù)算,因為總價是用公式自動累加出來的嘛。因此要想避免前面說到的問題,就應(yīng)該提供包含各種單項預(yù)算的表格,當高級管理人員需要減少時間時,要商量的就是去掉哪些單項。放心吧,高級管理人員早在年度預(yù)算會上就適應(yīng)這種模式了?! ?.估算不是玄學(xué) 《軟件工程經(jīng)濟學(xué)》之類的里程碑性著作為軟件估算學(xué)奠定了堅實的基礎(chǔ),但同時也將許多道行尚淺的項目經(jīng)理帶到萬米高空,使估算活動徹底與開發(fā)實踐脫節(jié)了?! ∠鄬τ贑OCOMO、FP之類高深的估算學(xué)模型而言,無數(shù)一線的開發(fā)人員更需要的是學(xué)以致用、能夠解決實際問題的方法,這些方法在本書中被稱為“估算術(shù)”,而且多到幾乎占據(jù)了全書所有的篇幅,沒有給這些大名鼎鼎的模型留下一點篇幅?! ≡陂喿x本書時,其中列舉的各種精致、有效、小巧的估算方法總讓我聯(lián)想到“瑞士軍刀”,相信大家也會有相似的感覺?! ?.經(jīng)驗數(shù)據(jù)是提升估算準確率的關(guān)鍵 經(jīng)歷并不意味著經(jīng)驗,這是我常掛在嘴邊的一句話,放在估算領(lǐng)域也是如此。許多項目經(jīng)理、開發(fā)人員雖然早已身經(jīng)百戰(zhàn),但每當遇到新的開發(fā)任務(wù)時,卻仍然由于沒有經(jīng)驗數(shù)據(jù)而難以給出較好的估算,甚至連自己的產(chǎn)能都不太了解?! 」浪愕慕Y(jié)果需要進行校準,才能夠更加準確。而最無奈之舉則是使用估算模型提供的行業(yè)平均數(shù)據(jù)進行校準,要想真正有效就必須收集、記錄自己的經(jīng)驗數(shù)據(jù)。本書不僅指出了應(yīng)該收集、記錄哪些數(shù)據(jù),還指出了項目初期的數(shù)據(jù)能夠用來修正項目中、后期的計劃,這一理念必將為你的“經(jīng)驗數(shù)據(jù)收集工程”注入強有力的引擎?! ?.分解是復(fù)雜性的克星 對于任何復(fù)雜的問題,都可以借助“分解”這一偉大的工具來應(yīng)對。因此WBS(Work Breakdown Structure,工作分解結(jié)構(gòu))分解的質(zhì)量對于估算而言意義重大,而僅從軟件開發(fā)過程的階段、活動來劃分是不足以支撐估算的;因此必須從軟件開發(fā)的產(chǎn)物(諸如用例、用戶故事)的角度進行分解,這樣才能夠為估算奠定良好的基礎(chǔ)?! ∫虼藢⑿枨箝_發(fā)的輸出作為WBS的基礎(chǔ),讓負責(zé)具體實現(xiàn)的開發(fā)人員對每個單項進行估算,然后在此基礎(chǔ)上進行累加、考慮緩沖、重組,最后才能夠得到真正合理的估算結(jié)果?! ?.估算的問題不僅困擾你一個 在多年的職業(yè)生涯中,老聽到諸如“中國的客戶水平差,連需求都說不清”、“這種東西放到中國來是行不通的”……之類的“國情托詞”。其實不然,在規(guī)模估算、工作量估算、進度估算、計劃參數(shù)估算、估算結(jié)果表達以及圍繞著估算結(jié)果的談判等活動中,全世界的開發(fā)團隊都將公平地遇到相似的問題,Steve McConnell特意用了很大的篇幅講解他在實踐中總結(jié)出來的解決之道。 怎么樣,是否感到有點興趣盎然呀!不要輕易放過“興趣”這一最好的老師,現(xiàn)在就開始愉快的閱讀之旅吧,相信全書簡潔且充滿哲理的文字會給你帶去好的心情和收獲。 如果你是開發(fā)團隊的一員 嗨,開發(fā)團隊中的普通一員!別走開,這里同樣歡迎你!估算并非是頭銜中帶有“經(jīng)理”字樣的那些人的特權(quán)。對于每個開發(fā)活動而言,都需要你對其進行估算,如果你的估算結(jié)果偏離太遠,那么整個項目估算就是在浮沙之上筑高臺?! 》e累反映自己產(chǎn)能的經(jīng)驗數(shù)據(jù),以便正確地對完成任務(wù)所需時間進行估算,從而對團隊做出現(xiàn)實的承諾,才能夠使自己直正遠離“無休止”加班的困擾,畢竟加班要解決的就是那些不應(yīng)該設(shè)置的最后期限,是對不負責(zé)任的進度承諾的懲罰! 學(xué)會記錄自己的時間,掌握基本的估算方法,這些是使自己成長為具有專業(yè)素養(yǎng)的開發(fā)人員所必備的過程。而從本書中,你可以獲得你想要的東西。 感言 在我看完整本書之后,腦海里便浮現(xiàn)出了金庸筆下的兩門絕世武功。用它們作類比,既顯得十分貼近,卻又有幾分不像之處: ? 它好像是“易筋經(jīng)”,能夠幫你打通奇經(jīng)八脈,讓你建立系統(tǒng)、清晰的估算知識體系;它也不像是“易筋經(jīng)”,因為它沒有那么神秘、晦澀,不必非得“有緣人”才可練就?! ? 它好像是“降龍十八掌”,每招每式都那么有氣勢,有威力;它也不像是“降龍十八掌”,因為使用它的人并不需要有絕頂?shù)膬?nèi)力?! “パ剑〔恢挥X將你擋在這本“睿智小書”之前好長時間了,我還是趕快躲開吧,不影響你享受閱讀之趣了?! ⌒臁′h 2007年10月于廈門 譯者序 軟件估算是是項目計劃和控制的基礎(chǔ)。任何一個軟件項目在開始實施之前和實施的過程中,都需要對軟件的規(guī)模、成本、工作量和進度,等等方面進行估算。但是由于軟件開發(fā)是一個非常復(fù)雜的過程,故軟件估算具有極高的復(fù)雜性和不確定性,以至于估算過程往往被看做是一種“黑匣子過程”。在本書之前,還沒有哪本書籍能夠如此全面、深入地闡述如何才能對軟件項目進行有效和準確的估算。以往那些涉及軟件估算的書更多的是對一些相當成熟的開發(fā)組織的估算方法進行理論分析。這些開發(fā)組織采用的方法雖然很科學(xué),但是對大多數(shù)開發(fā)組織而言可能并不具有很高的效費比。 本書的作者Steve McConnell是資深的軟件開發(fā)人員和久負盛名的軟件開發(fā)書籍作家,他領(lǐng)導(dǎo)開發(fā)的軟件曾榮獲Software Development雜志的生產(chǎn)力大獎,他的著作也曾兩度榮獲Software Development雜志的軟件開發(fā)書籍震撼大獎。在《軟件估算——“黑匣子”揭秘》一書中,他為軟件開發(fā)組織和開發(fā)人員獲得基本的估算技能提供了有效的實踐指南,并為他們指出了持續(xù)提高估算能力的基本途徑。本書雖然涉及一些數(shù)學(xué)計算(這在估算中是不可避免的),但它盡可能地避免了過于復(fù)雜的公式推導(dǎo),并提供眾多的提示,以幫助讀者通過建立較少的工作來獲得更準確的估算結(jié)果。用作者的話說,本書關(guān)注的重點是實用的估算術(shù),而不是復(fù)雜的估算學(xué)方法?! 【驮诒緯姆g過程中,還傳來了本書榮獲Software Development雜志2007年生產(chǎn)力大獎的消息。這再次肯定了本書提供的那些實際的、經(jīng)過作者驗證的親身經(jīng)驗的價值?! ”緯饕伤武J翻譯,如果廣大讀者需要對本書的內(nèi)容或與軟件估算有關(guān)的問題進行討論,可以發(fā)送電子郵件至coldmoon75@163.com。Be Flying工作室負責(zé)人肖國尊負責(zé)本書譯員的確定,翻譯質(zhì)量和進度的控制與管理。此外,本書的出版離不開電子社編輯許艷所做的大量協(xié)調(diào)工作,沒有她的積極推動,本書有可能延遲半年以上出版,在此予以特別感謝。敬請廣大讀者提供反饋意見,讀者可以將意見E-mail至be-flying@sohu.com,我們會仔細查閱讀者發(fā)來的每一封郵件,以求進一步提高今后譯著的質(zhì)量。
編輯推薦
在《軟件估算:"黑匣子"揭秘》一書中,著名的軟件開發(fā)書籍的作者Steve McConnell揭開了圍繞在軟件估算周圍的層層迷霧。作者在深入淺出地介紹了與軟件估算有關(guān)的主要概念之后,深入、全面地介紹了與軟件估算有關(guān)的多種估算方法。
圖書封面
圖書標簽Tags
無
評論、評分、閱讀與下載