敏捷项目管理

出版时间：2010年4月  出版社：机械工业出版社  作者：Jochen Krebs  页数：189  译者：陈宗斌  
Tag标签：无  

前言

　　如果你学过经济，就肯定了解制定战术计划和制定战略计划之间的区别。在20世纪80年代，行动的战术窗口只是3～5年的计划，而战略计划则超过5年，最多可达10年。在20世纪90年代，也就是信息时代起飞之后，变革的速率及其附加作用极大地减少了计划窗口的大小，而软件开发周期也减少了。到现在，我不认为还有以20世纪80年代的周期作计划的机构存在，尤其是在信息技术这一部分。实际上，我听到经理们讲这么一个笑话：“战术是今天所要做的，战略是为明天做计划。”如同许多笑话一样，笑话之中有真理。　　变革的速率影响着我们将来开发系统的方式，尤其是那些较大的系统。项目的时间表越长，项目范围成为战略的一部分的几率就越高。我们从过去许多经验中得知，一个花费了两年时间进行的项目的结果不一定会和我们对它的期待一致。传统项目的计划精确度非常粗糙，这是造成这种问题的原因之一。　　为了解决这个问题，许多机构采用或试用敏捷开发方法-这是一种基于迭代-增量开发的方法，它将项目的范围分解为更小的、可管理的块。从管理的角度看，这是一种理想方法，因为即使是最长的战略性项目也会有一个战术上的组件：即将进行的迭代。而正是这个组件将使得执行官、项目经理以及项目团队得以掌好项目的舵，带领项目驶向并不精确的愿景。想转变为敏捷方法并不是一件容易的事情。改变带来机会，也总需承担风险，敏捷开发的机会和风险均有不少。本书将探究敏捷方法为开发机构及其领导力带来的机会，也将探究潜在的风险问题。　　我编写本书的动机之一是想把我的职业生涯内在项目团队内外所观察到的信息与大家分享。这些观察的结果有许多都能追溯到同一个根本原因：在机构内，我所目睹到的各个方面都缺乏信任。　　在长期以传统方式管理的项目过程中，许多项目状态报告（尤其是在项目早期阶段）过于乐观。首先，要让业务分析师或软件工程师知道他们的进度落后于时间表是一件极为困难的事情。在分析之前或在分析过程中，想知道总共有多少分析量是不可能的。如果不知道总量，我们如何知道现在的工作正按部就班呢？而后在项目进行时，如果项目由于有新的发现而延期，但执行分析的人早已离开，他们已经转移到新的项目上了。　　其次，长久以来，我们一直受到这样的教导：项目经理是负责人。他管理团队，指派任务并且承担整体项目成功的责任。所有这些压力以及所有这些期望都指向同一个人，这个人也负责项目的沟通交流工作。有了这样的场景，我们怎么可能期望项目沟通交流是中立的？高级执行官如果要求每周多给出一份详细的状态报告，那么这不就已经是一种不信任的底层形式了吗？在我的职业生涯里，我不断看到这些机能失调和不信任的症状。　　敏捷投资组合管理并不排除书面交流方式，但它确保沟通进行在执行中的项目所产生的现有敏捷指标的基础。敏捷投资组合管理在项目团队和执行官之间建立了一个清晰定义的接口，而其建立在敏捷实践的基础上。这些实践建立在信任之上，并且会对任何朝向组织上的敏捷所作的转变带来正面的影响。

内容概要

敏捷开发方法流行于那些发现传统瀑布法无法适应这个由改变、革新而驱动的世界的要求的企业。既然敏捷开发过程带来更好的结果，那么也能将这个方法应用于整个IT投资组合中。在一个企业中，朝向敏捷方式的改变既带来机会也带来风险，本书将探究敏捷方法为开发机构及其领导力带来的机会和回报，也将探究其潜在的风险问题。　　本书适合项目经理、投资组合经理、业务分析师、PMO成员以及执行经理等对采纳敏捷实践和投资组合管理感兴趣的人士阅读。　　敏捷开发过程可以促进更好的协作、革新。本书阐明了在整个IT投资组合中应用敏捷过程所能带来的机会和所获得的回报。　　不论你是项目经理、业务分析师还是执行官，通过本书都可以理解在敏捷投资组合管理背后驱动的业务，并学会对结果进行优化的最佳方法。　　使用敏捷过程调整IT和业务战略：　　适应并扩展核心敏捷过程　　协调IT与业务愿景之间的协作　　对投资组合中的项目、资源和资产进行优化平衡　　使用指标来交流项目状态、质量和团队士气　　创建与机构目标一致的投资组合战略　　获得组织上和过程上的透明性　　使用敏捷方法管理业务，并借此将回报最大化！ 　　

作者简介

Jochen Krebs是一位杰出的敏捷辅导员和教师。他也是Incrementor（www. incrementor.com）—位于纽约的敏捷教练与培训服务公司的创办人。他关注敏捷项目管理和需求管理，在这方面他直接参与项目管理办公室及其投资组合工作。在他超过15年的职业生涯中，他在许多不同的行业中工

书籍目录

译者序 前言 致谢 作者简介 第一部分 敏捷与管理人员 　第1章 动机 　　1.1 管理的期望 　　　1.1.1 迟到的变更 　　　1.1.2 需求瘫痪 　　　1.1.3 二义性 　　　1.1.4 需求太多 　　　1.1.5 需求太少 　　　1.1.6 变更控制委员会 　　1.2 上市时间 　　1.3 革新 　　1.4 资金供给 　　1.5 小结 　第2章 敏捷软件开发 　　2.1 定义 　　　2.1.1 敏捷是什么 　　　2.1.2 敏捷过程 　　　2.1.3 敏捷宣言 　　　2.1.4 敏捷联盟 　　　2.1.5 敏捷项目领导力网络 　　2.2 敏捷开发的关键实践 　　　2.2.1 迭代-增量开发 　　　2.2.2 测试驱动开发 　　　2.2.3 持续集成 　　　2.2.4 面对面交流 　　2.3 敏捷项目中所需观察的事情 　　　2.3.1 结对编程 　　　2.3.2 每日例会 　　　2.3.3 与需求有关的故事 　　　2.3.4 团队工作室 　　　2.3.5 频繁发布 　　　2.3.6 自我组织的团队 　　2.4 小结 　第3章 项目管理 　　3.1 传统项目管理 　　　3.1.1 工作分解结构 　　　3.1.2 甘特图 　　　3.1.3 关键路径分析 　　　3.1.4 项目报告 　　　3.1.5 对挑战的小结 　　3.2 敏捷项目管理 　　3.3 角色与职责 　　　3.3.1 角色 　　　3.3.2 责任 　　3.4 小结 第二部分 定义、计划并衡量投资组合 　第4章 基础 　　4.1 事实 　　4.2 机构 　　　4.2.1 职能型的机构 　　　4.2.2 项目型的机构 　　　4.2.3 矩阵型的机构 　　4.3 复合结构 　　4.4 项目管理办公室 　　4.5 术语和定义 　　　4.5.1 项目 　　　4.5.2 程序 　　　4.5.3 投资组合 　　4.6 涉众 　　4.7 目标 　　　4.7.1 太多项目 　　　4.7.2 项目很少能终止 　　　4.7.3 没有足够的资源可用 　　　4.7.4 缺乏指标 　　　4.7.5 没有愿景 　　4.8 小结 　第5章 指标 　第6章 投资回报 　第7章 项目投资组合管理 　第8章 资源投资组合管理 　第9章 资产投资组合管理 　第10章 投资组合在行动 第三部分 机构和环境 　第11章 使用Scrum进行投资组合管理 　第12章 项目管理办公室 附录 附加资源

章节摘录

　　2006年，在线电影租赁公司Netfix在NPR宣布，只要有人能将他们的电影推荐系统改进至少10％就给予100万美元的奖金。一年以后，到了2007年11月，仍旧没有人赢取这项现金大奖。　从许多角度来看，将这样的奖励方法公之与众都是一家公司革新其业务的新的、独特的手段。下面我们通过与按传统方式执行的项目作比较来看其如此创新的原因所在。　　首先，这家公司承认公众在为Netfix的顾客推荐电影这项工作上可以做得更好。Netfix也承认它自己无法解决这个问题，这是一个巨大的心理因素。想想有些公司在涉及知识产权问题时的保护态度吧。这个例子所涉及的问题要比仅仅从顾客那里收集反馈和想法多得多。这一比赛是要求提供解决某特定问题的聪明的方案。　　其次，Netfix采用了与开源开发类似的方法，而不是将解决方案外包给承包商。每个人都得到了邀请，都能有所贡献，但有一个很大的不同：赢家将获得很慷慨的奖金。Netfix使用了全球工程师网络的力量来解决问题，而不是把自己限制在少数几个合作伙伴中。　　再次，公司已经在内部对这个功能定了量——因推荐而实现10％改进所增加的收入以及增加的客户满意度足够支付这一大笔奖金。　　最后但并非不重要的一点，这个示例也为竞争对手展示了Netfix致力于改进其系统中的一个元素的决心以及所关注的顾客服务领域。有了这个声明，革新就转向公开。　　作为回报，这个奖励为Netfix带来铺天盖地的宣传和争论，我相信这与整个比赛本身一样有创意。甚至，从该公司开放的愿景和创新所吸引的人们中，公司可能获得新的业务机会。　　革新需要创新，以及持续不断地对现有业务过程进行重新思考。可是能在现代业务过程中应用的新技术可能仍旧在婴儿期。20世纪，IT在将企业内手工的、乏味的信息交换工作进行自动化的同时，也培养了新一代的对IT系统有高度期待的专业人士。Netfix的示例表明，人们所探讨的正在从以技术为动机的开发转向以业务为动机的解决方案。

媒体关注与评论

　　“Jochen的书揭示了企业在投资组合管理上应用敏捷方法丢失的环节。”　　——Mike Clhn,《Agile Estimating and Planning》的作者

用户评论 (总计5条)

•   一次买了N本书，分发了
•   收到了,还在学习中
•   内容很好，但有些翻译得不好。
•   正在读，内容不错，值得一看
•   看看文章，理理思路，写的一般