《Scrum指南》及《Scrum要素》读书笔记

迭代式开发怎么做？

• 边做边测试
• 及早且频繁地交付产晶
• 文档边做边写，只写必需的文档
• 打破筒仓（silo) 构建跨职能团队

敏捷方式的核心思想在于迅速交付商业价值，体现为可工作的软件，还要以定期增量的形式持续地交付价值。

敏捷价值观

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客服合作 高于 合同谈判

响应变化 高于 遵循计划

注意这些价值观的表述方式，它说，某一个因素“高于”另一个，而非“取代”另一个。

敏捷力的基本宗旨之一就是，干活的人最清楚该如何完成工作。

好的实践方式是在试验和犯错的过程中达成决议，例如选定使用的工具，也吻合了检验和适应的。工具和流程可是很棒很有用的东西，但必须要放对地方，要让使用者来掌控它们。流程和工具必须是为人服务的，而不是反过来。

人们普遍误以为敏捷团队是不写文档不做计划的，但实际上，敏捷团队为规划和文档工作所花费的时间、精力远多于传统团队，因为计划需要不断地进行细化和更新。敏捷软件项目中的计划以各种形式出现在我们身边，例如用户故事、列表（backlog）、接收测试和大型可视图表，它们组成了富沟通环境。

敏捷原则

很多团队都认为长周期 sprint 是走入“敏捷”的最佳起步方式，真实情况恰恰相反。短周期强迫你专注于重点，还要废除那些消耗生产力的瀑布时代积习。

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。面对面交谈时可以通过身体语言增强表达，因而效果也最好。

有些敏捷方法支持者误解了这条原则，以为分布式团队就不能“敏捷”了。可是，要注意到这条原则只不过是说面对面是最好的而已。远程方式也可以实践敏捷团队协作，只是你得格外留意如何建立沟通流。

面对面沟通最有价值的地方可以说就在于互相认识的阶段。根据我们的经验来看，团队一旦团结起来后，远程沟通也是能顺畅进行的。

历史已经证明，超负荷工作的人在任何领域都只能收获低效益。加大投入到一定程度后，人类的认知功能就会下降，而后我们开始犯错，在软件行业这就意味着会产生更多缺陷。

定期地检验和适应，增强有效方法，并改进无效方法，这是任何敏捷流程都有的主要成分，有些人也认为这是最重要的部分。

敏捷回顾远比它给人的第一印象强大得多。一些新接触敏捷流程的团队认为，回顾会议可以不用开，还能节省些时间。别！事实上，我们甚至斗胆建议，你向敏捷力迈出的第一步就应该在工作流中囊括回顾会议。展现定期检验和改进工作方式所产生的巨大效益，并以此方式证明迭代开发的价值，已经是最快了。

Scrum历史简述

“Scrum 是一个基于团队进行复杂系统，和产品开发的框架。”

​ ——Scrum联盟

“据其定义， Scrum 事实上并未谈及软件．Scrum 所涉乃是非软件项目亦可使用的工作管理和团队动力学。”

​ ——Jeff McKenna

Sutherland 和公司开始着手设计软件开发模型，模型能让团队紧密结合，表现起来就像一个人，希望借此可以创建出跟天才的超级程序员一样强大的团队！他们称之为 scrum。

Schwaber 觉得，新方法成功的秘诀在于，他使用了经验式流程（检验和适应），而不是预定义流程（计划和执行）。

Scrum角色

scrum 只承认三个互不相同的角色，产品负责人、 scrum master 和团队成员。

1. 产品负责人

产品负责人的责任在于，帮公司得到最高投资回报。做法是指引团队做最有价值的作业，并远离不那么有价值的作业。也就是说，产品负责人控制着团队列表上那些条目的优先级顺序。

产品负责人要做不编码的团队成员，这很重要。换言之，让一个开发大忙人来兼任团队的产品负责人，这招一般都不好使。合并产品负责人和 scrum master 角色，加倍地不好使。

2. Scrum Master

Scrum master 担当教练角色，引领团队达到更高级的凝聚力、自组织和表现。团队的交付物是产品，而 scrum master 的交付物就是自组织的团队。

Scrum master 能发挥用处的地方很多，包括引导 scrum 会议、帮助团队理解和使用 scrum 的工件、指引产品负责人和其他团队成员更好地理解自己在 scrum 团队中所担当的角色。

事实上，称职的 scrum master会不断地调整自己的风格去适应团队的需要。 scrum 团队新建立时， scrum master 可能得多教育多指引。随着团队技能的提升和对 scrum 理解的增进， scrum master 也在调整方式，转而扮演回音板和应需谏言者的角色，但并不代做决定，而是推回给团队自行决策。

Scrum master 还有另一个关键的作用，为团队移除障碍。

3. 团队成员

Scrum 团队是高度协作的，也是自组织的。团队成员可以全权决定如何完成工作。团队可以自行决定要使用的工具和技术，以及团队成员如何瓜分任务。决定最佳工作方法这件事的原理就是，干活的人权力最大。

一个 scrum 团队应该有多少队员呢？经验法则通常是七个人，再或多或少两个人，也就是说，五个到九个人。如果团队人数更少，可能会欠缺足够的技能多样化，难以全部完成用户故事所需工作。如果团队人数更多，沟通开销会开始过度地增长。

团队成员角色并不要求平等性、同一性，或是任何其他模糊的共产主义情调，它耍的就是最大化团队生产力。 Scrum 并不追求做到团队所有成员都可互换，只要他们在团队需要的时候，愿意选择舒适区之外的工作即可。

Sprint周期

Scrum 并未特别指定团队的 sprint 时长，但通常都认为上限是四周。两周的 sprint 好像是最流行的，一周和三周的周期也很普遍。

他发现，一个典型团队要掌握敏捷流程的精髓需要大约六个 sprint，至于使用一天的还是四周的 sprint 则无关紧要。我们的经验也很相似，所以 Chris 往往会推荐团队从一周的 sprint开始，因为这样有助于大家快速地学习并适应 scrum。

Sprint规划会议

Sprint 规划会议标志着 sprint 的开始。通常来说，这个会议分为两个部分。第一部分的目标是，团队要选择一组交付物作为当前 sprint的承诺。会议的第二部分中，团队要罗列出交付用户故事所需完成的所有任务。

Scrum日会

参会者轮流快速地分享：

在上一次 scrum 日会之后，我已经完成的内容。

到下一次 scrum 日会之前，我期望完成的内容．

导致我慢下来的障碍。

回顾

一些 scrum 新人有参加过传统“事后分析”或“经验总结”会议的经验。它们都是项目结束时才召开，收获的往往是一份罗列“好处”和“改变” 的冗长清单，会议刚结束就差不多全忘了，大家还嘟哝着抱怨“亡马锁厩，悔之晚矣”。

这种吐槽式抱怨的问题在于没有可行性。团队只要能找到单个改进点，并立刻采取行动，他们就能感觉更舒服些。有效地利用回顾持续改进工作方式的团队，会有种强烈的责任意识（a strong sense of empowerment）。

你可以用索引卡或便事贴在墙上做出一条 sprint 时间线，团队成员们努力地回想过去发生的事件并填充到时间线上。这样能帮助团队记起整个 sprint，而不只是最近那几天或那些不愉快的事！

我们发现，最好的办法是只选定一个地方做改进。关键在于让团队可以稳步地前进，克制住心中想要一并解决所有问题的倾向，不会被随之而来的压力所击倒。重申一遍，团队若能每个 sprint 搞定一个新领域，感觉会很棒。想解决五个问题却有四个无法付诸行动，只会让团队感到灰心丧气。

Sprint的异常终结

异常地终结掉 sprint 之后，召开回顾会议就显得尤为重要，正由于 sprint 的异常终结不同寻常，因而也就可以从中学习到很多东西。

检验和适应

归根结底我们以短周期形式做开发工作的原因何在呢？是为了学习。经验是最好的老师，而 scrum周期的设计就是要为你提供多方位接收反馈的机会，包括客户、团队和市场，并从中学习。

Scrum 日会标示着第一个循环，为的是 sprint 的利益。团队检验和适应他们每天的工作，稳住方向，朝着交付 sprint 所有故事的目标前进。

Sprint 展示会议是第二个循环圈的结束，为的是产品的利益。干系人可以看到产品的当前状态，并给出反馈。

回顾会议是第三个反馈循环的闭合，为的是团队的利益。他们从这些经验中洞悉见识，通过检验和适应调整他们的工作方式。

信息辐射器

张贴图表要挑地方，要在视野范围内，而且每天都全天候可见，让它深深地印入脑海以保持整个团队都有共同的认识（on the same page）。

完成之定义（Definition of Done）

所有团队都应该在项目刚开始的时候，花点时间协作得出公共的完成之定义，然后用那种写字很粗的笔把它写下来，作为信息辐射器放在团队公共空间的显眼处。

值得一提的是，完成之定义和验收标准是有区别的。验收标准属于产品负责人与或客户的领域，明确定义了被视为“可接受”产品所必须满足的条件并记录在案。像是回归测试和版本集成这些内容，则不属于验收标准的范畴。

完成之定义归开发团队所有，关注的不是产品面向用户的功能，而是产品要可交付必须要做完的那些“下面的（under the hood）”任务。

写得马马虎虎或不完整的完成之定义存在着风险，会攒出一个看不见的技术债务池。

用户故事

用户故事不是完整的需求或说明书，它们是占位符。它们的信息量足以提醒团队有东西要完成，但我们刻意地不过多探讨细节……直到必需之时。

需要阐述用户故事细节时，我们喜欢使用召集相关团队成员参与交谈的形式。交谈的目标在于，对故事内容以及所需完成的工作达成共识。

相对于依赖书面文档，使用实时对话的方式能更高效地达成此目标。它有更多的信息流动，你可能还会喜欢它更丰富的交流媒介。

估值

我们要估值究竟想干嘛？毕竟得花时间才能生成估值。直接开工干活岂不是能完成更多些？

生成估值的真正目标是要提供进度的可预测性度量。如果可预测性具有实际的业务价值，那就值得花功夫争取。

当然，我们刻意地严格使用这一组数字，并不是说某个给定的故事正好值 21 个点。我们说的是，相比 13 和 34，它更接近 21 。这已足够准确，能给我们有效的进度可预测性。你可以回忆一下，有效的进度可预测性就是我们一直以来所追求的东西。它正是我们不厌其烦地做估算的原因。

电梯演讲

你有一个值得公司为此发起项目的绝妙想法，而且你凑巧和公司CEO 搭乘同一部电梯。你正好可以借机说服他支持你的项目。

你的电梯演讲应该只有简短几句话。关注项目要解决的问题，以及公司或客户将由此获得的好处。你得言简意骸以便让人记住不忘，你的昕众要能在一小时后就向同事重复其要点。

重构

架构就像文胸，必须要合身才有支撑和提升的功效。开始编码后，往往会觉得 BDUF 方式创建的架构建设过度且笨重。晚些时候，系统开始其方向不可预料的有机生长时，架构会让人感到不安和拘谨。就像女人在生活中也需要不同的文胸一样，系统在成长过程中也需要有不同的架构。

结对编程

对几乎所有软件项目来说，改变代码所用时间都超过了用于创建代码的时间。减少缺陷、增强可维护性以及分享代码相关知识，都能实现更快速的开发。