硝烟中的Scrum和XP：我们如何实施Scrum pdf下载

《硝烟中的Scrum和XP：我们如何实施Scrum》源自真实的故事，Henrik Kniberg以过来人的身份，回顾了他在一年时间内带领40人团队实施敏捷转型和持续过程改进的亲身经历。在Henrik的领导下，团队经历了不同的规模，不同的sprint长度，不同的定义“done”的方式，不同格式的产品backlog和sprint backlog，不同的测试策略，不同的演示方式，同步多个Scrum团队工作的不同方式，如此等等。他们还尝试了XP实践——体验不同方式的持续构建、结对编程、测试驱动开发等，阐述了如何结合使用XP与Scrum。
书中的特色在于实践，对正在实施Scrum敏捷软件开发的读者具有一定的参考价值和指导作用。

第1章 简介
免责声明
撰写本书的原因
scrum到底是什么

第2章 我们怎样编写产品backlog
额外的故事字段
我们如何让产品backlog停留在业务层次上

第3章 我们怎样准备sprint计划
第4章 我们怎样制定sprint计划
为什么产品负责人必须参加
为什么不能在质量上让步
无休止的sprint计划会议......
sprint 计划会议日程
确定sprint长度
确定sprint目标
决定sprint要包含的故事
产品负责人如何对sprint放哪些故事产生影响
团队怎样决定把哪些故事放到sprint里面
用本能反应来估算
用生产率计算来估算
我们用的是哪种估算技术
我们为何使用索引卡
定义“完成”
使用计划扑克做时间估算
明确故事内容
把故事拆分成更小的故事
把故事拆分成任务
定下每日例会的时间地点
最后界限在哪里
技术故事
bug跟踪系统vs.产品backlog
sprint计划会议终于结束了

第5章 我们怎样让别人了解我们的sprint
第6章 我们怎样编写sprint backlog
第7章 我们怎样布置团队房间
第8章 我们怎样进行每日例会
第9章 我们怎样进行sprint演示
第10章 我们怎样做sprint回顾
第11章 sprint之间的休整时刻
第12章 怎样制定发布计划，处理固定价格的合同
第13章 我们怎样结合使用scrum和xp
第14章 我们怎样做测试
第15章 我们怎样管理多个scrum团队
第16章 我们怎样管理分布式团队
第17章 scrummaster检查列表
第18章 结语
有关henrik kniberg

之后我们改变了方式。首先承认自己已经陷入了手工回归测试的泥潭，然后再来问自己：“怎么让手工回归测试消耗的时间更少呢？”当时开发的是一个赌博系统，我们意识到：测试团队在非常琐碎的配置任务上花费了大量的时间。例如浏览后台并创建牌局来测试，或者等待一个安排好的牌局启动。所以我们特地创建了一些实用工具。这些快捷方式和脚本很小，而且使用方便。它们可以完成那些乱七八糟的工作，让测试人员专注于真正的测试。这些付出确实收到了成效！实际上，我们的确应该从一开始就这样做。当初太急于将测试自动化了，都忘了应该一步一步走。刚开始应该想办法提高手工测试的效率。吸取的教训：如果你深陷手工回归测试的泥潭，打算让它自动化执行，最好还是放弃吧（除非做起来特别简单）。首先还是应该想办法简化手工回归测试。然后再考虑将真正的测试变成自动化执行。
增量设计
这表示一开始就应该保持设计简单化，然后不断进行改进；而不是一开始努力保证它的正确性，然后就冻结它，不再改变。在这一点上我们做得相当好，我们用了大量的时间来做重构，改进既有设计，而几乎没用什么时间来做大量的预先设计。有时候我们当然也会出错，例如允许一个不稳定的设计“陷入”太深，以至于后来代码重构成了一个大问题。不过总体来看我们都是相当满意的。持续的设计改进，这在很大程度上是TDD自动带来的成果。持续集成我们的大多数产品在持续集成方面都已经很成熟了，它们是基于Maven和Quick Build的。这样做很管用，而且节省了我们大量时间。对于“哎，它在我的电脑上没有问题”这样的老问题，持续集成也是终极解决方案。要判断所有代码库的健康状况，可以用持续构建服务器充当“法官”或是参考点。每次有人向版本控制系统中check in东西，持续构建服务器就会醒来，在一个共享服务器上从头构建一切，运行所有测试。如果出现问题，它就会向整个团队发送邮件告知大家构建失败，在邮件中会包括有哪些代码的变化导致构建失败的精确细节，指向测试报告的链接等。每天晚上，持续构建服务器都会从头构建产品，并且向我们的内部文档门户上发布二进制文件（ears，wars等）、文档、测试报告、测试覆盖率报告和依赖性分析报告等等。有些产品也会被自动部署到测试环境中。把这一切搭建起来需要大量工作，但付出的每一分钟都物有所值。代码集体所有权我们鼓励代码集体所有权，但并不是所有团队都采取了这种方式。我们发现：在结对编程中频繁交换结对，会自动把代码集体所有权提到一个很高的级别。我们已经证实，如果团队拥有高度的代码集体所有权，这个团队就会非常健壮，比如某些关键人物生病了，当前的sprint也不会因此嗝屁着凉。
……