《硝烟中的Scrum和XP》是作者Henrik Kniberg讲述了一个团队实施Scrum开发的过程，针对Scrum实施的每个过程进行详细的阐述。首先提到了如何编写Backlog，介绍了Backlog应该包含的一些信息，如ID、名称、重要性、初始估算、如何演示及备注等，根据具体的业务可包含其他方面的信息，接下来的几节主要是围绕Sprint planning meeting展开的。
Scrum与传统的软件开发相比，它更强调会议。会议有计划会议、每日会议 和 回顾会议。在计划会议中，它强调产品经理与Scrum Master以及团队共同参与会议，然后确定每个Sprint周期内要完成的故事，并将每个故事拆分成更小的故事，最后把故事拆分成任务，并估算每个任务的完成时间。
确定完计划之后，接下来整个团队每天都会进行短时间的每日会议，来确定前一天完成了哪些事情，以及接下来的一天要做哪些事情。每日会议中可能会发生各种各样的情况，包括会议时间多长、会议没有结果等，作者详述了他们是如何处理这些事情的。这对于我们在实际项目中是非常宝贵的经验。在此次培训前由于各种原因没有将回顾会议放到日程中。今后会在实际的项目中将回顾会议放到日程中，让项目借鉴以往的成功经验，并吸取教训，可以让团队少走很多弯路。
Scrum是偏向于管理和组织实践的，但是软件项目离不开编程，所以项目要取得很大的成功还需要注重编程实践，XP则恰恰弥补了这一点。将Scrum与XP整合起来使用，管理与编程想结合，最终项目可以获得更大的成功。
下面是重点章节的笔记：
第2章 怎样编写产品backlog
产品backlog是Scrum的核心，是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。故事包括这样一些字段：名称（简短的、描述性的故事名）、重要性、初始估算（完成所需的工作量）、如何演示、注解（想关的解释说明、资料的引用）其他额外字段：Components（组件）——例如“数据库，服务器，客户端”。Requestor（请求者）——产品负责人可能需要记录是哪个客户或相关干系人最先提出了这项需求，在后续开发过程中向他提供反馈。Bug tracking ID（Bug跟踪ID）——比如bug跟踪系统(jira)
第3章 怎样准备sprint计划
在sprint计划会议之前，要确保产品backlog的井然有序：
产品backlog必须存在。
一个人产品只能有一个产品backlog和一个产品负责人。
所有重要的backlog条目都已经根据重要性被评过分。（评分是产品负责人独有的权利）
产品负责人应该理解每个故事的含义，要知道为什么这个故事会在这里
第4章 我们怎样制定sprint计划
Sprint计划会议非常关键，应该算是Scrum中最重要的活动。举办Sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰的工作，也是为了让产品负责人能对此有充分的信心。Sprint会议会产生一些实实在在的成功：
sprint目标。
团队成员名单，以及他们的投入程度。
sprint backlog，即sprint中的故事列表。
确定好sprint演示日期。
确定好每日scrum例会的时间和地点。
每个故事都含有三个变量，范围（scope）和重要性（importance）由产品负责人设置。估算（estimate）由团队设置。在sprint计划会议上，这三个变量会逐步得到调整优化。
Scrum中的一切事情都有时间盒。在sprint计划会议之前初步制定一个时间表，可以减少打破时间盒的风险。
产品负责人对sprint目标进行总体介绍，概括产品backlog。团队估算时间，在必要的情况下拆分backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的backlog条目都要填写“如何演示”。团队选择要放入sprint中的故事。计算生产率，用作核查工作安排的基础。
决定哪些故事需要在这个sprint中完成
产品负责人和团队需要对“完成”有一致的定义。
团队成员必须要对故事内容有一定的理解才能进行估算。要求每个人都做估算，我们就可以确保他们都理解了每个条目的内容。这样就为大家在sprint中相互帮助夯实了基础，也有助于故事中的重要问题被尽早发现。
如果要求每个人都对故事做估算，我们就会常常发现两个人对同一个故事的估算结果差异很大。我们应该尽早发现这些问题并就此进行讨论。
把故事拆分成任务。故事是可以交付的东西，是产品负责人所关心的。把技术故事变成可以衡量业务价值的普通故事。有助于产品负责人作出正确的权衡。
把产品backlog放到Jira上。把bug与其他故事同等看待。
一个可供参考的Sprint计划会议日程：
SPRINT 计划会议：13：00 - 17:00（每小时休息10分钟）
13:00-13:30：产品负责人对sprint目标进行总体介绍，概况产品backlog，定下演示时间。
13:30-15:00：团队估算时间，在必要的情况下拆分backlog条目。产品负责人在必要时修重要性评级，所有重要性高的条目都要写清示how to demo“如何演示”。
15:00-16:00：团队选择放入sprint中的故事。计算生成率，用作核查工作安排的基础。
16:00-17:00：为每日scrum会议安排固定的时间和地点，把故事进一步分解为任务。
第7章 我们怎样布置团队房间
让团队坐在一起。“一起”意味着：
互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。
互相看到：所有人都可以看到彼此，都能看到任务板——不用非得近到可以看清楚内容，但至少可以看到个大概。
隔离：如果你们整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会被打扰到。反之亦然。
第9章 我们怎样进行sprint演示
坚持所有的sprint都结束于演示。团队的成果得到认可。他们会感觉很好。其他人可以了解你的团队在做些什么。演示可以吸引相关干系人的注意，并得到重要反馈。团队间可以相互交流，讨论各自的工作。
Sprint演示检查列表。
确保清晰阐述了sprint目标。如果在演示上有些人对产品一无所知，那就花上几分钟来进行描述。
让演示关注于业务层次，注意力放在“我们做了什么”，而不是“我们怎么做的”。
可能的话，让观众自己试一下产品。
第10章 我们怎样做sprint回顾
回顾是Scrum中第二重要的事情（最重要的是sprint计划会议），因为这是做改进的最佳时机。
我们如何组织回顾。
根据要讨论的内容范围，设定时间为1至3个小时。
参与者：产品负责人，整个团队还有我自己。
我们换到一个封闭的房间中，或者舒适的沙发角，或者屋顶平台等等类似的场所。只要能够在不受干扰的情况下讨论就好。
指定某人当秘书。
Scrum master向大家展示sprint backlog，在团队的帮助下对sprint做总结。包括重要事件和决策等。
轮流发言。每个人都有机会在不被人打断的情况下进出自己的想法，他认为什么是好的，哪些可以做的更好，哪些需要在下个sprint中改变。
Scrum master对具体建议进行总结，得出下个sprint需要改进的地方。
我们怎样才能在下个sprint中做的更好。
Good：如果我们可以重做同一个sprint，哪些做法可以保持。
Could have done better：如果我们可以重做同一个sprint，哪些做法需要改变。
Improvements：有关将来如何改进的具体想法。投票决定下个sprint所要采取措施的优先级。
Scrum回顾会议，如果过于沉寂，他应该问一些简单而目标明确的问题，以刺激团队展开讨论。例如“如果时间可以倒流，从第一天重新开始这个sprint，那你觉得哪些事情会用其他方式来做？
第12章 怎样制定发布计划
定义你的验收标准。
产品负责人还会定义一系列的验收标准，它从合同的角度将产品backlog中重要性级别的含义进行了简单分类。下面是验收标准规则的一个例子：
所有重要性>=100的条目都必须在1.0版本中发布，不然我们就会被罚款到死翘翘。
所有重要性在50-99之间的条目应该在1.0中发布，不过也许我们可以在紧接着的一个快速发布版中完成这些。
重要性在25-49之间的条目也都是需要的，不过可以在1.1版本中发布。
重要性<25的条目都是不确定的，也许永远不会用到。
对最重要的条目进行时间估算。P78
对制定发布计划，产品负责人需要进行时间估算，至少是要估算在合同中包含的故事。跟sprint计划会议一样，这是产品负责人和团队协作共同完成的——团队进行估算，产品负责人描述条目内容，回答问题。如果时间估算最后被证明接近正确结果，那它就是有价值的；如果结果有所偏离，例如偏差30%，价值则有所降低了；如果它跟实际结果一点关系都没有，那就完全没用了。
第13章：怎么结合使用scrum和xp
结对编程：一旦尝试之后会迅速的喜欢上它。
测试驱动开发TDD：对我来说，它比scrum和xp还要重要！TDD意味着你要先写一个自动测试，然后编写恰好够用的代码，让他通过这个测试，接着对代码进行重构，主要是提高他的可读性和消除重复。他会把开发-构建-测试这三者构成的循环变得奇快无比，同时还可以充当一个安全网，让开发人员有足够的信息频繁重构，伴随着系统的增长，设计依然可以保持整洁和简单。
增量设计：一开始就应该保持设计简单化，然后不断的进行改进，而不是一开始女里保证它的正确性，然后冻结它，不再改变。持续的设计改进，再很大程度上得益于TDD。
持续集成：是解决“可是，它在我的电脑上一切正常……”这一问题的终极武器！
代码集体所有权：结对编程会自然提高代码所有权，这样团队就会变得健壮，不会因为个别关键人物的缺席而影响整个团队。
充满信息的工作空间：所有团队都可以有效的利用白板和空的墙壁空间，贴满各种关于产品和项目的信息。
第14章 我们怎样做测试
在理想化的Scrum世界中，每个sprint最终会产生一个可部署的系统版本。尽可能缩短验收测试的时间。说得更明白一些，把需要花在验收测试阶段上的时间减到最少。我们的做法是：
全力提高Scrum团队交付的代码质量。
全力提高人工测试的效率。
把测试人员放到Scrum团队中。
每个sprint少做点工作
17章 Scrum master检查列表
sprint开始阶段：
sprint会议之后，创建sprint信息页，在wiki上创建从dashboard指向创建页面的连接；把页面打印出来，贴在通过你们团队工作区域之外的墙上，让经过的人都可以看到。
给每个人发邮件，声明sprint已启动。邮件中要包含sprint目标和指向sprint信息页的连接。
更新sprint数据文档。加入估算生产率、团队大小和sprint长度等等。
每一天：
确保每日scrum会议可以按时开始和结束。
为了保证sprint可以如期完成，需要适当的增删故事。确保产品负责人了解这些变化。
确保团队可以及时得知sprint backlog和燃尽图的最新状态。
确保存在的问题和障碍都能被解决，并报告给产品负责人以及开发主管。
sprint结束时：
进行开放式的sprint演示。
在演示开始前一两天，就要通知到每个人。
与整个团队以及产品负责人一起开sprint回顾会议。
更新sprint数据文档，加入实际生产率和回顾会议中总结出的关键点
网友评论