关注微信

推荐商品

    加载中... 正在为您读取数据...
分享到:
  • 敏捷项目管理[平装]
  • 共3个商家     29.25元~30.00
  • 作者:克莱布斯(JochenKrebs)(作者),陈宗斌(译者),等(译者)
  • 出版社:机械工业出版社;第1版(2010年3月1日)
  • 出版时间:
  • 版次 :
  • 印刷时间:
  • 包装:
  • ISBN:9787111296980

  • 商家报价
  • 简介
  • 评价
  • 加载中... 正在为您读取数据...
  • 商品描述

    编辑推荐

    敏捷开发过程可以促进更好的协作、革新。《敏捷项目管理》阐明了在整个IT投资组合中应用敏捷过程所能带来的机会和所获得的回报。
    不论你是项目经理、业务分析师还是执行官,通过《敏捷项目管理》都可以理解在敏捷投资组合管理背后驱动的业务,并学会对结果进行优化的最佳方法。
    使用敏捷过程调整IT和业务战略:
    适应并扩展核心敏捷过程
    协调IT与业务愿景之间的协作
    对投资组合中的项目、资源和资产进行优化平衡
    使用指标来交流项目状态、质量和团队士气
    创建与机构目标一致的投资组合战略
    获得组织上和过程上的透明性
    使用敏捷方法管理业务,并借此将回报最大化!

    媒体推荐

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

    作者简介

    Jochen Krebs是一位杰出的敏捷辅导员和教师。他也是Incrementor(www. incrementor.com)—位于纽约的敏捷教练与培训服务公司的创办人。他关注敏捷项目管理和需求管理,在这方面他直接参与项目管理办公室及其投资组合工作。在他超过15年的职业生涯中,他在许多不同的行业中工作过,担任过许多不同的角色。比如,他曾经担任过面向对象开发人员、项目经理、教师、顾问以及辅导员。Jochen在Open University获得了工商业计算技术理学硕士学位。

    目录

    译者序
    前言
    致谢
    作者简介
    第一部分 敏捷与管理人员
    第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章 指标
    5.1 指标
    5.1.1 进展
    5.1.2 质量
    5.1.3 团队士气
    5.2 报告
    5.2.1 状态报告
    5.2.2 解释
    5.3 小结

    第6章 投资回报
    6.1 目标
    6.2 增量
    6.3 财务模型
    6.3.1 回收期
    6.3.2 净现值
    6.3.3 内部收益率
    6.3.4 成本效益分析
    6.4 项目提供的效益
    6.4.1 正在减少的效益
    6.4.2 效益最后期限
    6.4.3 正在增加的效益
    6.5 风险
    6.6 技术
    6.7 小结

    第7章 项目投资组合管理
    7.1 对项目投资组合进行平衡
    7.1.1 避免一次从事过多项目
    7.1.2 在投资组合中平衡有风险的和
    值得做的项目
    7.1.3 使用有愿景的项目来平衡投资
    组合
    7.1.4 避免限制愿景并阻碍开发的小
    项目
    7.2 初始化一个项目
    7.2.1 实现收集思想的过程
    7.2.2 展示业务案例
    7.2.3 业务案例的评估
    7.2.4 收集并管理提议
    7.2.5 项目竞争:让最好的项目胜出
    7.3 选择项目
    7.3.1 继续/不继续
    7.3.2 项目的暂停
    7.3.3 加速项目
    7.4 小结

    第8章 资源投资组合管理
    8.1 资源投资组合的平衡
    8.1.1 缺乏愿景
    8.1.2 项目太多但资源不够
    8.1.3 项目需要不同技能
    8.1.4 缺乏来自资源的反馈
    8.2 角色和资源池
    8.3 技能传授
    8.3.1 敏捷培训
    8.3.2 辅导
    8.4 全球化分布开发
    8.5 企业网络
    8.6 证书
    8.7 小结

    第9章 资产投资组合管理
    9.1 对资产投资组合进行平衡
    9.1.1 它首先是一项资产,然后是个
    路障
    9.1.2 “基业长青”是否是正面属性
    9.1.3 所有权的总成本
    9.2 小结

    第10章 投资组合在行动
    10.1 投资组合仪表板
    10.2 一个示例场景
    10.2.1 第一次迭代
    10.2.2 第二次迭代
    10.2.3 第三次迭代
    10.3 小结

    第三部分 机构和环境
    第11章 使用Scrum进行投资组合管理
    11.1 Scrum概述
    11.2 投资组合待办事宜
    11.2.1 项目投资组合待办事宜
    11.2.2 资源投资组合待办事宜
    11.2.3 资产投资组合待办事宜
    11.3 角色
    11.3.1 投资组合所有者
    11.3.2 投资组合队长
    11.3.3 投资组合经理
    11.4 活动
    11.4.1 投资组合冲刺计划会议
    11.4.2 投资组合Scrum会议
    11.4.3 投资组合冲刺回顾会议
    11.5 指标
    11.6 Scrum证书
    11.7 小结

    第12章 项目管理办公室
    12.1 敏捷项目管理的挑战
    12.1.1 敏捷项目团队是赋予力量且是自我组织的
    12.1.2 敏捷过程是以经验为依据的
    12.1.3 里程碑监视与过程报告
    12.1.4 项目管理的最优方法
    12.1.5 定义敏捷PMO的角色和职责
    12.1.6 PMO和投资组合管理
    12.1.7 为敏捷工作选择正确的工具
    12.1.8 开销和效益
    12.1.9 在敏捷环境中应用模型、标准和规则
    12.2 最大限度利用PMO
    12.2.1 辅导
    12.2.2 员工配备
    12.2.3 培训
    12.2.4 手册和发布说明
    12.2.5 发布团队
    12.2.6 指标
    12.2.7 状态
    12.2.8 投资组合
    12.3 小结
    附录 附加资源

    序言

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

    文摘

    插图:



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