注册 | 登录读书好,好读书,读好书!
读书网-DuShu.com
当前位置: 首页出版图书经济管理管理人力资源管理管理软件开发项目:通向成功的最佳实践

管理软件开发项目:通向成功的最佳实践

管理软件开发项目:通向成功的最佳实践

定 价:¥39.00

作 者: (美)尼尔·怀特(Neal Whitten)著;孙艳春,陈向群,赵俊峰译;孙艳春译
出版社: 电子工业出版社
丛编项: 软件项目管理系列丛书
标 签: 软件项目管理

ISBN: 9787505375062 出版时间: 2002-04-01 包装: 平装
开本: 24cm 页数: 328 字数:  

内容简介

  本书在汇集数千人及成百个项目的经验智慧的基础上,通过揭示困扰当前软件项目管理的最常见问题,向读者提供了快刀斩乱麻式的解决方案,使读者能正确地确定、解决和避免最常见问题,提高产品质量及客户满意度,缩短开发周期,提高项目成员的生产效率。少谈理论而更多注重实践,提供切实可行的内行专家的建议和最新的指导,这一切使本书成为一本项目管理的经典教材。本书作者有25年的软件工程实践经验,管理项目管理协会成员,资深项目管理权威专家。环顾一下在你本人.你所在的公司及你的周围,贯穿于整个软件产业的软件开发项目,是否有未完成计划.超出预算甚至危及产品质量的情况?上述情况比比皆是.为什么出现这样的状况呢?毕竟在每一个新的年度里会有新的项目管理者加盟到成千上万的新的软件开发项目中,这使得软件产业就好像是全新的产业,而且在此之前很多人还从来没有经历过一个软件开发项目.除此之外,今天成千上万的人们在进行软件项目开发中累积了大量经验,这些人肯定从他们所有的积累的经验中学到一些东西.也就是说,肯定也有了更好的软件项目管理实践和软件开发工具.那么,在以上的情况下,现实中究竟会发生什么事情呢?今天的现状有何问题吗?为什么大多数软件开发项目仍然面临这么多问题?其实,最糟糕的事情就是当前许多困扰软件开发项目的问题与去年.前年甚至是20年前所遇到的问题一样!为找到这些问题的答案,我们先看看下面的场景.你为一家公司工作了10年.这家公司从雇佣你时就开始开发软件产品.今天,有超过一打的软件项目正在开发中.如果你想清点一下从你进公司开始,公司在这10年中有多少软件项目,你将会清点出数百个,包括一些从来没有完成过的项目.现在,让我们看一下在这个案例中的2个可能采取的途径.路径A你所在公司的领导层在承接第一个项目的10年后才做了一个很英明的商业决策(不幸的是在软件工业中很少发生).这个决策就是:无论软件项目完成或取消之后,都要立即进行强制的项目后的评审.而且,每位新的项目成员必须仔细思考最近的项目评审中发现的问题,并对这些问题给出一些解决的建议,判断哪些问题也是他们自己也可能忽略的问题.团队也许会反对:“我们没有时间去完成项目后的评审,也没有时间总去修改我们的进程.我们在这个高度竞争的工业中以尽量低的花费,努力尽快生产和交付产品.我们在每个项目中需要完全的自由去做我们觉得对的任何事情.”但是,管理者仍然坚持必须做项目后的评审.(在这里,我简要地定义一下项目后评审,这样就不会对我要表述的意思产生怀疑.项目后评审(postprojectreview)在整个项目完成或取消之后进行,其目的是要从这个完成或取消的项目中找出一些有代表性的东西,并讨论项目中什么是对的.什么是错的.哪些可以改善.于是这些结论可以在以后的项目中进行发扬,使得将来的所有项目都可以从已经完成的项目的好的和不错的经验中受益.)路径B管理者认为项目后评审只是项目完成时要做的一个可选活动.在公司里,领导解释说:“如果我们能找到时间,这当然是件好事.”如果一个项目被取消,评审就会是:“不需要做项目后评审了.评审会浪费太多的时间和金钱.我们不要再浪费了.”这两个路径的结果是什么?走路径A的公司已经证明完成的项目提供了许多有价值的经验教训,这些经验教训可以被应用于降低新项目的风险—减少花费.增加生产效率等.在第一个软件开发项目的10年后,当前的项目仍然存在本应被避免的问题,但是这些问题比10年前更少出现.影响更小.实际上,公司已经在此行业中赢得了声誉:具有最高成功率.最低的成本.最高质量的生产者.而且,从被取消项目的项目后评审中,公司也学到了更多的关于如何不去运?欣嗨频南钅康木?.项目的取消率只有大约为5%,并且逐年降低.在路径B中,公司经常胡乱地评审.任选的项目后评审在所完成的项目中的执行率是10%左右,但是很少使用这些发现去让新项目受益.大部分项目仍然遇到在以前的项目中出现的同样问题.运行得很好的项目是不常见的.极少的运行得很好的项目也是因为迫于强制,因为对他们的那些纪律要求是项目领导提出的.当项目领导调职或离开公司时,项目执行状况经常会恶化.发生这种情况是因为没有准确的过程和文化去支撑项目领导的积极动力.项目的取消率为每年35%,大于具有同样公司历史的公司.从以上两种路径,得到的经验是:经验教训0-1:选择路径B意味着大多数项目的领导者和成员将不会持续地从过去的错误或过去的成功中进行学习,这样也就导致了成本的增加,并难以得到改善.一个项目的成功或失败是人为的事情,而与工具.技术以及其他事情无关.因为项目是由人来领导的,而不是技术.虽然技术能给予帮助,例如使用艺术化的项目管理工具和软件开发工具,但是项目领导层的不同,将导致项目的差异.你也知道什么情况会变得这么严重?为什么项目总遇到困难,这一点不是一个秘密,虽然许多人不想听这样的话,但他们还是听得到.以上情况导致的更严重后果就是,公司解雇员工或由于空前的竞争而倒闭.谁是赢家?有部分原因可以认为,高效地培训他们的领导者的公司是赢家.他们培训自己的领导在遇到问题之前去认识主要问题,并培训他们尽快地解决这些问题,这样问题就不会像一个化脓的伤口一样扩散,并导致项目有失败的风险.另外还要说的就是,不要因为你最后交付了产品,你就认为是成功了.不要下风险很大的赌注,项目应该最好能进行分解,以降低损失并重新部署人力资源和资金.许多组织就是因为高额的维护费用和较低的客户满意度而遭受重创或破产.本书的成功之处在哪呢?本书可以说既可以作为一个实践指南,又是一个可以医治你的疾病的药方.实践指南赢得你更多的注意力,帮助你看到那些困扰软件开发项目的最常见问题.一旦你认识到这些问题,你将处于一个处理这些问题的更有利的位置.关于药方呢?本书的药方部分是提供来帮助你避免或从这些问题中解脱出来的解决方案.我经常收到读者寄来的信,其中最常见的话是:“我已经命令我组织中的所有协调者和经理购买并学习你的书,以帮助他们更好地学习项目管理技术,项目管理的价值是‘强行推销’,并且我经常使用你的书作为强化和增强我自己管理素质的一个课程,这也是我们努力所达到的价值.”在本书中的药方部分也鼓励你学习过去的经验.遵守信用.保持正直.富有责任感并努力自控.自从本书的第1版在1990年出版以来,我已经收到大量的读者反馈,这些反馈帮助我让第2版比第1版写得更好.虽然我仍然在学习,但是作为一个有20多年的第一线软件工程经验的经理.项目领导.教师和顾问,我自信在我从许多软件工业的成功典范学习到的知识.反馈并获得的勇气的基础上写作的本书,一定能帮助你避免许多我和无数其他人已经犯过的错误.我们首次犯错误时,我们能辨证地称之为“失误”,但是如果我们不停地重复相同的错误,那仍然只是“失误”吗?我不这样认为.为什么?因为我们都可以做选择.如果我们已经知道,而仍选择一个有害的路径—不管是什么“崇高”的原因,作为专业人员,我们就太粗心大意了.作为专业人员,我们需要不停地寻找提高我们技能的方法和管理软件开发项目的艺术,这样我们与我们工作的公司才能取得成功.关于项目管理的知识通常是通过实际工作获得的—一个效率极低的学习高技术的方式.许多经理.项目领导以及项目成员由于各种原因从不学习,使得一些本来可以避免的错误工作及环境,从一个项目持续到又一个项目.本书的目的就是要尽力为你以后的项目提供直接的.立刻可以应用的经验.不管你是一个经理.项目领导或项目成员,本书都有及时.有用的信息去帮助现在的项目并为将来的项目做准备.下面介绍了如何阅读本书以及如何立即开始应用书中的这些信息.确定问题及解决方案人们不可能高效地控制他们没有理解的事情.因此,本书的首要目的是确定在软件开发项目中最常见的问题.从你自身的各种经验中,你或许会添加一个或更多的主要问题.但是,我已经选择的问题可能是最击中要害的.有趣的是,这些问题在这几年中几乎没有变化,我想也不会马上有很大的改变.你也许认为本书中提到的问题中的大部分显然是针对项目成员的.但是,这些问题的大部分会在项目中缓慢扩散,而不是在某天突然显现出来.而且,遇到困难的项目经常在任何给定的时间是处于控制中的.因此,能够认识到问题是关键的第一步.既然本书的读者有不同的背景,我将?∥宜馨盐侍舛ㄒ宓霉惴汉屯?

作者简介

  尼尔·怀特在项目管理、软件开发和人力资源开发领域是一个非常受欢迎的演讲家、教师、顾问和作家。他早先是IBM的高级系统工程师,有25年的软件工程实践经验。曾管理过许多软件产品的开发、包括OS/2和其他操作系统、通信应用软件以及专用程序的早期设计,他还管理过质量保证小组,并负责为大量的软件项目提供质量保证。怀特先生是美国项目管理协会的成员,也是一名资深项目管理专家。

图书目录

丛书总序                  
 译者序                  
 原书序                  
 前言                  
 第1章 软件开发过程定义                   
 1.1 项目案例                   
 1.2 “过程”意味着什么                   
 1.3 定义软件开发过程的步骤                   
 1.4 步骤1:确定软件模型                   
 1.5 步骤2:确定活动                   
 1.6 步骤3:确定活动间的关系                   
 1.7 步骤4:将每个活动的有用信息文档化                   
 1.8 步骤5:剪裁过程文档化                   
 1.9 步骤6:改善过程文档化                   
 1.10 步骤7:过程获得认可并培训员工                   
 1.11 步骤8:不断地使用和改善过程                   
 1.12 软件开发过程的一个实例                   
 第2章 纪律—队伍的黏合剂                   
 2.1 项目案例                   
 2.2 纪律的必要性                   
 2.3 对有纪律约束的组织的认识                   
 2.4 执行纪律                   
 2.5 成功领导人的素质                   
 2.6 对组织进行诊断                   
 2.7 组织也渴望纪律                   
 第3章 有效的沟通                   
 3.1 项目案例                   
 3.2 尊重个人                   
 3.3 当你犯错误时, 要勇于承认                   
 3.4 学会宽容                   
 3.5 与他人会面                   
 3.6 快速帮助他人                   
 3.7 向他人请求帮助                   
 3.8 使用一些技巧—以恰当的方式阐述你的评论                   
 3.9 通知他人, 不要让他们感到惊讶                   
 3.10 解决问题                  
 3.11 表示出赞赏                   
 3.12 做一个好听众                   
 3.13 向人们致意时, 要记住他们的名字                   
 3.14 考虑折衷                   
 3.15 愿意打破常规                   
 3.16 知道别人对你的期望                   
 3.17 管理工具                   
 第4章 项目进度计划控制                   
 4.1 项目案例                   
 4.2 项目进度计划开始的时间                   
 4.3 自顶向下与自底向上的计划                   
 4.4 最初与最终的项目进度计划                   
 4.5 项目进度计划要包括的内容                   
 4.6 活动关系类型                   
 4.7 与文档相关的活动                   
 4.8 交迭的活动                   
 4.9 估计活动的周期                   
 4.10 关键路径                   
 4.11 资源                   
 4.12 计划意外事故缓冲时间                   
 4.13 加班. 轮班和临时个人缓冲时间                   
 4.14 节日和假期缓冲时间                   
 4.15 第二方观点                   
 4.16 确定里程碑                   
 4.17 活动责任矩阵                   
 4.18 项目检查表                   
 4.19 创建项目进度计划的步骤                   
 4.20 富有挑战性但却可达到的进度计划                   
 第5章 项目跟踪:保持控制                   
 5.1 项目案例                   
 5.2 应该跟踪什么                   
 5.3 项目高风险区                   
 5.4 项目进展概况                   
 5.5 项目活动进展                   
 5.6 活动项进展                   
 5.7 项目展望                   
 5.8 进行跟踪的时间                   
 5.9 参加跟踪会议的人选                   
 5.10 跟踪会议日程                   
 5.11 跟踪会议的安排                   
 5.12 跟踪会议的程序                   
 5.13 修复计划                   
 5.14 问题升级的规则                   
 5.15 跟踪项目进度计划的步骤                   
 5.16 小结                   
 第6章 质量计划                   
 6.1 项目案例                   
 6.2 质量定义                   
 6.3 开发正确的产品                   
 6.4 正确地开发产品                   
 6.5 质量计划                   
 6.6 缺陷的概念                   
 6.7 消除缺陷的活动                   
 6.8 每一活动的条件                   
 6.9 缺陷消除目标                   
 6.10 质量改进小组                   
 6.11 质量褒奖                   
 第7章 高效的管理优先权                   
 7.1 项目案例                   
 7.2 首先解决最重要的问题                   
 7.3 步骤1:指明优先级                   
 7.4 步骤2:为每一个问题指定一个负责人                  
 7.5 步骤3:提交行动计划                   
 7.6 步骤4:每天评估进展                   
 7.7 对成功进行衡量                   
 第8章 产品需求:理解客户需要解决的问题                   
 8.1 项目案例                   
 8.2 产品需求的价值                  
 8.3 收集需求                   
 8.4 编写产品需求文档                   
 8.5 达成一致                   
 8.6 控制需求变更                   
 8.7 编写产品需求文档                   
 8.8 正确解决问题                   
 第9章 产品目标:为解决方案提供方向                   
 9.1 项目案例                   
 9.2 对产品目标的良好感觉                  
 9.3 今日投资, 明日收获                   
 9.4 产品目标中应该说明的内容                   
 第10章 产品规格说明书:定义最终产品                   
 10.1 项目案例                   
 10.2 控制功能蔓延                  
 10.3 步骤1:建立基线—完整地描述产品                   
 10.4 步骤2:从“认可者”处获得同意                   
 10.5 步骤3:维持控制—加强变更控制过程                   
 10.6 产品规格说明书应该阐述的内容                   
 10.7 计划控制                   
 第11章 产品易用性                   
 11.1 项目案例                   
 11.2 目标                   
 11.3 规格说明书                   
 11.4 原型                  
 11.5 测试计划                   
 11.6 易用性走查                   
 11.7 测试                   
 11.8 易用性:竞争的关键                   
 第12章 开发测试:强化薄弱环节                   
 12.1 项目案例                   
 12.2 单元测试                  
 12.3 单元测试计划                  
 12.4 功能测试                   
 12.5 功能测试计划                   
 12.6 预测代码质量的薄弱环节                   
 第13章 供应商关系—合同管理                   
 13.1 项目案例                   
 13.2 使用供应商的利弊                   
 13.3 与供应商签订合同的过程                   
 13.4 详细说明供应商的工作                   
 13.5 采取激励机制                   
 13.6 可跟踪的计划                   
 13.7 定期度量执行情况                   
 13.8 谁来负责                   
 13.9 质量体系                   
 13.10 考虑距离因素                   
 13.11 交付产品的验收                   
 13.12 产品售出之后的维护                   
 13.13 非特惠待遇                   
 13.14 选择供应商                   
 13.15 更换供应商                   
 13.16 法律事项                   
 13.17 子承包商                   
 第14章 项目完成后评审                   
 14.1 项目案例                   
 14.2 项目完成后评审的内容与步骤                   
 14.3 项目评审的内容与步骤                   
 14.5 小结                   

本目录推荐