返回首页
苏宁会员
购物车 0
易付宝
手机苏宁

服务体验

店铺评分与同行业相比

用户评价:----

物流时效:----

售后服务:----

  • 服务承诺: 正品保障
  • 公司名称:
  • 所 在 地:
本店所有商品

  • [正版]Scrum敏捷软件开发 项目管理从入门到精通 敏捷转型战略书 软件定制开发 科恩 清华大学出版社
  • 正版图书!品质保证!默认发最新版本!收藏店铺可享优先发货!
    • 作者: (美)科恩著 | | 廖靖斌译
    • 出版社: 清华大学出版社
    送至
  • 由""直接销售和发货,并提供售后服务
  • 加入购物车 购买电子书
    服务

    看了又看

    商品预定流程:

    查看大图
    /
    ×

    苏宁商家

    商家:
    友一个文化制品专营店
    联系:
    • 商品

    • 服务

    • 物流

    搜索店内商品

    商品参数
    • 作者: (美)科恩著| 廖靖斌译
    • 出版社:清华大学出版社
    • 开本:16
    • ISBN:9784800344544
    • 版权提供:清华大学出版社

            铺公告

      为保障消费者合理购买需求及公平交易机会,避免因非生活消费目的的购买货囤积商品,抬价转售等违法行为发生,店铺有权对异常订单不发货且不进行赔付。异常订单:包括但不限于相同用户ID批量下单,同一用户(指不同用户ID,存在相同/临近/虚构收货地址,或相同联系号码,收件人,同账户付款人等情形的)批量下单(一次性大于5本),以及其他非消费目的的交易订单。

    温馨提示:请务必当着快递员面开箱验货,如发现破损,请立即拍照拒收,如验货有问题请及时联系在线客服处理,(如开箱验货时发现破损,所产生运费由我司承担,一经签收即为货物完好,如果您未开箱验货,一切损失就需要由买家承担,所以请买家一定要仔细验货)。

      关于退货运费:对于下单后且物流已发货货品在途的状态下,原则上均不接受退货申请,如顾客原因退货需要承担来回运费,如因产品质量问题(非破损问题)可在签收后,联系在线客服。

     

     

    满39包邮
    全国包邮
    2018-05-24 18:24:00 - 2019-03-31 18:24:00 截止
    下单满就减,赶快购买吧!
    单笔订单满39包邮( 包邮地区:辽宁、吉林、黑龙江、北京、天津、河北、山西、山东、上海、江苏、安徽、浙江、江西、湖北、湖南、河南、广东、福建、陕西 )

     书名:  Scrum敏捷软件开发
     图书定价:  ¥ 69 元
     图书作者:  科恩(Mike Cohn) (作者) 廖靖斌 (译者), 吕梁岳 (译者),
     出版社:  清华大学出版社
     出版日期:  2010
     ISBN号:  9787302238799
     开本:  16
     装帧:  平装
     页数:  474页
     版次:  第1版
    《Scrum敏捷软件开发》是敏捷联盟及Scrum联盟创始人之一、敏捷估算及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎之作,也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考。作者花四年时间,把自己近十五年的敏捷实践经验,特别是近四年中针对各种敏捷转型企业的咨询和指导工作,并结合旁征博引的方式,从更高的思想层次对敏捷与Scrum多年来的经验和教训进行深入而前面的梳理和总结,最终集大成者便是这本令人醍醐灌顶的佳作。 
    《Scrum敏捷软件开发》是软件企业及其管理团队成功进行敏捷转型战略及实施的必备参考书,适合经理、开发人员、教练、Scrum Master、产品负责人、分析师、团队领导或项目领导,是帮助他们成功完成项目,甚至造就敏捷企业的重要参考。

    第1部分 启 航 
    第1章 为什么敏捷转型难(但值得) 3 
    为什么转型困难 5 
    成功的变革不是完全的自上而下 
    或者自下而上 5 
    结束状态是不可预知的 6 
    scrum是无处不在的 8 
    scrum是截然不同的 9 
    变化来得比以往更快 10 
    最佳实践是危险的 10 
    为什么值得投入 11 
    更高的生产力及更低的成本 13 
    员工的参与度和工作满意度增强 15 
    更快的产品上市时间 16 
    更高的质量 17 
    项目干系人的满意度提升 18 
    现在的做法已经不再有效 19 
    承前启后 20 
    延伸阅读 20 
    第2章 adapt模型 23 
    意识 25 
    意识开发工具 27 
    渴望 29 
    渴望提升工具 30 
    能力 33 
    能力开发工具 34 
    推广 37 
    scrum推广工具 38 
    传递 40 
    “企业重力”的来源 41 
    承前启后 44 
    延伸阅读 45 
    第3章 scrum实施模式 47 
    小团队试点,还是全面转型 47 
    选择小团队试点的原因 48 
    选择全面转型的原因 49 
    在全面转型和小团队试点之间 
    选择 50 
    公开敏捷,还是悄悄行动 51 
    选择公开展示敏捷的原因 52 
    选择悄悄行动的原因 53 
    从公开展示和悄悄行动中做出 
    选择 54 
    scrum的推广模式 55 
    先拆分后播种 55 
    先成长后拆分 56 
    内部教练 57 
    优先选择先拆分后播种模式的原因 57 
    选择先成长后拆分模式的原因 58 
    选择内部教练模式的原因 58 
    选择你自己的方式 59 
    引入新的技术实践 60 
    马上开始的原因 61 
    推迟尝新的原因 62 
    最后一点考虑 62 
    延伸阅读 64 
    第4章 渐进敏捷 67 
    改进backlog 68 
    企业转型社区 70 
    etc的 sprint 72 
    发起人和产品负责人 73 
    etc的职责 74 
    改进社区 77 
    改进的催化剂 78 
    有效性的两个度量指标 79 
    改进社区sprint 80 
    关注实际相关的目标 82 
    改进社区的成员 82 
    解散社区 84 
    一种尺寸不能适合所有的 85 
    承前启后 85 
    延伸阅读 85 
    第5章 试点项目 87 
    选择试点项目 87 
    理想试点项目的四个属性 88 
    选择合适的时机启动项目 90 
    濒临失败的项目 91 
    选择试点项目团队 92 
    试点项目不成功会怎样 94 
    设定和管理期望 95 
    关于进度的期望 95 
    关于可预测性的期望 97 
    关于对scrum态度的期望 98 
    关于参与程度的期望 98 
    不过是个试点项目 99 
    延伸阅读 100 

    第2部分 个 体 
    第6章 克服抵触 103 
    预见抵触 103 
    哪些人会抵触 104 
    瀑布深信症和敏捷恐惧症 106 
    关于变革的沟通 107 
    从领导那里听到 107 
    从同伴那里听到 108 
    个体抵触的方式和原因 109 
    怀疑论者 112 
    破坏者 115 
    顽固分子 116 
    追随者 119 
    把抵触视为一个有用的危险信号 121 
    延伸阅读 122 
    第7章 新角色 123 
    scrummaster的角色 123 
    优秀scrummaster的品质 124 
    技术带头人担任scrummaster 127 
    内部或外部的scrummaster 128 
    轮流担任scrummaster 129 
    克服共同的问题 130 
    产品负责人 132 
    产品负责人的职责 132 
    每个团队只需要一个产品负责人 135 
    优秀产品负责人的品质 138 
    scrummaster担任产品负责人 139 
    克服普遍问题 140 
    新角色,老责任 143 
    延伸阅读 143 
    第8章 角色转换 145 
    分析员 145 
    项目经理 148 
    为什么头衔要发生变化 150 
    架构师 151 
    不编码的架构师 152 
    职能经理 153 
    职能经理的领导角色 153 
    人员管理职责 155 
    程序员 155 
    数据库管理员 157 
    测试员 157 
    用户体验设计师 160 
    三个常见主题 163 
    延伸阅读 163 
    第9章 技术实践 165 
    追求技术进步 165 
    测试驱动开发 166 
    重构 169 
    集体所有权 171 
    持续集成 172 
    结对编程 174 
    设计:有意的而又是涌现式的 176 
    习惯于不做大型设计 178 
    引导设计 179 
    技术实践的改进并不是可有可无的 182 
    延伸阅读 182 

    第3部分 团 队 
    第10章 团队结构 189 
    给他们两个匹萨 189 
    为什么两个匹萨就够了 191 
    小团队的效率 192 
    支持特性团队 195 
    保守地使用组件团队 197 
    谁来做这些决定? 201 
    今天对,明天可能错 201 
    自组织不等于随意组合 202 
    一人一个项目 205 
    任务太多的时候,花在单一任务上的 
    时间会减少 206 
    何时可以多任务 208 
    公司的多任务表 209 
    立刻停止 209 
    良好的团队结构指导原则 211 
    承前启后 213 
    延伸阅读 213 
    第11章 团队协作 215 
    拥抱团队责任制 215 
    培养团队承诺 217 
    依赖专家但须谨慎 218 
    所有工作总是逐渐完成 220 
    不要等到sprint快结束时才完成 
    所有任务 221 
    承诺完成不同粒度的产品backlog 
    事项 222 
    鼓励团队学习 223 
    确保学习环境 223 
    设计学习型团队 224 
    消除知识浪费 228 
    通过承诺鼓励合作 230 
    承前启后 232 
    延伸阅读 233 
    第12章 领导自组织团队 235 
    影响自组织团队 236 
    容器、差异与交流 237 
    选择外部环境 245 
    定义绩效 245 
    管理思想 246 
    引入替换选择系统 246 
    给系统注入能量 247 
    领导力远不仅限于买匹萨 249 
    延伸阅读 249 
    第13章 产品backlog 251 
    从文档到讨论的转变 252 
    切勿良莠不分 254 
    在产品backlog中使用用户故事 255 
    持续地提炼需求 258 
    涌现的需求 258 
    产品backlog冰山 259 
    为什么要持续地提炼需求? 261 
    对用户故事的持续提炼 262 
    学会在没有详细说明书的情况下开始 266 
    通过事例说明 267 
    跨职能的团队能降低对文档的 
    需求 270 
    创建deep的产品backlog 271 
    不要忘记讨论 271 
    延伸阅读 272 
    第14章 sprint 273 
    每个sprint应递交可工作的软件 274 
    “潜在可交付”的含义 275 
    识别"潜在可交付"的指导方针 276 
    每个sprint提交一些有价值的东西 279 
    在当前sprint为下个sprint做准备 282 
    台球短跑 283 
    只在一个sprint中塞入能完成的 
    东西 283 
    每个sprint始终保持协作 285 
    避免特定活动的sprint 286 
    用完成-完成的关系取代完成-开始的 
    关系 288 
    用户体验设计的交迭 289 
    全盘思考,增量工作 290 
    系统架构和数据库设计 292 
    保持时间箱定期性和严格性 294 
    绝不要延长sprint 295 
    不要改变目标 297 
    放弃改变团队目标的习惯 299 
    获得反馈,学习和适应 301 
    延伸阅读 301 
    第15章 做计划 303 
    逐步完善计划 304 
    不要用加班来赶计划 306 
    历经挫折后才会明白 307 
    达到目标 308 
    如果不加班,怎么办 310 
    如果可能,支持改变范围 311 
    考虑其他选择 312 
    项目环境是关键 315 
    区别对待估算和承诺 316 
    用正确的数据来做 317 
    从估算到承诺 320 
    历史估算是承诺的基础 321 
    小结 325 
    延伸阅读 326 
    第16章 质量 327 
    把测试集成到流程中 327 
    为什么最后才测试没有效果 328 
    什么是构建质量 330 
    不同层次的自动化 331 
    保留用户界面测试的角色 334 
    手工测试角色 334 
    在sprint内做自动化 335 
    关于收益的例子 337 
    验收性测试驱动开发(attd) 338 
    恰到好处的细节 339 
    偿还技术债务 341 
    通过三个步骤3降低测试债务 342 
    质量需要团队的共同努力 344 
    延伸阅读 344 

    第4部分 组 织 
    第17章 扩展scrum 349 
    扩展产品负责人 350 
    共享责任,分割职能 351 
    完成大型产品backlog的工作 352 
    一个产品,一个产品backlog 352 
    保持产品backlog大小合理 354 
    主动管理依赖 356 
    进行滚动的前瞻性计划会议 357 
    举行发布启动会议 359 
    共享团队成员 360 
    使用集成团队 361 
    在团队间协调工作 363 
    scrum of scrums会议 364 
    同步sprint 367 
    扩展sprint计划会议 368 
    错开一天 369 
    大房间 370 
    培养实践社区 371 
    正式的或非正式的 373 
    创造有利于社区形成和繁荣的 
    环境 374 
    参与 375 
    scrum确实能扩展 376 
    延伸阅读 377 
    第18章 分布式团队 379 
    决定如何分布多个团队 380 
    形成凝聚力 383 
    承认显著的文化差异 383 
    承认微小的文化差异 385 
    加强职能和团队的亚文化 386 
    通过强调早期进展来建立信任 389 
    现场见面会 392 
    播种访问 392 
    联络访问 394 
    旅行大使 395 
    改变沟通方式 397 
    添加一些文档 397 
    给产品backlog添加细节 398 
    鼓励横向沟通 399 
    会议 400 
    一般性建议 401 
    sprint计划会议 403 
    每日站会 406 
    scrum of scrums 410 
    sprint评审和回顾 411 
    谨慎行事 412 
    延伸阅读 413 
    第19章 与其他方法论共存 415 
    混合scrum和顺序式开发 415 
    三种交互场景 416 
    冲突的3个领域 417 
    scrum和顺序式能永远共存吗? 419 
    监管 420 
    用非敏捷的监管来运行scrum项目 421 
    兼容 422 
    iso 9001 423 
    能力成熟度模型集成(cmmi) 425 
    实现兼容 427 
    下一步 428 
    延伸阅读 429 
    第20章 人力资源、后勤和pmo 431 
    人力资源 432 
    管理层次结构 433 
    定期的绩效评估 434 
    开除团队成员 436 
    职业发展 437 
    只要有人参与,就总是存在与人 
    相关的问题 438 
    后勤 439 
    空间 439 
    将作战指挥室变到整个空间 440 
    家具 442 
    在工作空间里应该可见的东西 444 
    项目管理办公室 446 
    人员 447 
    项目 448 
    过程 449 
    重新命名pmo 450 
    底线 451 
    延伸阅读 451 

    第5部分 下 一 站 
    第21章 看看进展如何 455 
    测量的目的 455 
    一般性的敏捷评估 456 
    撒丹遵守度调查 457 
    agile: ef 459 
    比较式敏捷评估 460 
    创建你自己的评估 464 
    scrum团队平衡计分卡 465 
    构建平衡记分卡 466 
    推崇简单度量 468 
    我们真的在意这些吗 470 
    延伸阅读 471 
    第22章 没有终点 473

    《Scrum敏捷软件开发》:
    全景呈现Scrum敏捷成功之点滴
    萃取Mike Cohn敏捷思想之精华
    通用、经过实证且百分百行之有效的Scrum与敏捷实践指南
    对于Scrum与敏捷快速转型及其与传统之间的持久战,《Scrum敏捷软件开发》提供了通用、实际和可操作的指导。声誉卓著的领军人物MikeCohn,优秀的敏捷顾问和践行者,从自己多年来帮助数百家软件公司进行Scrum和敏捷改革的无人媲美的经历中,提取出细节纷呈的建议、令人醒醐灌顶的提示和实际案例研究。
    《Scrum敏捷软件开发》是为实施s仁rum过程中勇敢面对重重挑战并渴望征服这些难题的实干家准备的。Cohn全面概述了整个转型过程:启动转型、帮助个人适应新的角色、组建团队、扩展Sct,Um到多团队项目、分布式团队项目以及最后的实施效果度量和持续改善。
    贯穿全书,Cohn基于自己最成功的建议,创设了“试一试”特色段落。与此相得益彰的“反对”特色段落则重现与变革抵制人员之间的典型对话,提供实际有效的指导来打消其疑虑。
    本书主题:
    立即着手转型和迅速进入正轨的几种实用方法
    克服个人对Scrum变革的抵触
    建立由变革积极推动者组成的“改进社区”
    选择要使用或试验的敏捷技术实践
    领导自组织团队
    最有效的的Scrum迭代、计划和质量技巧
    将Scrum扩展到分布式以及多团队项目
    将Scrum用于复杂的顺序过程项目或富有挑战的、有服从和管控需求的项目
    理解Scrum对人力资源、后勤和PMO的影响
    不管你已经完成多个Sprint,还是多个敏捷项目,不管你的角色是经理、开发人员、教练、产品负责人、Scrum Master、分析师、团队领导或项目领导,本书都可以帮助你赢得当下项目的成功,甚至帮助你走得更远,实现整个开发机构的成功转型。

    “理解敏捷过程的工作机理是远远不够的。Mike Cohn提炼了大量精妙而丰富的建议。在个人与团队面对具体的挑战时,这些建议将帮助他们从容地采纳和调整敏捷过程。《Scrum敏捷软件开发》将成为敏捷团队不可或缺的权威指南,不可或缺的基本指导手册。” 
    ——Colin Bird,EMC咨询公司,全球敏捷总监 
    “《Scrum敏捷软件开发》所介绍的实用方法和有价值的洞见,充分彰显了Mike Cohn在帮助如此多软件开发企业采纳敏捷方法的过程中所积累的丰富经验。如果您真的希望坚持敏捷方法,请不要错过这本书。” 
    ——Jeff Honious,Reed Elsevier,创新副总裁 
    “Mike Cohn再次获得成功。《Scrum敏捷软件开发》取材于他的亲身经历,也基于我们大家的经历。他的描述从项目早期开始,直到项目尾声,提供了针对个人、团队乃至整个企业的建议。不管您是否已经开始敏捷,都能通过本书找到自己想要的!” 
    ——Ron Jeffries,www.XProgramming.com 
    “如果打算开始或者深入敏捷软件开发,本书就是为您准备的。书中讨论了敏捷项目存在的问题,提供了出色的解决方案和有用的指导。在将敏捷方法引入一个受FDA管辖的大型部门时,我们广泛使用了《Scrum敏捷软件开发》这本书中所提到的指导方针。” 
    ——Christ Vriens,飞利浦研究院,MiPlaza部门主管 
    “如果敏捷转型对您而言,总是犹抱琵琶半遮面,那么这本书可以揭开她的神秘面纱。Mike Cohn毫无保留地为我们全景呈现了一套全面、基本且不含半点水分的行动指南,促使并推动软件企业转型为更强大、更有创意和更有竞争力的成功企业。” 
    ——Steve Greene,www.salesforce.com,项目管理与敏捷开发高级总监 
    “Mike Cohn是一位不同凡响的软件企业转型顾问。本书凝聚着他多年来帮助软件企业实现敏捷转型的所有精华。如果您正在考虑向敏捷进发,请选择这本《Scrum敏捷软件开发》。”——Christopher Fry博士,www.salesforce.com,平台开发副总裁 
    “不管您是刚有开始Scrum征途的想法,还是略有Scrum经验,都可以通过阅读《Scrum敏捷软件开发》,在Mike Cohn的引导下开始自己持续改进的探索之旅。贯穿全书,敏捷的概念通过Mike这些行之有效的建议得以进一步巩固和升华,这些建议包括如何处理反对的声音,以及发人深省的“试一试”特色段落。各章最后的“延伸阅读”使得本书更是业内人士“不容错过”的典藏精品。” 
    ——Nikki Rohm,艺电,项目和资源管理,工作室总监 
    “使用Scrum来改进软件过程在初期是困难的,每一步都会遇到新的挑战。在《Scrum敏捷软件开发》这本书中,Mike Cohn向我们阐述了其他企业是如何度过这个阶段的,让我们知道如何从中学习成功实施Scrum的经验,让企业走上持续改进和交付价值的道路。” 
    ——Johanes Brodwall, 挪威Steria公司,首席科学家 
    “当我一开始审阅Mike Cohn这本书的时候,我就开始推荐它。貌似一有人向我问起敏捷开发的问题,我总是意识到我刚刚在Mike Cohn这本书的某些章节中读到过一些非常出色的内容。我很高兴,这本书终于付梓出版,我可以不再说‘Mike Cohn有一本新书很快要出版,书中将谈到这个问题。’现在,我可以说‘Mike的书上市了!去买一本吧!’” 
    ——Linda Rising,与Mary Lynn Manns合著Fearless Change:Patterns for Introducing New Ideas 
    “书名已经说明了一切。这是一本以敏捷软件开发成功之路为主线的指南,非常深入和实用。如果你只看一本敏捷方面的书,那么就这本书啦!我现在就想把它推荐给我所有的客户!” 
    ——Henrik Kniberg,敏捷教练,敏捷联盟董事会成员,《硝烟中的Scrum与XP》作者 

    .“Mike Cohn的《Scrum敏捷软件开发》融合了深入的理论知识与实用的实操技巧。这是他创作的又一本非常出色的敏捷佳作。他将帮助您的团队、部门及整个企业取得敏捷的成功。” 
    ——Matt Truxaw,Kaiser Permanente IT,应用程序交付经理,认证的ScrumMaster 
    “Mike Cohn的这本新书是企业向Scrum转型的最佳指南。它的内容非常实用,也很容易理解。赶紧拥有她,阅读,然后应用。” 
    ——Roman Pichler,Agile Product Management With Scrum作者 
    “《Scrum敏捷软件开发》这本书不仅非常实用,而且写得很深刻,读来引人入胜。它结合软件行业中的实际案例和故事中的好的想法,吸引了更多的读者,从那些将要在企业范围内实施敏捷过程的读者,到那些只是在某一个项目上需要改进团队工作方式的开发者。” 
    ——Andrew Stellman,开发人员,项目经理,Head First PMP,Beautiful Teams和 
    Applied Software Project Management作者 
    “在一家小公司采纳敏捷方法开发一个新的Web应用程序已属不易,更别提在一个企业内部实施敏捷转型了。《Scrum敏捷软件开发》描述了我们面临的挑战,提供了深刻的见解,更重要的是提供了很多实用的方法。” 
    ——Michael Wollin,CNN广播产品系统,高级开发经理 
    “Mike Cohn在这本非常出色的书中给出了许多有效的指引, 不仅仅是针对如何开始Scrum实施,还包括如何将整个企业转型为敏捷型企业。我已经实践了书中给出的许多建议,已经领略到对企业的Scrum实施所产生的积极影响。” 
    ——James Tischart,CSM,CSP,CTFL,Mx Logic公司,产品交付副总裁 
    “在《Scrum敏捷软件开发》这本书中,Mike Cohn收集和精选了集体的经验和教训,除了他自己经历的许多不同的项目、团队及企业的敏捷经验,还包括了其他许多团队的经验。他提供了许多实战中的真实故事、有用的数据及研究,针对实施、适应和扩展Scrum过程中哪些有效和哪些无效,提供了非常有价值的见解。我最喜欢这本书的原因是,Mike Cohn针对若干个不同的备选方案和方法及其各自最适用的场景,提供了他的智慧。” 
    ——Brad Appleton,《财富》100强某电信企业,内部敏捷顾问 
    “我相信,Mike Cohn的这本书可以回答个人或团队在艰难地改进协作、沟通、质量和团队效率这一过程的许多问题和困难。我非常欣赏和认同Mike Cohn的观点:‘在要求持续改进的过程中,没有结束状态。’这是一个非常困难的工作,需要坚持、团队精神和优秀人才。我计划将《Scrum敏捷软件开发》作为企业内部的必备读物,就像《敏捷估算与计划》一样。” 
    ——Scott Spencer,First American CoreLogic公司,工程部副总裁 
    “Mike Cohn再一次取得了成功。这本书针对敏捷软件开发进行全面研究,提供了有助于成功的许多技巧和方法。我向期望改进软件开发过程的所有人力荐此书。” 
    ——Benoit Houle,BioWare(隶属艺电),高级开发经理 
    “毫无疑问,Mike Cohn的这本新书将成为如何进行Scrum软件项目的参考书。这本书经过精雕细琢,尽量避免给出一个单一的、简单的方案来解决所有问题。以Scrum为主线,Mike通过描绘其他各种技术,构成这样一本透彻、完整的手册。这不是一本依靠信仰或单一经验而仓促拼凑而来的书。书中的示例都非常有说服力,这也是Mike Cohn非凡敏捷经验的一个强有力的证明。” 
    ——Philippe Kruchten,英属哥伦比亚大学,软件工程系教授 
    “针对企业如何才能敏捷,《Scrum敏捷软件开发》充满大量有用的建议。对于面临真实世界中挑战(比如如何将敏捷扩展到分布式团队)的敏捷教练或变革推动者,对于寻求组织广泛参与的人员,这是一本非常实用的手册。我非常喜欢Mike Coke这种生动的行文方式,即来自行业的真实故事和紧随其后的研究数据与结论相结合。每一章,我都能学到新东西,我打赌你肯定也会。” 
    ——Rachel Davies,Agile Coaching作者之一

    作者:(美国)科恩(Mike Cohn) 译者:廖靖斌 吕梁岳 陈争云 等

    Mike Cohn Mountain Goat Software创办人,以帮助客户公司成长为卓越软件开发组织为己任,专门提供Scrum与敏捷软件开发培训。Mike Cohn是敏捷运动两大公认名著(《用户故事与敏捷方法》和《敏捷估算与规划》)的作者。他曾经历任多个软件开发公司(从新创公司到《财富》40强)的技术总监,曾服务子BBC(英国国际广播公司)、Capital One(美国第—投资集团),Electronic Arts(艺电)、Experian(益百利)、Gooqle(谷歌)、Intuit(直觉软件公司)、Lexis Nexis(律商联讯)。

    这本书不是为那些刚接触Scrum或敏捷概念的人们而准备的。有其他书籍、课程甚至网站可以帮助他们。如果你在Scrum方面是新人,可以从其中的一种方式着手。这本书也不是为那些纯粹主义者而准备的(译者注:纯粹主义者指特别执着于完美理论阐述的人)。他们其实可以找到很多这方面的博客,来争辩什么是真正的敏捷或Scrum。这本书为实用主义者而生。写给那些已经开始尝试Scrum且可能已经遇到一些问题的人,以及那些虽然没有开始但已经按捺不住跃跃欲试的人。这些人需要的已经不是关于如何画一张燃尽图,或者是在每日站会上如何给出三个问题的答案等入门介绍。他们需要的是一些更加高阶的课题——比如如何在企业或者项目中引入Scrum,并进行推广,如何帮助人们在项目初期放弃大的设计,如何在每个Sprint交付可以工作的软件,经理应该做什么,等等。如果这些课题你似曾相识,本书正好可以满足你的需要! 
    本书借助我过去15年的Scrum经验(特别是最近四年以来的经验),来帮助大家找到这些问题的答案。在最近的四年中,每次我见完一个客户,就会在晚上回到酒店后整理和记录他们面临的难题、他们提出的疑问及我当时所给出的建议。然后我会通过回访或者电子邮件的方式进一步跟踪这些问题。我只想通过实践真切地确认我的哪些建议能最终解决哪些方面的问题。

    在20世纪90年代中期,我在一家公司工作,它的激励目标是通过改变病人和诊断者的交互方式实现医疗的突破性革新。公司以一个呼叫中心的护士为中心,还有一群为她们开发系统的开发人员来支持。每周护士长要发一封电子邮件总结一周的重要信息。多数是些鸡毛蒜皮的小事儿:增加多少新的病人、接听多少电话、回答电话的平均时间等。
    不平凡的、帮助实现公司激励目标的东西是对被我们救治的病人生命的总结。我记得护士长有一封电子邮件中谈到一个特别电话。打电话者是一个左上背部疼痛的男病人。他想知道他是需要看医生还是只服用一些止痛药。通过询问一些问题,并在我们软件的专家系统指导下,护士断定打电话者心脏出了问题。在对方挂断电话前,她调派了一辆救护车,从而拯救了他的生命。一个激励目标并不是非要高尚到拯救生命,它只是一些能够让团队兴奋和感兴趣并渴望参与其中的事物。
    深入了解固有的激励。不仅仅是寻求团队范围的激励目标,也要发掘团队成员已有的激励动机。不同的人,有不同的激励动机,如果一个项目可以让每个人不同的个人目标和项目目标保持一致,那么这个项目就可以产生期望的承诺。也许JaⅧ开发人员想要获得C#的经验。有机会在项目上满足他的期望吗?也可能某个测试员期望积累一些领导经验。是否可以赋予她一些职责,让她来管理外包给一个合作伙伴开发的一个组件。

     

    1
    • 商品详情
    • 内容简介

    售后保障

    最近浏览

    猜你喜欢

    该商品在当前城市正在进行 促销

    注:参加抢购将不再享受其他优惠活动

    x
    您已成功将商品加入收藏夹

    查看我的收藏夹

    确定

    非常抱歉,您前期未参加预订活动,
    无法支付尾款哦!

    关闭

    抱歉,您暂无任性付资格

    此时为正式期SUPER会员专享抢购期,普通会员暂不可抢购