具体描述
《Scrum敏捷软件开发》是敏捷联盟及Scrum联盟创始人之一、敏捷估算及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎之作，也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考。作者花四年时间，把自己近十五年的敏捷实践经验，特别是近四年中针对各种敏捷转型企业的咨询和指导工作，并结合旁征博引的方式，从更高的思想层次对敏捷与Scrum多年来的经验和教训进行深入而前面的梳理和总结，最终集大成者便是这本令人醍醐灌顶的佳作。
《Scrum敏捷软件开发》是软件企业及其管理团队成功进行敏捷转型战略及实施的必备参考书，适合经理、开发人员、教练、Scrum Master、产品负责人、分析师、团队领导或项目领导，是帮助他们成功完成项目，甚至造就敏捷企业的重要参考。
作者简介
Mike Cohn曾就职于财富500强公司、小公司、以及从事过两者之间的许多工作。凭借敏捷与Scrum的十五年的经验，Mike 用丰富的经验和广博的知识深度帮助您的组织创建和打造高绩效团队。
目录信息
第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
· · · · · · (收起)
读后感
首先要说的是，这本书不是面向初学者的，读者至少需要有一些敏捷开发的基本知识，如开发模式、迭代的概念等，最好可以有相关的开发经验。我们公司一直使用的是瀑布模型的开发方式，严格遵循着需求－设计－编码－测试的流程，虽然对敏捷开发和迭代模型我也有一些了解，但是看这...
评分首先要说的是，这本书不是面向初学者的，读者至少需要有一些敏捷开发的基本知识，如开发模式、迭代的概念等，最好可以有相关的开发经验。我们公司一直使用的是瀑布模型的开发方式，严格遵循着需求－设计－编码－测试的流程，虽然对敏捷开发和迭代模型我也有一些了解，但是看这...
评分看到了第二章，这本书写的不错，是对Scrum导入分析的很透的书，推荐大家阅读。 我总结了第一章的一些内容： 了解Scrum: 1. Scrum 适用于每一个公司。 2. Scrum 会引起公司很多部门的反对，原因之一是可能会影响一些人的仕途；它带来的变革是全面的，不局限于开发团队；没有...
评分【第5波赠书】赠敏捷开发类图书25本 活动规则： 1、推荐本帖子，并回复说明自己希望得到赠书的理由，一句话即可，当然长了也不反对。 2、获得赠书者须在收到赠书的2个周内回馈1篇500字以上的书评。 3、回复中位于9楼、99楼、199楼、299楼、399楼者将自动获得赠书1册，每楼1...
评分一本scrum方面的大部头, 很多内容讲的比较细, 也比较全, 很多地方都涉及到项目管理的知识, 当然还有敏捷相关的知识, 不过较少, 有选择性的看了看, 算是其他scrum书籍的一个补充吧. ------------------我是读书笔记的分割线------------------ scrum这个游戏如同围棋, 入门...
用户评价
这本书的封面设计真是别出心裁，那种深沉的蓝色调配上简洁的字体，一下子就抓住了我的眼球。拿到手里掂了掂，感觉内容应该会非常扎实。我本来对敏捷开发只停留在一些零散的知识点了解上，总觉得概念很飘，不够落地。这本书的开篇部分，作者用了一种非常亲切的口吻，像一位经验丰富的前辈在分享心得，而不是枯燥的说教。他没有直接抛出那些复杂的术语，而是从我们日常工作中遇到的痛点入手，比如需求不断变更、项目交付遥遥无期这些让人头疼的问题。这种叙述方式让我感觉找到了共鸣，仿佛作者早就洞察了我们这些一线开发人员的心声。尤其是对“价值交付”的阐述，不再是抽象的理论，而是和具体的工作流程紧密结合起来，让我对如何衡量进度的标准有了全新的认识。书中的案例分析也很到位，虽然是虚构的场景，但那种细节的真实感让人很难出戏，感觉就像是正在参与一个真实的迭代周期。整体来说，阅读体验非常流畅，文字功底扎实，逻辑清晰，没有那种晦涩难懂的技术术语堆砌，非常适合刚接触敏捷的职场新人，也给资深人士提供了一个重新审视自己工作方式的契机。
评分这份厚重的阅读体验，完全超出了我对一本“方法论”书籍的预期。它的排版和插图设计非常注重可读性，大量的图表和流程图，使得复杂的概念得到了直观的视觉化呈现。我尤其欣赏作者在介绍“计划会议”时所采用的视角转换技巧。他不是简单地告诉我们“要做什么”，而是引导我们思考“为什么这样做最有效率”。书中对“用户故事”的描述，那种强调“价值、角色、行动”的结构，以及如何用“验收标准”来量化完成度，讲得极其透彻。我曾参加过一些外部培训，讲师往往一笔带过，但这本书却像是手把手地教你如何写出真正能指导开发的任务描述。书中对“迭代周期”的长度选择，也给出了非常实用的参考范围，并且详细分析了不同行业和团队规模下的权衡取舍，避免了“一刀切”的僵化教条。读到关于风险管理的章节，作者展现了极高的前瞻性，敏捷并非没有计划，而是以更灵活的方式管理不确定性，这种成熟的观点让人信服。相比其他一些偏重于工具使用的书籍，这本书更侧重于“人”和“协作”的艺术，强调沟通的效率和透明度才是敏捷成功的核心驱动力，这一点非常值得我们深入研读和实践。
评分这本书的语言风格可以用“精准而富有洞察力”来形容。它没有使用那种浮夸的、过度承诺敏捷能解决一切问题的语气，反而保持了一种冷静、务实的分析态度。我特别喜欢作者在探讨“团队自组织”时所引用的心理学原理。他解释了为什么一个高信任度的环境才能催生真正的自组织，而不是简单地把决策权扔给团队。这种跨学科的融合，让整本书的理论深度大大增加，不再是停留在“敏捷口号”的层面。在解释“燃尽图”的解读时，书中提供了一套非常详尽的异常情况分析手册，教你如何从图表的变化中读出团队士气、技术瓶颈甚至产品方向偏差的早期信号。这对于项目经理和技术主管来说，简直是黄金般的数据分析指南。更难得的是，书中对“组织变革的阻力”也有独到的见解，它没有指责变革的反对者，而是分析了阻力背后的合理诉求，并提供了化解阻力的实用策略。阅读这本书的过程，就像是进行了一次高级别的思维体操，不断挑战你既有的工作惯性，强迫你从多个维度去审视现有的流程，从而找到更优化的路径。
评分这本书在内容编排上展现了极高的成熟度。它没有急于展示那些令人眼花缭乱的敏捷实践，而是花费了相当大的篇幅来铺垫敏捷背后的哲学思想和原则。作者对“拥抱变化”的解读，不再是简单地接受变更，而是将其视为获取市场反馈、快速调整航向的主动策略，这种主动性让我深受启发。在介绍“度量”时，书中明确区分了“指导性度量”和“惩罚性度量”的界限，极大地缓解了团队对数据收集的抵触情绪，强调度量是为了学习，而非为了考核。书中对“精益思想”的融入也处理得非常自然，将最小可行产品（MVP）的概念与迭代反馈紧密结合，形成了一个闭环的价值验证体系。我发现，书中的许多概念，虽然我以前也听过，但经过作者的重新组织和深入挖掘后，仿佛一下子被点亮了，从模糊的轮廓变成了清晰的实体。特别是关于跨职能团队内部沟通效率的优化建议，那些具体的对话技巧和会议引导术语，可以直接复制粘贴到日常工作中去使用。总而言之，这是一本兼具深度理论和实战指导的典范之作，它提供的不仅仅是知识，更是一种应对复杂性挑战的有效心智工具。
评分这本书的阅读过程，对我来说更像是一次系统性的思维重塑。我原本以为敏捷就是多开会、多站立，效率就能提高，但这本书彻底颠覆了我的刻板印象。作者在讲解“角色定义”时，花了大篇幅去探讨“产品负责人”的真正职责，不仅仅是需求的收集者，更是价值的守门人。这一点对我触动很大，以往我们团队里，这个角色往往是最模糊的，导致需求反复拉锯。书里构建了一个非常清晰的“心智模型”，让你能够一步步搭建起对整个框架的理解，而不是被零散的实践技巧所迷惑。最让我惊喜的是，它深入探讨了“技术债务”与敏捷实践的辩证关系。很多敏捷的书籍往往会忽略工程实践的根基，但这本书没有回避这个痛点，而是将技术质量视为持续交付价值的必要条件，这点体现了作者深厚的工程背景。书中对“回顾会议”的描述，也远超出了简单的“做得好/不好”的总结，它引导我们去探索流程中的系统性障碍，真正做到持续改进。文字的节奏感把握得极好，该快则快，快速带过已知的概念，该慢则慢，在关键的转折点会放慢语速，用大量的篇幅进行类比和深化。读完后，我迫不及待地想在下个 Sprint 中尝试书里提出的那些微调，期待能看到立竿见影的效果。
评分简单入门
评分核心内容在第13章，请注意前面不要看太细
评分核心内容在第13章，请注意前面不要看太细
评分不是很能看懂, 很难在精达时间scrum....
评分算是了解了下敏捷开发
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 qciss.net All Rights Reserved. 小哈图书下载中心 版权所有