《硝烟中的Scrum和XP》读书笔记

迭代开发的基本需求：

• 迭代要有固定时长（被称为“时间盒-timebox”），不能超过六个星期。
• 在每一次迭代的结尾，代码都必须经过QA的测试，能够正常工作。

Nokia的Scrum标准：

• Scrum 团队必须要有产品负责人，而且团队都清楚这个人是谁。
• 产品负责人必须要有产品Backlog，其中包括团队对它进行的估算。
• 团队必须要有燃尽图，而且要了解他们自己的生产率。
• 在一个Sprint中，外人不能干涉团队的工作。

Agile.png

我们怎么编写产品backlog

故事（story）

• ID —— 统一标识符
• Name —— 简短的、描述性的故事名。必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。一般由2到10个字组成。
• Importance —— 产品负责人评出一个数值，指示这个故事有多重要。
• Initial estimate —— 团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小单位是故事点（story point），一般大致相当于一个“理想的人天（man-day）”
• How to demo —— 大略描述了这个故事应该如何在sprint演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到......的结果”。
• Notes —— 相关信息、解释说明和对其它资料的引用等等。

backlog.png

额外的故事字段

• Track（类别）—— 当前故事的大致分类，例如“后台系统”或“优化”
• Components（组件）——通常在Excel文档中用“复选框”实现，例如“数据库，服务器，客户端”
• Requestor（请求者）—— 产品负责人可能需要记录是哪个客户或相关干系人最先提出了这项需求，在后续开发过程中向他提供反馈。
• Bug tracking ID

我们怎么样准备sprint计划

在sprint计划会议之前，要确保产品backlog的井然有序。

• 产品backlog必须存在。
• 只能有一个产品backlog和一个产品负责人（对于一个产品而言）。
• 所有重要的backlog 条目都已经根据重要性被评过分，不同的重要程度对应不同的分数。
• 产品负责人应当理解每个故事的含义（通常故事都是有他来编写的，但是有的时候其他人也会添加一些请求，产品负责人对它们划分先后次序）。他不需要知道每个故事具体是如何实现的，但是他要知道为什么这个故事会在这里。

注意：产品负责人之外的人也可以向产品backlog中添加故事，但是他们不能说这个故事有多重要，这是产品负责人独有的权力。他们也不能添加实际估算，这是开发团队独有的权力。

我们怎样制定sprint计划

Sprint计划会议产生的成果：

• sprint目标
• 团队成员名单（以及他们的投入程度，如果不是100%的话）
• sprint backlog（sprint中包括的故事列表）
• 确定好sprint演示日期
• 确定好时间地点，供举行每日scrum会议

为什么整个团队和产品负责人都必须要参加sprint计划会议？
原因在于，每个故事都含有三个变量，它们两两之间都对彼此有着强烈依赖

image.png

scope和importance由产品负责人设置，estimate由团队设置。

如果产品负责人坚持没时间参加怎么办？

• 试着让产品负责人理解，为什么他的直接参与事关项目成败。
• 试着在团队中找到某个人代表产品负责人，产品负责人在会议开始前要跟代表沟通到位。代表会在会议中行使改变故事的优先级和范围。
• 试着说服管理团队为我们分配新的产品负责人
• 推迟sprint启动日期。

为什么不能在质量上让步

• 外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面等
• 内部质量一般指用户看不到的要素，它们对系统的可维护性由深远影响。可维护性包括系统设置的一致性、测试覆盖率、代码可读性和重构等

决定sprint要包含的故事

sprint1.png

每个矩形都表示一个故事，按重要性排序。最重要的故事在列表顶部。矩形尺寸表示故事大小（故事点估算的时间长短）。蓝括号的高度表示团队的估算生产率，也就是团队认为他们在下一个sprint中所能完成的故事点数。

右侧的sprint backlog是产品backlog中的一个故事快照。它表示团队在这个sprint中承诺要完成的故事。

在sprint中包含多少故事由团队决定，而不是产品负责人或其他人。

由两个问题：

• 团队怎么决定把哪些故事放在sprint里面？
• 产品负责人怎么影响他们的决定？

产品负责人如何对sprint放哪些故事产生影响？

假设在sprint计划会议中遇到下面的情况：

image.png

产品负责人希望故事D放在sprint里面：

• Option 1：重新设置优先级

  
  
  

  image.png

• Option 2：更改范围，缩小故事A的范围，直到团队相信故事D能在这个sprint里完成为止。

image.png

• Option 3：拆分故事。产品负责人判定出故事A中某些实际并不重要，把A分成两个故事A1和A2，给它们不同的重要级别。

image.png

虽然产品负责人在正常情况下不能控制团队的估算生产率，依然由很多种方式，对sprint中放入哪些故事施加影响。

团队怎样决定把哪些故事放在sprint里面？

• 本能反应
• 生产率计算

用生产率计算来估算

• 得出估算生产率
• 计算在不超出估算生产率的情况下可以加入多少故事。

[图片上传中...(image.png-65320a-1512312356281-0)]

左边是sprint启动时的估算生产率，右边是sprint结束时的实际生产率。

Scrum的要求（也是敏捷开发和精益求精制造的要求）：把事情完全做完，达到可以交付的状态，事情只做了一半，它的价值就是0。

This Sprint's Estimated Velocity:

(Available Man-days) X (Focus Factor) = (Estimated Velocity)

Last Sprint's Focus Factor:

(Focus Factor) = (Actual Velocity) / (Available Man-days)

假设在上个sprint里面，由Tom，Lisa和Sam组成的三人团队在3个星期内工作了45Man-day，完成了18个故事点。以及Dave后期加入：

image.png

则下个sprint的估算生产率是20个故事点，团队下个sprint中所能做的故事点数之和不能超过20.

image.png

想要收到好的效果，不妨创建一些索引卡

image.png

使用计划纸牌做时间估算

image.png

每个人都会得到如上图所示的 13 张卡片。在估算故事的时候，每 个人都选出一张卡片来表示他的时间估算（以故事点的方式表示）， 并把它正面朝下扣在桌上。所有人都完成以后，桌上的纸牌会被同 时揭开。这样每个人都会被迫进行自我思考，而不是依赖于其他人 估算的结果。

如果在两个估算之间有着巨大差异，团队就会就此进行讨论，并试 图让大家对故事内容达成共识。他们也许会进行任务分解，之后再 重新估算。这样的循环会往复进行，直到时间估算趋于一致为止， 也就是每个人对这个故事的估算都差不多相同。

把故事拆分成任务

故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它也不关心。

故事拆分成更小的故事：

image.png

故事拆分成任务：

image.png

• 新组建的 Scrum 团队不愿意花时间来预先把故事拆分成任 务。有些人觉得这像是瀑布式的做法。
• 有些故事，大家都理解得很清楚，那么预先拆分还是随后 拆分都一样简单。
• 这种类型的拆分常常可以发现一些会导致时间估算增加的 工作，后得出的 sprint 计划会更贴近现实。
• 这种预先拆分可以给每日例会的效率带来显著提高（参见 “我们怎样进行每日例会”）。
• 即使拆分不够精确，而且一旦开始具体工作，事先的拆分 结果也许会发生变化，但我们依然可以得到以上种种好处。

如果时间不够，用下面的优先级列表：

• 优先级 1：sprint 目标和演示日期。
• 优先级 2：经过团队认可、要添加到这个 sprint 中的故事列表。
• 优先级 3：Sprint 中每个故事的估算值。
• 优先级 4：Sprint 中每个故事的“如何演示”。
• 优先级 5：生产率和资源计算，用作 sprint 计划的现实核查。包括 团队成员的名单及每个人的承诺（不然就没法计算生产率）。
• 优先级 6：明确每日例会固定举行的时间地点。
• 优先级 7：把故事拆分成任务。

怎样让别人了解我们的sprint

我们为此使用“sprint信息页”：

image.png

Sprint 计划会议一结束，Scrum master 就创建这个页面，把它放到 wiki 上，给整个公司发一个“垃圾”邮件。

image.png

Sprint 接近尾声时，Scrum master 会把即将来临的演示告知每个人。

image.png

我们怎样编写sprint backlog

image.png

几天以后，任务板可能会变成这样：

image.png

燃尽图如何发挥作用

image.png

• Sprint 的第一天，8 月 1 号，团队估算出剩下 70 个故事点 要完成。这实际上就是整个 sprint 的估算生产率。 �
• 在 8 月 16 号，团队估算出还剩下 15 个故事点的任务要做。 跟表示趋势的虚线相对比，团队的工作状态还是差不多沿 着正轨的。按照这个速度，他们能在 sprint 结束时完成所有任务。

任务版警示标记

image.png

image.png

image.png

image.png

怎样布置团队房间

设计角

image.png

我们怎样进行每日例会

更新任务板

image.png

我们怎样进行sprint演示

为什么我们坚持所有的sprint都结束于演示

• 团队成果得到认可
• 其他人可以了解你的团队在做些什么
• 演示可以吸引相关干系人的注意，并得到重要反馈
• 演示时一种社会活动，不同的团队可以在这里相互交流，讨论各自的工作。
• 做演示会迫使团队真正完成一些工作，进行发布。有了演示以后，也许我们完成的事情会变少，但它们是真正完成的。

Sprint 演示检查列表

• 确保清晰阐述了sprint目标。
• 不要花太多时间准备，不要做花里花哨的演讲。
• 节奏要快，把准备的精力放在保持演示的快节奏上。
• 可能的话，让观众自己试一下产品。
• 不要演示一大堆细碎的bug修复和微不足道的特性。

怎样做sprint回顾

我们如何组织回顾

• 根据要讨论的内容范围，设定时间为1至3小时。
• 参与者：产品负责人，整个团队
• 在不受干扰的情况下讨论
• 指定某人当秘书
• Scrum master 向大家展示sprint backlog，在团队的帮助下对sprint做总结。包括重要事件和决策等。
• 我们会轮流发言。每个人都有机会在不被人打断的情况下讲出自己的想法，他认为什么是好的，哪些可以做的更好，哪些需要在下个sprint中改变。
• 我们对预估生产率和实际生产率进行比较。
• 快结束的时候，Scrum master对具体建议进行总结，得出下个sprint需要改进的地方。

image.png

• Good：如果我们可以重做同一个sprint，哪些做法可以保持。
• Could have done better：哪些做法需要改变。
• Improvements：有关将来如何改进的具体想法。

Sprints之间的休整时刻

image.png

更好：

image.png

最好？（LAB DAY）

image.png

怎样制定发布计划，处理固定价格的合同

怎样组合使用Scrum和XP

结对编程

• 结对编程可以提高代码质量。
• 结对编程可以让团队的精力更加集中。
• 很多强烈抵制结对编程的开发人员根本没有尝试过，而一旦尝试之后就会迅速喜欢上它。
• 结对编程令人精疲力竭，不能全天都这样做。
• 常常更换结对是有好处的。
• 有些人不习惯结对编程，不要因为一个优秀的开发人员不习惯结对编程就把他置之不理
• 可以把代码审查作为结对编程的替代方案。
• “领航员”应该自己也有一台机器。不是用来开发，而是在需要的时候稍微做一些探索尝试、当“司机”遇到难题的时候查看文档等。
• 不要强制大家使用结对编程。鼓励他们，提供合适的工具，让他们按照自己的节奏去尝试。

测试驱动开发（TDD）

测试驱动开发意味着你要先写一个自动测试，然后编写恰到够用的代码，让它通过这个测试，接着对代码进行重构，主要是提高它的可读性和消除重复。整理一下，然后继续。

• TDD 很难，开发人员需要花上一点时间才能掌握，一旦掌握后，就会彻底的影响，从此再也不想使用其他方式工作。
• TDD对系统设计的正面影响特别大。
• 回报来得非常快。
• 投入足够的时间，来保证大家可以很容易地编写测试。

怎样做测试

在每个sprint中少做工作来提高质量

怎样管理多个Scrum团队

创建多少个团队

宁可团队数量少，人数多，也比弄上一大堆总在互相干扰的小团队强。要想拆分小团队，必须确保他们彼此之间不会产生互相干扰。

怎样管理地理位置上分布的团队

• 能够一起结对编程
• 能够在每日例会上面对面交流
• 在任何时候都能够面对面讨论
• 可以真正地碰面与交往
• 整个团队可以主动举行会议
• 团队对sprint backlog、sprint燃尽图、产品backlog和其他信息传递设施有相同的理解。

在家工作的团队成员

Scrum master检查列表

sprint结束时

• 进行开放式的Sprint演示
• 在演示开始前一两天，要通知到每个人。
• 与整个团队以及产品负责人一起开Sprint回顾会议。
• 更新sprint数据文档。加入实际生产率和回顾会议中总结出的关键点。