迭代软件开发项目管理
基本信息
- 作者: (美)Kurt Bittner Ian Spence [作译者介绍]
- 译者: 罗景文 罗灿锋 张弘毅
- 出版社:清华大学出版社
- ISBN:9787302209522
- 上架时间:2010-6-24
- 出版日期:2010 年3月
- 开本:16开
- 页码:356
- 版次:1-1
- 所属分类:
计算机 > 软件工程及软件方法学 > 软件方法/软件工程
内容简介回到顶部↑
迭代过程已经得到了广大软件开发人员的普遍认可,它有助于降低风险和投资,管理变化,提高生产率,开发出更有效、快捷的解决方案。但是传统的项目管理技术不能很好地适应迭代项目,而且新的迭代管理技术还很少有文档支持。本书提供了一个很好的解决方案:它为任何迭代项目提供规划、组织、评估、人事招聘和管理方法,是一本非常实用的参考指南。
迭代开发领域的领衔专家kurtbittner和lan spence向读者介绍了一种经过验证的、可伸缩的方法来同时增加开发的敏捷性和可控性,从而满足了开发人员、管理人员和商家的需求。他们的技术容易理解,也易于和任何迭代方法同时使用,这些方法包括关系统一过程、极限编程、microsoft解决方案架构等。
不管您是团队带领人、程序管理员、项目经理、开发人员、赞助商,还是用户代表,本书都能使您受益匪浅。
本书主要内容:
·理解迭代项目成功的关键驱动者
·利用“时间盒”来定义项目周期、评估结果
·使用统一过程的阶段来推动所管理的迭代开发项目
·掌握迭代项目管理的核心概念,包括分层和演化
·创建项目的路线图,包括版本计划
·发现风险管理、评估、组织和迭代计划的关键模式
·理解什么必须重点控制,什么可以安全委托
·平滑地转移到迭代过程
·扩展迭代项目管理的方法,应用到不同规模的项目中
·统一软件投资和商业需求
不管您是否喜欢用rup、openup还是其他敏捷过程来进行软件开发,本书都能降低软件改进过程中的困难和成本,它提供了一种简单的、非入侵的途径来改进质量,并且不会使您和您的团队不知所措。
迭代开发领域的领衔专家kurtbittner和lan spence向读者介绍了一种经过验证的、可伸缩的方法来同时增加开发的敏捷性和可控性,从而满足了开发人员、管理人员和商家的需求。他们的技术容易理解,也易于和任何迭代方法同时使用,这些方法包括关系统一过程、极限编程、microsoft解决方案架构等。
不管您是团队带领人、程序管理员、项目经理、开发人员、赞助商,还是用户代表,本书都能使您受益匪浅。
本书主要内容:
·理解迭代项目成功的关键驱动者
·利用“时间盒”来定义项目周期、评估结果
·使用统一过程的阶段来推动所管理的迭代开发项目
·掌握迭代项目管理的核心概念,包括分层和演化
·创建项目的路线图,包括版本计划
·发现风险管理、评估、组织和迭代计划的关键模式
·理解什么必须重点控制,什么可以安全委托
·平滑地转移到迭代过程
·扩展迭代项目管理的方法,应用到不同规模的项目中
·统一软件投资和商业需求
不管您是否喜欢用rup、openup还是其他敏捷过程来进行软件开发,本书都能降低软件改进过程中的困难和成本,它提供了一种简单的、非入侵的途径来改进质量,并且不会使您和您的团队不知所措。
作译者回到顶部↑
本书提供作译者介绍
Kurt Bittner在IBM软件开发解决方案的策略部门工作。在其24年的职业生涯中,他成功地在多个行业和领域使用了软件开发的迭代方法。他是IBM关系统一过程原始开发团队中的一员,并与Ian Spence合著了《用例建模》(清华大学出版社引进并出版)。
Ian Spence是Ivar Jacobson咨询公司的首席科学家和首席咨询师,主要研究如何采用统
一过程和它所推荐的迭代、用例驱动方法。他在软件行业有20多年的经验,其中包括10多年的参与和管理迭代项目的经验。目前他致力于下一代轻量级软件开发进程的研究.. << 查看详细
Ian Spence是Ivar Jacobson咨询公司的首席科学家和首席咨询师,主要研究如何采用统
一过程和它所推荐的迭代、用例驱动方法。他在软件行业有20多年的经验,其中包括10多年的参与和管理迭代项目的经验。目前他致力于下一代轻量级软件开发进程的研究.. << 查看详细
目录回到顶部↑
第ⅰ部分 迭代项目管理原理
第1章 什么是迭代开发 3
1.1 迭代与科学方法 3
1.2 迭代的含义 4
1.2.1 迭代是一个独立的微型项目 4
1.2.2 迭代有一组独特的活动 5
1.2.3 每次迭代的结果都在“发布版本”中 6
1.2.4 迭代开发的特点 7
1.3 迭代体验 8
1.3.1 站在核心开发团队的角度分析迭代 8
1.3.2 站在客户的角度分析迭代 12
1.3.3 站在管理团队的角度分析迭代 19
1.4 小结 24
第2章 迭代项目的特性 25
2.1 迭代开发:最大化项目成功的机会 25
2.1.1 定义项目成功标准 25
2.1.2 成功和迭代项目 28
2.1.3 成功与迭代:收集项目成功的证据 29
2.2 一个成功的迭代项目的主要特征 30
2.2.1 可验证的、可客观度量的过程 30
第1章 什么是迭代开发 3
1.1 迭代与科学方法 3
1.2 迭代的含义 4
1.2.1 迭代是一个独立的微型项目 4
1.2.2 迭代有一组独特的活动 5
1.2.3 每次迭代的结果都在“发布版本”中 6
1.2.4 迭代开发的特点 7
1.3 迭代体验 8
1.3.1 站在核心开发团队的角度分析迭代 8
1.3.2 站在客户的角度分析迭代 12
1.3.3 站在管理团队的角度分析迭代 19
1.4 小结 24
第2章 迭代项目的特性 25
2.1 迭代开发:最大化项目成功的机会 25
2.1.1 定义项目成功标准 25
2.1.2 成功和迭代项目 28
2.1.3 成功与迭代:收集项目成功的证据 29
2.2 一个成功的迭代项目的主要特征 30
2.2.1 可验证的、可客观度量的过程 30
前言回到顶部↑
“任何作战计划在遭遇敌人后都会失效。”
陆军元帅Helmuth Von Moltke,1800-1891
如果计划无懈可击,如果一切有条不紊地进行,如果事情的进展始终与计划相符,就没必要执行迭代开发了。之所以使用迭代开发,是因为我们认识到,必须采取一种方法,以便面对变化取得进展,或即使发生变化也能取得进展。迭代开发本质上是一个动态规划和管理过程,在整个项目开发过程中,它会纳入甚至设法获得新信息来管理风险并连续交付增量价值。
迭代开发并非崭新方法,它由来已久,历经若干次的独立演进。它更注重适应环境,通常不注重完善的文档记录,更像是一种“即席”方法。本书将澄清这种认识——将系统地介绍您可以在项目中予以应用的迭代开发管理方法。
迭代方法的核心是将明确管理风险作为项目管理的基本指导原则。它将项目分解成一系列迭代,每个迭代通过实现“场景”减轻一组风险,“场景”必须制衡和控制风险。我们的目标是运用这些概念,并予以落实从而为其赋予生命力。我们要提供一种简明、直观且实用的方法来组织、评估和管理项目并且为项目配备人员,此方法不仅适用于微型项目,也可以扩展到宏大计划中。为此,需要推进一种切合实际的方法,以便按可预测、可重复、井然有序的方式获得结果。
在我们的从业经历中,我们使用IBM Rational Unified Process (RUP)2帮助多家公司采用了迭代开发方法,但迭代技术并非仅适用于统一过程3项目,实际上,它代表适用于任何迭代软件开发工作的通用方法。在使用极限编程4、针对敏捷软件编程的Microsoft Solution Framework或其他任何敏捷或迭代软件开发过程时,迭代技术同样行之有效。
本书旨在使任何拥有软件项目的基本管理背景的读者都可以理解迭代开发管理技术。它致力于呈现必需的实用指南信息,以便您开始以可控的、敏捷的、训练有素的方法管理迭代和增量项目。
管理软件项目面临的挑战
管理软件开发项目充满了挑战:适应快速变化的业务和技术环境意味着团队在不断突破极限。由于总是缺少拥有适当技能的人员,交付结果所承受的压力变得更大;另外,技术的演进速度极快。但团队必须对此做出响应,而且必须取得成功,因为这事关重大。如今,商业领域中的所有工作几乎都依赖于软件的使用,商业上的成功往往依赖于一些开发解决方案(由一系列软件构成)的开发团队的成功。
商业需求和实施技术在无休止地、飞快地变化着,这就要求软件开发项目对此做出快速敏捷的响应。软件开发敏捷性是当今和未来能否取得商业成功的决定性因素,对未来的影响尤其重大。
由于软件在支持日常业务运营和赢得竞争优势方面起到的至关重要作用,“软件治理”趋势呈现方兴未艾之势。简单说来,由于商业领域的成功依赖于软件领域的成功,商业决策者需要了解在信息技术和软件开发方面的投资如何换回利润。他们需要可见性与可说明性,如果他们不了解项目状态和发展轨迹,将面临极大风险。另外,在很多环境中,软件对于安全和业务流程的重要性意味着需要提供审计性(证明完成工作已经批准)。软件开发的治理是值得一提的事项。
最后,软件开发是一项极富创造性和协作性的工作,要取得成功,需要缜密协调来自多个不同学科(经常在不同地理区域和时区工作,有时还生活在不同的文化圈中)的不同人员的工作。发明和创新水准是优秀软件开发的基石,这意味着,开发并非是一个机械呆板的过程(即在开头制定完美计划,然后在执行期间予以监控)。这也导致了软件开发项目遇到令人寒心的因经营规模扩大而增加成本的问题——即大型项目每行代码的成本远高于小型项目5——此问题表明软件行业尚未学会如何完好地管理创新性、新颖性和复杂性。
迭代开发使这三个棘手问题迎刃而解,它提供能够满足业务需要的敏捷方法,提供治理开发过程所需的监控能力,同时培育解决复杂业务问题需要的创新能力和协作能力。
学习软件开发的管理艺术
每项工作的开展都离不开出色的管理。三十多年前,Frederick Brooks写下了这段至今仍如醍醐灌于众生头顶的名言:
“在很多方面,管理大型计算机编程项目与管理所有其他大事业一样,相似的方面比大多数编程人员想象的多。但在其他很多方面,它又与众不同,不同的方面比大多数职业管理人员想象的多6。”
这段话一语中的地点明了人们在考虑软件开发项目管理时容易掉入的两大陷阱。
·开发人员可以没有认识到职业管理实践给软件项目带来的价值,觉得项目管理人员的角色类似于Henry David Thoreau的作品“论公民的不服从权利”中谈及的政府角色:“管事最少的政府最英明”。
·管理人员可能不懂技术细节的重要性,也没有意识到无法完全委托这些细节;如果没有真正了解正完成的工作,将无从管理任务项目。
要取得成功,项目管理人员不仅要拥有扎实的传统管理实践基础,还要了解软件开发项目与其他项目类型的差异。项目管理人员只有熟谙工作才能判断工作是否走在正轨上。同时,只懂技术却不晓得如何激励和领导团队的管理人员也不称职——他们未能使团队拧成一股绳。
陆军元帅Helmuth Von Moltke,1800-1891
如果计划无懈可击,如果一切有条不紊地进行,如果事情的进展始终与计划相符,就没必要执行迭代开发了。之所以使用迭代开发,是因为我们认识到,必须采取一种方法,以便面对变化取得进展,或即使发生变化也能取得进展。迭代开发本质上是一个动态规划和管理过程,在整个项目开发过程中,它会纳入甚至设法获得新信息来管理风险并连续交付增量价值。
迭代开发并非崭新方法,它由来已久,历经若干次的独立演进。它更注重适应环境,通常不注重完善的文档记录,更像是一种“即席”方法。本书将澄清这种认识——将系统地介绍您可以在项目中予以应用的迭代开发管理方法。
迭代方法的核心是将明确管理风险作为项目管理的基本指导原则。它将项目分解成一系列迭代,每个迭代通过实现“场景”减轻一组风险,“场景”必须制衡和控制风险。我们的目标是运用这些概念,并予以落实从而为其赋予生命力。我们要提供一种简明、直观且实用的方法来组织、评估和管理项目并且为项目配备人员,此方法不仅适用于微型项目,也可以扩展到宏大计划中。为此,需要推进一种切合实际的方法,以便按可预测、可重复、井然有序的方式获得结果。
在我们的从业经历中,我们使用IBM Rational Unified Process (RUP)2帮助多家公司采用了迭代开发方法,但迭代技术并非仅适用于统一过程3项目,实际上,它代表适用于任何迭代软件开发工作的通用方法。在使用极限编程4、针对敏捷软件编程的Microsoft Solution Framework或其他任何敏捷或迭代软件开发过程时,迭代技术同样行之有效。
本书旨在使任何拥有软件项目的基本管理背景的读者都可以理解迭代开发管理技术。它致力于呈现必需的实用指南信息,以便您开始以可控的、敏捷的、训练有素的方法管理迭代和增量项目。
管理软件项目面临的挑战
管理软件开发项目充满了挑战:适应快速变化的业务和技术环境意味着团队在不断突破极限。由于总是缺少拥有适当技能的人员,交付结果所承受的压力变得更大;另外,技术的演进速度极快。但团队必须对此做出响应,而且必须取得成功,因为这事关重大。如今,商业领域中的所有工作几乎都依赖于软件的使用,商业上的成功往往依赖于一些开发解决方案(由一系列软件构成)的开发团队的成功。
商业需求和实施技术在无休止地、飞快地变化着,这就要求软件开发项目对此做出快速敏捷的响应。软件开发敏捷性是当今和未来能否取得商业成功的决定性因素,对未来的影响尤其重大。
由于软件在支持日常业务运营和赢得竞争优势方面起到的至关重要作用,“软件治理”趋势呈现方兴未艾之势。简单说来,由于商业领域的成功依赖于软件领域的成功,商业决策者需要了解在信息技术和软件开发方面的投资如何换回利润。他们需要可见性与可说明性,如果他们不了解项目状态和发展轨迹,将面临极大风险。另外,在很多环境中,软件对于安全和业务流程的重要性意味着需要提供审计性(证明完成工作已经批准)。软件开发的治理是值得一提的事项。
最后,软件开发是一项极富创造性和协作性的工作,要取得成功,需要缜密协调来自多个不同学科(经常在不同地理区域和时区工作,有时还生活在不同的文化圈中)的不同人员的工作。发明和创新水准是优秀软件开发的基石,这意味着,开发并非是一个机械呆板的过程(即在开头制定完美计划,然后在执行期间予以监控)。这也导致了软件开发项目遇到令人寒心的因经营规模扩大而增加成本的问题——即大型项目每行代码的成本远高于小型项目5——此问题表明软件行业尚未学会如何完好地管理创新性、新颖性和复杂性。
迭代开发使这三个棘手问题迎刃而解,它提供能够满足业务需要的敏捷方法,提供治理开发过程所需的监控能力,同时培育解决复杂业务问题需要的创新能力和协作能力。
学习软件开发的管理艺术
每项工作的开展都离不开出色的管理。三十多年前,Frederick Brooks写下了这段至今仍如醍醐灌于众生头顶的名言:
“在很多方面,管理大型计算机编程项目与管理所有其他大事业一样,相似的方面比大多数编程人员想象的多。但在其他很多方面,它又与众不同,不同的方面比大多数职业管理人员想象的多6。”
这段话一语中的地点明了人们在考虑软件开发项目管理时容易掉入的两大陷阱。
·开发人员可以没有认识到职业管理实践给软件项目带来的价值,觉得项目管理人员的角色类似于Henry David Thoreau的作品“论公民的不服从权利”中谈及的政府角色:“管事最少的政府最英明”。
·管理人员可能不懂技术细节的重要性,也没有意识到无法完全委托这些细节;如果没有真正了解正完成的工作,将无从管理任务项目。
要取得成功,项目管理人员不仅要拥有扎实的传统管理实践基础,还要了解软件开发项目与其他项目类型的差异。项目管理人员只有熟谙工作才能判断工作是否走在正轨上。同时,只懂技术却不晓得如何激励和领导团队的管理人员也不称职——他们未能使团队拧成一股绳。
序言回到顶部↑
中 文 版 序
Kurt和Ian都是我在Rational时的多年老同事,很荣幸有机会为他们这本大作的中文版作序。
迭代的思想其实由来久矣:在20世纪80年代中期,Barry Boehm提出了螺旋模型,Ivar提出了Objectory方法(Objectory是RUP的前身),但是今天往往被划入敏捷的范畴,反而被包装成新的理念。 在敏捷的十二条基本原则当中,有四条是直接和迭代相关的。迭代也因此成为敏捷中最重要的实践。可以说,绝大多数项目都应该采用迭代的方式去进行,因此我们IJI公司的软件工程咨询项目中全部采用开发方式。
·我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
·即使到了开发的后期,也欢迎改变需求,敏捷过程利用变化来为客户创造竞争优势
·经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好
·工作的软件是首要的进度度量标准
然而,迭代并不是一件简单的目标,为了有效地迭代,需要解决许多问题。例如,如何迭代地精化需求,如何将需求细化成可迭代的单元,如何规划迭代,如何组织迭代团队,迭代对测试有何新要求,如何在大型团队中推行迭代,等等。
我相信,读者一定能从此书中获得有益的启示!
吴 穹
IJI中国公司董事总经理
序 言
软件开发经历了一个漫长的发展过程。
“在黑暗中摸索”的年代里,我们墨守着沿袭传统项目管理方法的旧模型,即首先指定需求,然后将其“冻结”,直到结束前都不再改动需求。虽然开发周期十分清晰,即计划工作,然后再按计划工作,但其结果却乱作一团。
问题常变得扑朔迷离,软件开发组织声称成功完成了任务,并演示是根据需求规范交付的。但从商业的角度来看,系统必然是失败的,而且这在交付时会变得显而易见。为什么呢?
因为事情并非是一成不变的。所有大型软件开发项目都会持续相当长的时间,它们势必受到外界环境变化的影响:新技术的涌现、新竞争对手的出现、经济驱动力量的变化等。有时在外界压力的驱使下追求创新,而外界压力并非始终恰好落在软件开发周期范围内。在今天的快节奏世界里,如果您完全照搬最初的需求构建系统,事必会构建出一个错误的东西,导致自己在市场竞争中一败涂地。
虽然也存在执行不当的问题(根本原因可能也是原始需求模棱两可),但是一个经过无数次讨论总结出的结论是:即使执行过程完美无缺,也可能不会成功,原因是最初的方法足以导致所有管理者一败涂地。显然,我们需要一种新方法,这种方法应该着重于取得商业方面的成功,而不只是软件开发方面的成功。
现在,如果以顺应变化的能力来确定一个软件开发组织是否成功,我们将对这个问题有一个新的看法。变化会在需求中体现出来,因此软件开发组织所面临的最根本问题是处理需求波动的能力。此外,需求变化会随机出现,而且变化范围和出现时间由外界因素决定。也许您的项目节奏和周期井井有条,但需求的变化可能与项目的进展不同步。就像生活中无法加以控制的其他事情一样,您需要采取应对之策。有句话掷地有声:“要么顺应变化,要么被逼上绝路!”
本质上,这正是迭代开发关注的问题。它是软件开发对“交付有价值的软件系统”这一根本商业问题做出的回应。是的,“系统”是一个移动靶。我们放弃了将这个靶子钉死在墙上的不明智想法;我们努力地跟踪它并击中靶心。
Kurt和Ian都是我在Rational时的多年老同事,很荣幸有机会为他们这本大作的中文版作序。
迭代的思想其实由来久矣:在20世纪80年代中期,Barry Boehm提出了螺旋模型,Ivar提出了Objectory方法(Objectory是RUP的前身),但是今天往往被划入敏捷的范畴,反而被包装成新的理念。 在敏捷的十二条基本原则当中,有四条是直接和迭代相关的。迭代也因此成为敏捷中最重要的实践。可以说,绝大多数项目都应该采用迭代的方式去进行,因此我们IJI公司的软件工程咨询项目中全部采用开发方式。
·我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
·即使到了开发的后期,也欢迎改变需求,敏捷过程利用变化来为客户创造竞争优势
·经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好
·工作的软件是首要的进度度量标准
然而,迭代并不是一件简单的目标,为了有效地迭代,需要解决许多问题。例如,如何迭代地精化需求,如何将需求细化成可迭代的单元,如何规划迭代,如何组织迭代团队,迭代对测试有何新要求,如何在大型团队中推行迭代,等等。
我相信,读者一定能从此书中获得有益的启示!
吴 穹
IJI中国公司董事总经理
序 言
软件开发经历了一个漫长的发展过程。
“在黑暗中摸索”的年代里,我们墨守着沿袭传统项目管理方法的旧模型,即首先指定需求,然后将其“冻结”,直到结束前都不再改动需求。虽然开发周期十分清晰,即计划工作,然后再按计划工作,但其结果却乱作一团。
问题常变得扑朔迷离,软件开发组织声称成功完成了任务,并演示是根据需求规范交付的。但从商业的角度来看,系统必然是失败的,而且这在交付时会变得显而易见。为什么呢?
因为事情并非是一成不变的。所有大型软件开发项目都会持续相当长的时间,它们势必受到外界环境变化的影响:新技术的涌现、新竞争对手的出现、经济驱动力量的变化等。有时在外界压力的驱使下追求创新,而外界压力并非始终恰好落在软件开发周期范围内。在今天的快节奏世界里,如果您完全照搬最初的需求构建系统,事必会构建出一个错误的东西,导致自己在市场竞争中一败涂地。
虽然也存在执行不当的问题(根本原因可能也是原始需求模棱两可),但是一个经过无数次讨论总结出的结论是:即使执行过程完美无缺,也可能不会成功,原因是最初的方法足以导致所有管理者一败涂地。显然,我们需要一种新方法,这种方法应该着重于取得商业方面的成功,而不只是软件开发方面的成功。
现在,如果以顺应变化的能力来确定一个软件开发组织是否成功,我们将对这个问题有一个新的看法。变化会在需求中体现出来,因此软件开发组织所面临的最根本问题是处理需求波动的能力。此外,需求变化会随机出现,而且变化范围和出现时间由外界因素决定。也许您的项目节奏和周期井井有条,但需求的变化可能与项目的进展不同步。就像生活中无法加以控制的其他事情一样,您需要采取应对之策。有句话掷地有声:“要么顺应变化,要么被逼上绝路!”
本质上,这正是迭代开发关注的问题。它是软件开发对“交付有价值的软件系统”这一根本商业问题做出的回应。是的,“系统”是一个移动靶。我们放弃了将这个靶子钉死在墙上的不明智想法;我们努力地跟踪它并击中靶心。
【插图】

点击看大图


加载中...