![]() 作者:Mike Cohn 出版社: 清华大学出版社 原作名: Succeeding with Agile: Software Development using Scrum 译者:廖靖斌/吕梁岳/陈争云/阳陆育 出版年: 2010-11 页数: 474 定价: 69.00元 装帧: 平装 ISBN: 9787302238799 内容简介 · · · · · ·《Scrum敏捷软件开发》是敏捷联盟及Scrum联盟创始人之一、敏捷估算及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎之作,也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考。作者花四年时间,把自己近十五年的敏捷实践经验,特别是近四年中针对各种敏捷转型企业的咨询和指导工作,并结合旁征博引的方式,从更高的思想层次对敏捷与Scrum多年来的经验和教训进行深入而前面的梳理和总结,最终集大成者便是这本令人醍醐灌顶的佳作。 《Scrum敏捷软件开发》是软件企业及其管理团队成功进行敏捷转型战略及实施的必备参考书,适合经理、开发人员、教练、Scrum Master、产品负责人、分析师、团队领导或项目领导,是帮助他们成功完成项目,甚至造就敏捷企业的重要参考。 作者简介 · · · · · ·Mike Cohn曾就职于财富500强公司、小公司、以及从事过两者之间的许多工作。凭借敏捷与Scrum的十五年的经验,Mike 用丰富的经验和广博的知识深度帮助您的组织创建和打造高绩效团队。 目录 · · · · · ·第i部分 启 航第1章 为什么敏捷转型难(但值得) 3 为什么转型困难 5 成功的变革不是完全的自上而下 或者自下而上 5 结束状态是不可预知的 6 · · · · · ·() 第i部分 启 航 第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 第ii部分 个 体 第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 第iii部分 团 队 第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 第iv部分 组 织 第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 第v部分 下 一 站 第21章 看看进展如何 455 测量的目的 455 一般性的敏捷评估 456 撒丹遵守度调查 457 agile: ef 459 比较式敏捷评估 460 创建你自己的评估 464 scrum团队平衡计分卡 465 构建平衡记分卡 466 推崇简单度量 468 我们真的在意这些吗 470 延伸阅读 471 第22章 没有终点 473 · · · · · · () |
描述领域之多
为我提供了一个解看历史和现实的全新视角。
文字却通俗易懂
果然有独到的见解