灾难拯救:让软件项目重回轨道
基本信息
- 原书名: Catastrophe Disentanglement: Getting Software Projects Back on Track
- 原出版社: Addison-Wesley Professional
- 作者: (美)E.M.Bennatan [作译者介绍]
- 译者: 侯艳飞 侯玉芳 李萌
- 丛书名: 软件工程研究院
- 出版社:电子工业出版社
- ISBN:9787121058097
- 上架时间:2008-3-10
- 出版日期:2008 年2月
- 开本:16开
- 页码:239
- 版次:1-1
- 所属分类:
计算机 > 软件工程及软件方法学 > 软件项目管理
计算机 > 软件工程及软件方法学 > 软件质量、软件测试及维护
编辑推荐
07年Jolt世界图书大奖获奖图书.
案例丰富、写作精良、富有趣味
填补软件工程领域校正性解决方案空白
从进度、开支和质量三方面诊断项目是否陷入灾难..
提供一套有效、易理解和易操作的项目灾难拯救方法
以十个步骤、在不超过两周的时间内完成项目拯救过程...
内容简介回到顶部↑
本书是作者在几十年软件项目管理实践经验的基础上写成的,它为软件项目拯救提供了一套易理解的、便于操作的和有效的方法。本书偏重实践而非理论,共分为13章。第1章为绪论,主要是介绍了灾难拯救的基本概念,阐述了软件项目何时需要拯救行动的介入。第2章主要介绍了判断项目是否陷入灾难的方法。第3至12章详细介绍了灾难拯救过程的十个步骤,教你如何一步步地使陷入灾难的软件项目重回轨道。第13章为结束语,对前面各章做了简要回顾,并阐述了如何进行时间安排以使全部拯救过程在两周时间里完成。
本书适用于软件项目经理和高级经理,也可供软件开发人员和与软件项目有关的其他人员参考;本书还可以作为软件工程和项目管理方面的一本教材。
本书适用于软件项目经理和高级经理,也可供软件开发人员和与软件项目有关的其他人员参考;本书还可以作为软件工程和项目管理方面的一本教材。
作译者回到顶部↑
本书提供作译者介绍
E.M.Bermatan拥有丰富的管理实战经验。这些经验源自他在摩托罗拉公司多年担任高级主任的经历。在任其期间,他带领团队开发了很多大型软件系统,并领导过多个跨国设计中心。他还曾是米德威公司(Midway Company)的工程副总裁,任职期间管理着数百名软件和硬件工程师。Bennatan先生在软件项目管理方面是演讲台上的一位常客。他还是《在预算范围内按时完成:软件项目管理、实践和技术(第三版)》(On Time Wthin Budget:Software PROFECT,ectManagement,Practices andTechniques,THIRD Edition)一书的作.. << 查看详细
目录回到顶部↑
第1章 绪论
1.1 灾难拯救过程概述
1.1.1 案例研究
1.1.2 做出拯救决定
1.1.3 拯救过程
1.2 一些调查数据
1.3 一些提示
1.4 本章小结
第2章 确定项目是否陷入灾难
2.1 进度
2.1.1 设置进度警报器
2.1.2 调整进度警报器
2.1.3 监视延长后的时间表
2.2 预算
2.2.1 设置预算警报器
2.2.2 其他需考虑的事项
2.3 质量
2.3.1 问题列表警报器
2.3.2 顾客满意度警报器
2.4 学会利用经验
1.1 灾难拯救过程概述
1.1.1 案例研究
1.1.2 做出拯救决定
1.1.3 拯救过程
1.2 一些调查数据
1.3 一些提示
1.4 本章小结
第2章 确定项目是否陷入灾难
2.1 进度
2.1.1 设置进度警报器
2.1.2 调整进度警报器
2.1.3 监视延长后的时间表
2.2 预算
2.2.1 设置预算警报器
2.2.2 其他需考虑的事项
2.3 质量
2.3.1 问题列表警报器
2.3.2 顾客满意度警报器
2.4 学会利用经验
前言回到顶部↑
几年前,我听了这样一个故事。一个俄国人、一个法国人、一个日本人和一个美国人不幸被食人族抓住了。在被扔进沸水锅之前,酋长告诉他的俘虏,每人可提一个请求,而他会满足他们在这世上的最后要求。.
俄国人的请求是喝最后一杯伏特加,法国人的请求是让一位年轻的本地姑娘给他最后一吻,日本人说他的请求是最后一次关于质量的演讲。最后轮到了美国人说出自己的请求,他说:“请先把我扔进沸水锅吧,这样我就不必再听一次关于质量的演讲了!”
什么事都要讲个时机和场合。当一个软件项目陷入严峻的困境时,软件开发机构最想听到的是他们应怎样扭转败局,使项目进行下去。然而此时,并没有可遵循的PMI、IEEE、SEI或ISO标准帮助他们拯救项目。PMI、IEEE、SEI和ISO这些组织提供了预防项目失败的方案,而没有提供拯救项目于危难的办法。当项目迫近“被扔入沸水锅”的结局之时,它最后的请求是“救我”,而不是“再告诉我一次如何避免陷入困境”。
本书是一本“救治”之书。本书探讨了如何拯救面临失败的软件项目使之回到正轨,虽然其中也偶有内容论及灾难预防。本书描述了拯救(或解救)面临失败的软件项目(或称软件项目灾难)的10个步骤。本书有广泛的目标读者群,包括软件开发人员、项目经理、高级管理人员以及软件项目利益攸关者(同软件项目之间存在很大利益关系的人)。
本书也旨在成为一本教材。在本书每一章的末尾,都有本章小结,并提供了习题。
本书中有的内容要求读者具备一些软件工程知识,不过这样的内容很少,具备软件工程知识并不是使用本书的必要条件。本书对于缺少管理知识的软件工程师和对于缺少软件开发知识的项目管理人员一样有用。
本书共包括13章:
第1章为绪论。本章介绍了灾难拯救的概念,探讨了软件项目何时需要拯救行动的介入。在本章中,还对本书中使用的几个基本术语进行了阐释。
第2章论述了判断项目灾难来临的方法。对于遇到麻烦的项目来说,本章是决定是否需要对它采取后面各章中描述的拯救步骤的一章。
第3章至第12章描述了灾难拯救过程的10个步骤(每章描述一个步骤)。..
第13章为结束语,标题是“把最后的拼图放入位置”。在本章中,有些内容是关于灾难预防的。本章综览之前各章描述的10个步骤,并阐述了如何进行时间安排以使全部拯救过程在两周时间里完成。
本书所介绍的拯救过程中,很多步骤之间存在交叠,且每一步骤都依赖于它前面的步骤,因此,本书不适合随兴翻到哪里看哪里、“东一榔头西一棒槌”的阅读方式。如果读者从头到尾地了解了整个拯救过程,那么,理解起每个拯救步骤来也会更加容易。因此,强烈建议您在实施拯救过程之前从头到尾学习本书全部内容。不过,您也不必因为我的上述建议而气馁,本书每一章都有“本章小结”,您可以采用仅仔细阅读与正在实施的拯救步骤有关的章而对其他各章只阅读“本章小结”的简化方式来学习。
本书内容偏重实践而非理论。本书在介绍很多方法和技术时,并未说明其理论基础。不过,本书中提供了大量的参考书目,以飨对理论背景感兴趣的读者。参考书目信息见本书末尾部分。
在本书出版之前,有一些关于项目灾难局面能否扭转的讨论,实际上也就是说,当我们想拯救一个项目的时候,将这个项目称为灾难是否合适。对于任何一名在大型技术公司工作过并听到过某位沮丧的高级经理说“这个项目是个灾难!”的人来说,答案都是很明显的。如果灾难局面不可扭转,那么,项目在彼时彼地就会被放弃了,但是,高级经理接下来通常会说的是:“我们需要马上使它回到轨道!”是的,这正是本书所要论述的。
我在摩托罗拉公司和其他一些技术公司从事了多年的软件项目管理工作,并对数百家软件开发机构的软件项目开发数据进行了收集和分析,这是形成本书中“拯救”概念的基础。在本书之前,我曾写过一篇同名的论文,这篇论文发表在了美国国防部出版的期刊“CrossTalk, The Journal of Defense Software Engineering”上。
感谢埃米尔(Amir)在本书问世过程中给予的极大帮助,他的贡献和评论是无价的。...
E. M. Bennatan
2006年1月
俄国人的请求是喝最后一杯伏特加,法国人的请求是让一位年轻的本地姑娘给他最后一吻,日本人说他的请求是最后一次关于质量的演讲。最后轮到了美国人说出自己的请求,他说:“请先把我扔进沸水锅吧,这样我就不必再听一次关于质量的演讲了!”
什么事都要讲个时机和场合。当一个软件项目陷入严峻的困境时,软件开发机构最想听到的是他们应怎样扭转败局,使项目进行下去。然而此时,并没有可遵循的PMI、IEEE、SEI或ISO标准帮助他们拯救项目。PMI、IEEE、SEI和ISO这些组织提供了预防项目失败的方案,而没有提供拯救项目于危难的办法。当项目迫近“被扔入沸水锅”的结局之时,它最后的请求是“救我”,而不是“再告诉我一次如何避免陷入困境”。
本书是一本“救治”之书。本书探讨了如何拯救面临失败的软件项目使之回到正轨,虽然其中也偶有内容论及灾难预防。本书描述了拯救(或解救)面临失败的软件项目(或称软件项目灾难)的10个步骤。本书有广泛的目标读者群,包括软件开发人员、项目经理、高级管理人员以及软件项目利益攸关者(同软件项目之间存在很大利益关系的人)。
本书也旨在成为一本教材。在本书每一章的末尾,都有本章小结,并提供了习题。
本书中有的内容要求读者具备一些软件工程知识,不过这样的内容很少,具备软件工程知识并不是使用本书的必要条件。本书对于缺少管理知识的软件工程师和对于缺少软件开发知识的项目管理人员一样有用。
本书共包括13章:
第1章为绪论。本章介绍了灾难拯救的概念,探讨了软件项目何时需要拯救行动的介入。在本章中,还对本书中使用的几个基本术语进行了阐释。
第2章论述了判断项目灾难来临的方法。对于遇到麻烦的项目来说,本章是决定是否需要对它采取后面各章中描述的拯救步骤的一章。
第3章至第12章描述了灾难拯救过程的10个步骤(每章描述一个步骤)。..
第13章为结束语,标题是“把最后的拼图放入位置”。在本章中,有些内容是关于灾难预防的。本章综览之前各章描述的10个步骤,并阐述了如何进行时间安排以使全部拯救过程在两周时间里完成。
本书所介绍的拯救过程中,很多步骤之间存在交叠,且每一步骤都依赖于它前面的步骤,因此,本书不适合随兴翻到哪里看哪里、“东一榔头西一棒槌”的阅读方式。如果读者从头到尾地了解了整个拯救过程,那么,理解起每个拯救步骤来也会更加容易。因此,强烈建议您在实施拯救过程之前从头到尾学习本书全部内容。不过,您也不必因为我的上述建议而气馁,本书每一章都有“本章小结”,您可以采用仅仔细阅读与正在实施的拯救步骤有关的章而对其他各章只阅读“本章小结”的简化方式来学习。
本书内容偏重实践而非理论。本书在介绍很多方法和技术时,并未说明其理论基础。不过,本书中提供了大量的参考书目,以飨对理论背景感兴趣的读者。参考书目信息见本书末尾部分。
在本书出版之前,有一些关于项目灾难局面能否扭转的讨论,实际上也就是说,当我们想拯救一个项目的时候,将这个项目称为灾难是否合适。对于任何一名在大型技术公司工作过并听到过某位沮丧的高级经理说“这个项目是个灾难!”的人来说,答案都是很明显的。如果灾难局面不可扭转,那么,项目在彼时彼地就会被放弃了,但是,高级经理接下来通常会说的是:“我们需要马上使它回到轨道!”是的,这正是本书所要论述的。
我在摩托罗拉公司和其他一些技术公司从事了多年的软件项目管理工作,并对数百家软件开发机构的软件项目开发数据进行了收集和分析,这是形成本书中“拯救”概念的基础。在本书之前,我曾写过一篇同名的论文,这篇论文发表在了美国国防部出版的期刊“CrossTalk, The Journal of Defense Software Engineering”上。
感谢埃米尔(Amir)在本书问世过程中给予的极大帮助,他的贡献和评论是无价的。...
E. M. Bennatan
2006年1月
媒体评论回到顶部↑
“市面上有很多关于软件风险和软件失败的书,但是其中鲜有教你如何一步步使陷入困境的软件项目重回到轨道的。这本书为软件项目拯救提供了详细的指导,尽管作者所推荐的有些步骤可能会令人不快,但所有的步骤都是十分重要的。”.
——Capers Jones,软件生产力研究公司荣誉首席科学家
“这是一本极具匠心、写作精良且富有趣味的书,它所探讨的话题非常重要。作者说并没有其他书论及项目失败的这一特定方面,此话符实。”..
——Robert L. Glass,双月刊通讯《软件从业者》
The Software Practitioner出版人...
——Capers Jones,软件生产力研究公司荣誉首席科学家
“这是一本极具匠心、写作精良且富有趣味的书,它所探讨的话题非常重要。作者说并没有其他书论及项目失败的这一特定方面,此话符实。”..
——Robert L. Glass,双月刊通讯《软件从业者》
The Software Practitioner出版人...


点击看大图




加载中...
