首页 > 知识库 > 正文

Scrum精髓:敏捷转型指南是什么 关于Scrum精髓:敏捷转型指南的详细介绍

如何使用Scrum解决复杂问题,驱动更优成果,更快交付更具有价值的软件产品。www.shufadashi.com*??*?

《Scrum精髓:敏捷转型指南》是2014年清华大学出版社出版的图书, 作者是鲁宾 (Kenneth Rubin)。

敏捷软件过程大家都叫了这么多年了,Extreme Programming(XP),Scrum,Feature Driven Development(FDD),Lean Software Development,Agile Unified Process(Agile UP or AUP),Crystal,and Dynamic Systems

图书信息

Scrum精髓:敏捷转型指南

作者:Kenneth S. Rubin 姜信宝 米全喜 左洪斌

ISBN:9787302363859

定价:79元

印次:1-1

装帧:平装

印刷日期:2014-5-27

图书简介

短短几年时间,Scrum跃升为敏捷首选方法,在全球各地得以普遍应用。针对如何用好、用巧这个看似简单的框架,本书以通俗易懂的语言、条理清晰的脉络阐述和提炼出Scrum的精髓。全书共4部分23章,阐述了七大核心概念:Scrum框架,敏捷原则,冲刺,需求和用户故事,产品列表,估算与速率,技术债;五大角色:产品负责人,ScrumMaster,开发团队,Scrum团队构成:Scrum规划原则及四大规划活动:多层级规划、产品组合规划、产品规划和长期规划;冲刺四大活动:规划、执行、评审和回顾。

本书取自作者十多年的实践经验,对员工个体和管理层都具有重要的指导和参考意义,可以帮助企业顺利导入Scrum,在动态的商业环境中以积极心态拥抱变化,做出优秀、卓越的产品,走上创业、守业、常青基业的成功之路。

图书目录

第1章 引子 1

什么是Scrum? 2

Scrum的起源 3

为什么要用Scrum? 5

Genomica取得的成果 6

Scrum能给你带来帮助吗? 6

复杂域 9

繁杂域 10

简单域 10

混乱域 10

无序 11

事务性工作 11

结语 12

第Ⅰ部分 核 心 概 念

第2章 Scrum框架 17

概述 17

Scrum角色 19

产品负责人 20

ScrumMaster 20

开发团队 21

Scrum活动与工件 21

产品列表 23

冲刺 25

制定冲刺计划 26

冲刺执行 28

每日例会 29

完成 31

冲刺评审 32

冲刺回顾 33

结语 34

第3章 敏捷原则 35

概述 35

可变性和不确定性 37

积极采用有帮助的可变性 38

采用迭代和增量开发 39

通过检视、调整和透明充分

利用可变性 42

同时减少各种各样的不确定

因素 43

预测和适应 44

不到最后时刻,不轻易

做决定 44

承认无法一开始就把事情

做对 45

偏好适应性、探索式的方法 46

用经济合理的方法接受变化 48

平衡预测性的事前工作和

适应性的刚好及时工作

之间的关系 51

经验认知 52

快速验证重要的假设 52

利用多个认知循环并行的

优势 53

妥善组织工作流程以获得

快速反馈 54

WIP 56

批量大小要经济合理 56

识别并管理库存以达到良好的

流动 57

关注闲置工作,而非闲置

人员 59

考虑延期成本 61

进度 63

根据实时信息来重新制定

计划 63

通过验证工作结果来度量

进度 63

聚焦于以价值为中心的交付 64

执行 65

快速前进,但不匆忙 65

以质量为魂 65

采用最小够用的仪式 66

结语 68

第4章 冲刺 71

概述 71

时长限定 72

设定WIP数量限制 72

强制排列优先顺序 73

展示进度 73

避免不必要的完美主义 73

促进结束 74

增强可预测性 74

持续期短 74

容易规划 74

反馈快 74

投入产出比高 75

错误有限 75

有助于“满血复活” 75

检查点多 76

一致的持续期 77

有节奏感 78

简化规划活动 79

锁定冲刺目标 80

什么是冲刺目标? 80

共同承诺 80

是变更,还是澄清? 80

变更引起的后果 81

注重实效 83

异常终止 84

完成的定义 85

什么是完成的定义? 86

完成的定义可以随时间演变 88

完成的定义还是接收标准? 89

完成还是完成-完成 90

结语 91

第5章 需求与用户故事 93

概述 93

利用对话 96

逐步细化 97

用户故事是什么? 97

卡片 98

对话 99

确认 100

详细程度 101

好故事的INVEST原则 104

独立 104

可协商 105

有价值 106

可估算 107

大小合适 108

可测试 108

非功能性需求 109

知识获取型故事 110

收集故事 112

用户故事写作研讨会 112

绘制故事地图 113

结语 115

第6章 产品列表 117

概述 117

PBI 118

产品列表的四大特征 119

详略得当 119

涌现的 120

做过估算的 121

排列优先顺序的 122

梳理 123

什么是梳理? 123

由谁来梳理? 124

何时梳理? 125

就绪的定义 127

工作流管理 128

版本的工作流管理 129

冲刺的工作流管理 130

产品列表有哪些,应该有多少? 131

什么是产品? 132

大型产品,层级化列表 133

多个团队,一个产品列表 135

一个团队,多个产品 136

结语 137

第7章 估算与速率 139

概述 139

何时估,估什么? 141

组合列表条目的估算 141

产品列表条目的估算 142

任务估算 143

PBI估算的概念 143

团队估算 144

估算不是承诺 145

准确与精确 146

估算相对大小 147

PBI估算的单位 149

故事点 149

理想天 149

规划扑克 150

估算 151

活动规则 152

好处 155

什么是速率? 155

计算速率范围 156

预测速率 157

影响速率的因素 158

速率的误用 160

结语 161

第8章 技术债 163

概述 163

技术债的后果 165

爆发点不可预期 165

交付时间延长 166

缺陷数量可观 167

开发和支持成本上升 167

产品萎缩 168

可预测性降低 168

表现越来越差 168

挫折感四处弥漫 168

客户满意度降低 169

技术债的起因 169

如期完工的压力 169

试图以错误的方式提高速率 170

误区:减少测试可以提高

速率 171

债累债 172

技术债必须加以管理 173

管理应计技术债 174

使用良好的技术实践 174

使用强完成定义 175

正确理解技术债经济 175

让技术债可见 178

让技术债在业务层面可见 178

让技术债在技术层面可见 180

偿还技术债 181

并非所有技术债都应该偿还 182

行将就木的产品 183

一次性原型 183

短命产品 183

应用童子军规则

(有债就还) 184

分期偿还技术债 185

先偿还高息技术债 186

一边做有客户价值的工作,

一边偿还技术债 186

结语 188

第Ⅱ部分 Scrum的角色

第9章 产品负责人 191

概述 191

主要职责 192

管理经济效益 193

版本层面的经济考量 193

冲刺级别的经济考量 194

产品列表的经济考量 195

参与规划 195

梳理产品列表 195

定义接收标准并验证 196

与开发团队协作 196

与利益干系人协作 198

特征∕技能 198

领域能力 199

人际交往能力 200

决策力 200

责任心 201

日常工作内容 201

谁来担任产品负责人? 204

内部开发 205

商业开发 206

外包开发项目 208

组件开发 209

产品负责人兼任其他角色 210

产品负责人团队 210

产品负责人代理 211

首席产品负责人 212

结语 213

第10章 ScrumMaster 215

概述 215

主要职责 215

教练 215

服务型领导 217

过程权威 217

“保护伞” 217

“清道夫” 218

变革代言人 218

特征/技能 218

见多识广 218

善于提问 219

有耐心 219

有协作精神 220

保护团队 220

公开透明 220

日常工作内容 221

履行角色 222

谁来担任ScrumMaster? 222

ScrumMaster是全职

工作吗? 223

ScrumMaster兼任其他角色 223

结语 225

第11章 开发团队 227

概述 227

专职团队 227

主要职责 228

冲刺执行 229

每日检视和调整 229

梳理产品列表 229

冲刺规划 229

检视和调整产品与过程 230

特征/技能 230

自组织 231

跨职能的多样化和全面化 233

T型技能 234

火枪手态度 236

沟通广泛 237

透明沟通 239

规模适中 239

专注、有责任感 240

工作步调可持续 242

团队人员稳定 243

结语 245

第12章 Scrum团队结构 247

概述 247

特性团队与组件团队 248

多团队之间的协调 253

SoS 253

版本火车 255

结语 258

第13章 经理 259

概述 259

塑造团队 261

定义边界 261

提供一个清晰而鼓舞人心的

目标 262

组建团队 262

改变团队的人员组成 263

授权团队 264

培育团队 265

激励团队 265

发展团队能力 266

建立职能领导力 267

保持团队的完整性 267

整改环境 268

传播敏捷价值观 268

移除组织层面的障碍 268

使内部各个团队一致 269

使外部合作伙伴一致 269

管理价值创造流程 270

采用系统化视角 270

管理经济效益 270

测量和报告 271

项目经理 272

Scrum团队中的项目管理

职责 272

保留单独的项目经理角色 274

结语 278

第Ⅲ部分 规 划

第14章 Scrum的规划原则 283

概述 283

假设事先无法制定完美计划 284

事先规划有帮助,但不宜过度 284

最后责任时刻才敲定计划 286

关注适应与重新规划胜于

遵循计划 286

正确管理规划库存 288

提倡更小、更频繁发布 289

计划快速学习并在必要时

调头 291

结语 291

第15章 多层级规划 293

概述 293

组合规划 295

产品规划(构想) 295

愿景 295

概要产品列表 296

产品路线图 296

版本规划 298

冲刺规划 300

日常规划 301

结语 302

第16章 产品组合规划 303

概述 303

时间安排 303

参与者 304

流程 304

进度安排策略 306

优先考虑生命周期利润 307

计算延期成本 308

估算要准确,不必精确 311

流入策略 312

应用经济过滤器 313

到达率和离开率要平衡 314

快速拥抱新涌现的机会 316

为更小、更频繁发布做计划 317

流出策略 318

关注闲置工作,

而非闲置人员 318

设立WIP限制 319

等待整个团队一起行动 320

WIP策略 321

使用边际效益 321

结语 323

第17章 构想(产品规划) 325

概述 325

时间安排 326

参与者 327

过程 327

示例:SR4U 329

建立愿景 330

创建概要产品列表 333

定义产品路线图 334

其他活动 337

从经济合理的角度构想产品 339

瞄准一个实际的信心阈值 340

关注短期收益 341

动作要快 342

花钱买经验认知 343

使用递增/暂行的资助方式 344

快速学习并调头

(即快速失败) 345

结语 346

第18章 版本规划

(长期规划) 347

概述 347

时间安排 348

参与者 349

过程 349

版本约束 351

固定一切 352

固定范围和日期 352

固定范围 354

固定日期 354

可变质量 355

更新约束 355

梳理产品列表 356

细化最小可发布特性 357

冲刺映射(PBI归位) 358

版本规划:固定日期版本 360

版本规划:固定范围版本 365

计算成本 367

沟通进展情况 368

固定范围版本如何沟通 369

固定日期版本如何沟通 371

结语 373

第Ⅳ部分 冲 刺

第19章 冲刺规划 377

概述 377

时间安排 377

参与者 378

流程 378

冲刺规划的两种方式 380

两段式冲刺规划 381

一次性冲刺规划 382

确定生产能力 382

什么是生产能力? 382

用故事点来表示生产能力 384

用工时来表示生产能力 385

选取PBI 386

获得信心 386

细化冲刺目标 388

敲定承诺 388

结语 389

第20章 冲刺执行 391

概述 391

时间安排 391

参与者 391

流程 392

冲刺执行规划 393

工作流程管理 394

并行工作和蜂拥式 394

从哪个PBI开始 397

如何安排任务 397

需要完成哪些工作? 398

谁来做具体工作? 398

每日例会 399

任务执行:强调技术实践 399

沟通 401

任务板 401

冲刺燃尽图 402

冲刺燃烧图 404

结语 406

第21章 冲刺评审 407

概述 407

参与者 408

准备工作 410

确定邀请谁参加 410

安排活动日程 411

确认冲刺工作完成 411

演示准备工作 412

确定谁做什么 413

方式(方法) 413

总结 414

演示 415

讨论 416

调整 416

冲刺评审的问题 417

签字接收 417

断断续续地参与 417

大型开发工作 418

结语 419

第22章 冲刺回顾 421

概述 421

参与者 423

准备工作 424

定义回顾重点 425

选择练习活动 425

收集客观数据 426

安排回顾日程 426

方式(方法) 427

营造氛围 429

建立共同背景 429

事件时间线 431

情绪测震仪 431

得出见解 432

确定采取行动 437

回顾结束 438

贯彻执行 438

冲刺回顾的问题 439

结语 442

第23章 前进之路 443

Scrum,有完?没完! 443

修行靠个人 444

分享最佳实践 444

使用Scrum探明未来之路 446

整装待发! 447

后记 449

词汇表 453

参考文献 475

展开全部 如果严格按照书本上的 Scrum 法则一条条地看,那么我们队伍现在的做法也许根本不算 Scrum。不过好歹我们也被称作 Scrum 一段时间了,我的资历比不上前面的资深开发者,只能说一些目前的一点经验。经验一:整个团队必须理解 Scrum 的目的和限制。如果管理团队把 Scrum 当作一种新的管理流程,那么这个理解绝对是错误的,而且有害。要正确理解 Scrum 的实施原则,需要从理解其设计目的开始。我所理解的 Scrum 的目的在于两点:适应变化。Scrum 的一个基本假设,就是外部需求模糊而难以理解。Scrum 对此的理念是:让客户直接看到半成品,他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的:比如每个 Sprint 结束时由 Product Owner 为客户进行展示,又比如任务细化一般不超过一个 Sprint。理解了这一点,才会理解为什么 Scrum 似乎总在变化,因为需求总在变化。快速迭代。Scrum 的另一个基本假设,是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本,而竞争对手半年就能发布,那么几年之内,我们就会被对手甩得远远的。Scrum 对此的理念是:发布即 Milestone(里程碑),宁可每次发布二十个功能发布五次,也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点,才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。要实施 Scrum,整个团队至少必须取得共识,即以上两点是不能商量的。流程必须为目的服务。如果队伍相信增加前期沟通才是让需求清晰起来的最好方法,或者相信发布的功能必须是大批量一次性,那么请使用瀑布开发模式。相应地,我们必须明白 Scrum 不能做什么。我的理解可能耸人听闻,仍是两点:因为发布周期缩短,团队没有能力保证作出的每一个决定都正确,很多开销都必须花在试错上;快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队,因为一个人的离职或病假都可能对单一功能的进度造成影响,不利于短期频繁发布。Scrum 对此的解答是:不要试图不犯错误,而是保证小的错误能被尽快发现从而不会酿成大错。所以 Scrum 过程中总会有些不确定性,或者功能不合需求而返工,或者突然缺了人手导致一些单个功能必须延期完成。如果非要事先确定发布周期而且还得保证不许功能裁剪,请出门左转找 CMM 认证:它可以把任务精确到每个对话框上该用什么字体。前期计划精确到这个粒度,什么都可以在掌控之中。但问题是,我们必须用更长的发布周期来换。理解了上面的内容,我们实施时就不会对某些形式性的东西过于纠结,比如 Burn down chart,比如 Scrum 扑克。需知形式服务于目的,而形式未必适用于每一个团队,正如瀑布模型在每一个团队中也都有差异。如果仅仅是因为团队成员没有在 planning meeting 上打扑克就认定这不是 Scrum,那么未免愚蠢了些。反过来,某些看似烦人的「流程」却不可或缺,比如每天的 15 分钟 stand-up,如果我们明白它对交流方面的重要作用,就绝对不会认为它可以被省略。举个实际的例子,在我们的团队里,我们强迫一周一个 Sprint。就我所知,即使在很多实施很成功的项目中,这种做法也是相当激进的。一开始我也不理解这一点,但实施了一段时间后,我开始认同这一条,因为一周的发布周期让我们没有机会把任务往后推,从而迫使我们尽快从瀑布模型中转移出来。这对一个有着悠久瀑布开发传统的团队来说非常重要,但对别的团队来说,就不一定了。经验二:正确定位队伍中的 Scrum Master。为什么单独提 Scrum Master?如果只是看书本和参加培训,我相信多数人都会同意我的观点,即 Scrum Master 或许是整个开发过程中作用最不清楚的角色:不参与需求分析、不参与代码开发、甚至不参与任何人事问题,只有一句「去除阻碍」这种含糊的表述。但是,当我真正当起这个 Scrum Master 之后,才发现这个角色承担的职责非常具体。比如:确保流程执行正确。进入 Scrum 之后,很多团队仍然会以各种方式走老路,比如有意无意地拉长 Sprint 周期,并以此区别计划周、开发周和测试周,实际上是把原来三个月的瀑布开发周期变成了两到四个星期的瀑布周期;又比如以开发时间有限为理由把自动测试开发任务缩减为手工测试。好的 Scrum Master 应该有能力发现并制止这种情况。顺便说一句,相信我,不要以为两个星期的瀑布周期是个可行的开发计划,我们不可能完成测试任务的。制止官僚主义流程。典型的例子就是一个又一个的 spec/plan review 和 sign-off 邮件;又比如非要区分所谓 Unit Test、BVT 和 Functional Test:或许对一个图形界面程序来说这两者区别极大,可对于函数库则几乎没有原则差别。合格的 Scrum Master 应该制止这样的倾向。不过我也得说,这一条我现在做得很差,还需要改进。构建交叉知识结构。整个团队的知识模型应该是各有专长但互有交叉的,而传统开发的一个很重要的问题是知识结构不平衡,比如测试的只管测试,开发的只管开发。这种模式对于发布时间长的大团队来说也许能接受,但对人手短缺又要求快速发布的小团队则是致命的。好的 Scrum Master 应当能够对团队的决策具备影响力,确保不会让某个任务陷入「只有一个人知道细节」的情况。这一条在习惯了传统瀑布开发模型的团队中往往是最大的阻碍,需要时间改善。但正因为上面的理解,我基本上不同意 Scrum Alliance 的教科书里关于 Scrum Master 的大多数表述。首先,Scrum Master 必须承担一部分开发任务,因为没有介入一线开发,很难想象 Scrum Master 会真正理解团队的「痛点」。其次,Scrum Master 需要关注团队的每一个人,不然队伍可能由于所谓「自组织」的原则而隐藏一些问题,比如某个人过于专精某一项而忽略了和其它成员的交流。当然,也有些部门的 Scrum Master 只负责写报告和推事情。这不是我共事过的任何一位 Scrum Master 的做法,而且我也可以很自信地说,这种 Scrum Master 在我们公司是生存不下去的。Scrum Master,你是肩负着人类使命的人啊!最后,贴两句最近刚学到的话:50%percent of our decisions are wrong.Fail fast,learn fast.(我们作出的决定中,50%都是错误的。早早失败,早早学习。No matter what you want to do,choose what is good for your team.(无论你选择做什么,选择对你的团队有利的事)先声明,说上面两句话的哥们本人在我们队伍里不算很受欢迎,但这两句我很喜欢。在我眼里,这两句话指出了 Scrum 的所有实质。共勉之。Scrum 是众多敏捷开发方法中的一种,它既是方法论,也包括了一系列预定义的角色、一系列的流程,以及一系列的实践经验。那么践行Scrum 到底是应该坚持以理论为准绳,还是从实际角度出发,有所舍弃和调整?一个可运行的 Scrum 流程的主要步骤是怎样的?首先聊聊敏捷开发的价值观对于敏捷开发来讲,有人说是流程、是方法论是工具,但对于我来讲它更是一种精神,它并没有局限在流程、方法、工具上。敏捷软件开发的目的就是解决需求中的变化和中的不可控因素。当时提出敏捷开发的这个人或者这个群体,提出来的是敏捷开发的四个价值观:第一,个体的互动要高于流程和工具;第二,可工作的软件要高于详尽的文档;第三,客户的合作高于合同谈判;第四,响应变化高于遵循计划。这四点价值观是最能体现敏捷开发的核心的东西,其精髓就是拥抱变化,而不是控制变化。了解Scrum 是什么很重要Scrum 是什么?它既是方法论,也包括了一系列预定义的角色、一系列的流程,以及一系列的实践经验,包括需要的文档。我提出的一个观点是,对于我有用的就做,对于产品、项目没有用的就不做,但是Scrum 实际上不是这样的。你想做到Scrum 有些东西是必须要做的。所以我也希望大家能够自己批判性、灵活用它,而不是死板用它。Scrum的主要角色Scrum 主要定义了三个角色:Scrum Master,Product Owner,Development Team。Scrum Master 不是Project Manager,他的主要的工作是要保证这个团队执行 Scrum 的顺畅。Product Owner 是真正对产品负责的人。如果我们是做产品研发的话,产品经理就是Product Owner。如果我们是做项目开发,客户就是Product Owner,这也体现了我们刚刚提到,我们并不是和客户去谈判,而是真正把客户放在我们的这种流程中,真正与他合作。第三种 Development Team 就是干活儿的。所以 在Scrum 里面没有管理者的概念。另外,Scrum 里面实际上所有的真正为最终产出的软件付出的,都叫Development Team。这个地方也体现了一个Scrum 的观点,就是它希望能够打造Cross-Functional Team,即在这个团队中的所有人可以做所有的事情,每个人都是Development Team。Scrum的开发流程Step1.需要一个 Vision真正Scrum 的流程是什么样子的?首先,我们需要有一个Vision,就是我们所做的产品或者所做项目的愿景。这个需要所有Team Members,包括Product Owner 一起确定,然后大家朝着同样的目标前进。Step2.维护BacklogVision 出现后,Product Owner 会维护一个Scrum 中我们提到的第一个文档,即 Backlog。它可以理解成我们从产品当中,从各个角度收集的需求,Product Owner 要做的事情就是维护Product Backlog,并且将Backlog 一条一条的按照优先级排好顺序。Product Owner 是唯一有权利维护这个列表的人。这个时候合理利用工具,就能免去写文档的的这一步,可以直接将需求通过任务的方式收集,每个需求就是一条任务,Product Owner 可以给任务打标签来标示优先级。Step3.拆分Sprint随后我们会针对这个Scrum 把它拆分成一个个的Sprint,就是开发周期。然后将 Backlog 里面的项目添加到Sprint 中去,成为Sprint Backlog。每一个Sprint 开始的时候,需要进行一个Sprint Plan。Step4.运行Sprint PlanSprint Plan 就是整个团队一起,通过Backlog 从优先级最高的这个item 开始挑,挑出ProductOwner 对Backlog 进行介绍。紧接着的是,大家将Backlog 拆分成单个的Task,每一个成员在每一天的工作当中领Task,完成Task。由此可见,在完美的Scrum 里面,是没有任务指派一说的。每个..*www.shufadashi.com*?*?

声明:本网内容旨在传播知识仅供参考,不代表本网赞同其观点,文字及图片版权归原网站所有。

你可能还关注
热门推荐
今日推荐 更多