《硝烟中的Scrum和XP》——Henrik Kniberg

[thzt]

你们是否清楚团队的生产率？
要想在将来得到投资，开发团队就必须清楚自己的软件生产率。
如果团队不清楚自己的生产率，那么产品负责人就无法用可靠的发布日期来创建产品路线图。
如果没有可靠的发布日期，公司的产品就可能会失败，投资人的钱就有可能化为乌有。

Scrum和XP都要求团队在每一次迭代的结尾完成一些可以交付的工作片段。
迭代要短，有时间限制，将注意力集中于在短时间内交付可工作的代码，这就意味着Scrum和XP团队没有时间进行理论研究。
他们不会花时间用建模来画UML图，编写完美的需求文档，也不会为了应对在可预计的未来中所有可能发生的变化而去写代码。
实际上，Scrum和XP都关注如何把事情做好。
这些团队承认在开发过程中会犯错，但是他们明白，要投入实践中，动手去构建产品，这才是找出错误的最好方式。
不要只是停留在理论层次上对软件进行分析和设计。

Scrum的强大和令人痛苦之处，就在于你不得不根据自己的具体情况来对它进行调整。

产品backlog是Scrum的核心，也是一切的起源。
从根本上说，它就是一个需求，或故事，或特性等组成的列表，按照重要性的级别进行了排序。
它里面包含的是客户想要的东西，并用客户的术语加以描述。
我们叫它故事（story），有时候也叫作backlog条目。
我们的故事包括这样一些字段：ID，名称，重要性，初始估算，如何演示，注解

在sprint计划会议之前，要确保产品backlog井然有序。
产品backlog必须存在。
只能有一个产品backlog和一个产品负责人。
所有重要的backlog条目都已经根据重要性被评分，分数只是比较级，不表示量级。
产品负责人要知道为什么这个故事会在这里。

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

举办sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰的工作，
也是为了让产品负责人能对此有充分的信心。
sprint会议会产出一些实实在在的成果：
sprint目标，团队成员名单，sprint backlog，确定好sprint演示日期，确定好时间地点举行每日scrum会议。

为什么产品负责人必须参加sprint计划会议？
原因在于，每个故事都含有三个变量，范围，重要性，估算，
它们两两之间有强烈的依赖，范围和重要性由产品负责人设置，估算由团队设置。
在sprint计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。

不能在质量上让步。
质量可以分为内部质量和外部质量，
外部质量是系统用户可以感知的，运行缓慢，让人迷糊的用户界面就属于外部质量低劣。
内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。
可维护性包括系统设计的一致性，测试覆盖率，代码可读性和重构等等。

外部质量可看做范围的一部分。
假设产品负责人这样说：
好吧，你们把它估算成6个故事点也行。
但我相信，一定能够找到临时方案，节省一半时间。
你们只要稍稍动下脑子就行。

他想把内部质量当做变量来处理，因为他想让我们缩减故事的估算时间，但不想为缩减范围买单。
临时方案，这个词应当在你的脑中敲响警钟。

经验告诉我，牺牲内部质量是一个糟糕透顶的想法。
现在节省下来的一点时间，接下来的日子里你就要一直为它付出代价。
一旦我们放松要求，允许代码库中暗藏问题，后面就很难恢复质量了。

碰到这种状况，我就会试着把话题转回到范围上来，
既然你想尽早得到这个特性，那我们能不能把范围缩小一点？这样实现时间就能缩短。
也许我们可以简化错误处理的功能，把“高级错误处理”当做一个单独的故事，放到以后在实现。
或者也可以降低其他故事的优先级，好让我们集中处理这一个。

一旦产品负责人弄清楚内部质量是不可能让步的，他一般都会处理好其他变量。

sprint的长度，时间短有短的好处。
公司会因此而变得敏捷，有利于随机应变。
短的sprint = 短反馈周期 = 更频繁的交付 = 更频繁的客户反馈
= 在错误方向上花的时间更少 = 学习和改进的速度更快

但是长的sprint也不错，
团队可以有更多时间充分准备，解决发生的问题，继续达成sprint目标，
也不会被接二连三的sprint计划会议，演示等等压得不堪重负。

确定了团队喜欢的sprint长度之后，就要在长时间内坚持住。
虽然有的时候回稍微感觉有点长，有的时候感觉有点短。
但保持住这个长度以后，它似乎变成了大家共同的心跳节奏，每个人都感觉很舒服。
这段时间内也无需讨论发布日期之类的事情，因为大家都知道，每过三周都会有一个发布。

确定sprint目标，要用业务术语表达，而不是技术词汇。
sprint目标需要回答这个根本问题，
我们为什么要进行这个sprint，为什么我们不直接放假算了？
要想从产品负责人的口中哄骗出sprint目标，你不妨一字不差的问他这个问题看看。

决定哪些故事需要在这个sprint中完成，是sprint计划会议的一个主要活动。
更具体的说，就是哪些故事需要从产品backlog拷贝到sprint backlog中。
sprint中包含多少故事由团队决定，而不是产品负责人或其他人。

产品负责人如何对sprint放哪些故事产生影响？
他可以重新设置优先级，可以缩小故事范围，还可以拆分故事。

生产率，是对已经完成工作总量的一个衡量方式。
在sprint结束时，要对比估算生产率和实际生产率。
在sprint里面差不多可以完成的故事并不算完成，这是Scrum的要求，
把事情完全做完，达到可以交付的状态，事情只做了一半，它的价值就是0。

我们在估算生产率的时候，
看看团队的历史，看看他们在过去几个sprint里面的生产率是多少，
然后假定在下一个sprint里面生产率差不多不变。
这项技术也被叫做昨日天气。
要想使用该技术，必须满足两个条件：
团队已经完成了几个sprint，
会以几乎完全相同的方式来进行下一个sprint。

我们的估算不应该是物理人天，而应该是理想化的人天，是故事点。
一个理想化的人天是完美，高效，不受打扰的一天，还需要考虑各种影响因素。
我们引入投入程度这个概念，投入程度用来估算团队会在sprint中投入多少精力。
投入程度低，就表示团队估计会受到很大干扰，或者他们觉得自己的时间估算太理想化了。
要想得出一个合理的投入程度，最好的办法就是看看上一个sprint的值，或者取平均值。

假设在上一个sprint，团队工作了45人天，完成了18个故事点。
现在我们要为下一个sprint估算一下生产率，如果下一个sprint一共有50个人天，
那么估算的生产率就是20个故事点。
这表明团队下一个sprint中所能做的故事点数之和不能超过20。

在新团队使用的默认投入程度通常是70%，这是大多数团队都能达到的数值。

如果让整个团队进行估算，通常那个对故事理解最透彻的人会第一个发言。
不幸的是，这会严重影响其他人的估算。
有一项很优秀的技术可以避免这一点，它的名字是计划纸牌。
0 1/2 1 2 3 5 8 13 20 40 100 ?
在估算故事的时候，每个人选出一张卡片作为时间估算，并把它正面朝下扣在桌上，
所有人都完成以后，桌上的纸牌会被同时揭开。
这样每个人都会被迫进行自我思考，而不是依赖其他人估算的结果。
如果在两个估算之间有着巨大差异，团队会就此进行讨论，并试图让大家对故事内容达成共识。

重要的是，我们必须提醒团队成员，他们要对这个故事中所包含的全部工作进行估算。
而不是他们负责的部分工作，测试人员不能只估算测试工作。

故事的大小要合适，
我们常常都力求保证故事的大小在2-8个人天之间。
一个普通团队的生产率大约是40-60，所以大概每个sprint可以完成10个故事。
有时会减少到5个，有时也会多到15个。

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

为什么我们坚持所有的sprint都结束于演示？
一次做得不错的演示，即使看上去很一般，也会带来深远影响。
团队的成果得到认可，他们会感觉很好。
其他人可以了解你的团队在做些什么。
演示可以吸引相关干系人的注意，并得到重要反馈。
演示是一种社会活动，不同的团队可以在这里相互交流，讨论各自的工作，这很有意义。
做演示会迫使团队真正完成一些工作，进行发布。
如果没有演示我们就会总是得到些99%完成的工作。
有了演示以后，也许我们完成的事情会变少，但它们是真正完成的。
这比得到一堆貌似完成的工作要好很多，而且后者还会污染下一个sprint。
团队知道这次无论如何他们也要进行演示，一些真正有用的东西被演示出来的机会就会大很多。

不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。
把那些玩意儿扔一边去，集中精力演示可以实际工作的代码。
节奏要快，也就是说要把准备的精力放在保持演示的快节奏上，而不是让它看上去好看。
让演示关注于业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”。
可能的话，让观众自己试一下产品。
不要花太多时间，不用很好看，只要能传递信息就行。

在有关回顾的种种一切中，最重要的就是确保回顾能够进行。
由于某些原因，团队常常都不太愿意做回顾。
如果不给他们点温柔的刺激，我们的大多数团队都会跳过回顾，直接进行下一个sprint。
我认为回顾是Scrum中第二重要的事件，最重要的是sprint计划会议。
因为，回顾是做改进的最佳时机。
当然，你不需要在回顾会议上得到什么好点子，在家里的浴盆里就能做到。
如果没有回顾，你就会发现团队在不断重犯同样的错误。

我们发现，很多时候，只要能清楚的指出问题所在，到了下一个sprint，问题也许就自行解决了。
把sprint回顾结果贴在团队房间的墙上，会更有效。
在sprint中引入的每一点变化，都会让团队付出相应的代价，
在引入变化之前，可以先考虑什么都别做，寄希望于问题自动消失或变小。
如果每次有人发几句牢骚，你就引入新的变化，那人们就不愿意再说小问题了，这就大为不妙。

Scrum注重的是管理和组织实践，而XP关注的是实际的编程实践。
组合使用Scrum和XP会有显著收获。

结对编程可以提高代码质量。
结对编程可以让团队的精力更加集中，不去做与当前sprint无关的东西。
很多强烈抵制结对编程的开发人员根本就没有尝试过，而一旦尝试之后就会迅速喜欢上它。
结对编程令人精疲力竭，不能全天都这样做。
常常更换结对是有好处的。
结对编程可以增进团队间的知识传播，速度快到令人难以想象。
有些人就是不习惯结对编程。
可以把代码审查作为结对编程的替代方案。
不用键盘的家伙应该自己也有一台机器，不是用来开发，而是在需要的时候稍稍做一些探索尝试，或者遇到困难的时候查看文档等等。
不要强制大家使用结对编程，鼓励他们，提供合适的工具，让他们按照自己的节奏去尝试。

对我来说，TDD比Scrum和XP还要重要。
你可以拿走我的房子，我的电视还有我的狗，但不要试着让我停止使用TDD。
如果你不喜欢TDD，那就别让我进入你的地盘，不然我一定会想方设法来偷摸着干的。

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

TDD很难，开发人员需要花一定时间才能掌握。
实际上，往往问题并不在于你用了多少精力去教学，辅导和演示。
多数情况下，开发人员掌握它的唯一方式就是跟一个熟悉TDD的人一起结对编程，
一旦掌握以后，他就会受到彻底的影响，从此再也不想使用其他方式工作。

TDD会把开发-构建-测试这三者构成的循环变得奇快无比，同时还可以充当一张安全网，
让开发人员有足够的信心频繁重构，伴随着系统的增长，设计依然可以保持整洁和简单。

TDD是很难，但是在一开始没有用TDD进行构建的代码库上实施TDD，则是难上加难。
如果你深陷手工回归测试的泥潭，打算让它自动化执行，最好还是放弃吧。
首先还是应该想办法简化手工回归测试，然后再考虑将真正的测试变成自动化执行。

增量设计。
这表示一开始就应该保持设计简单化，然后不断进行改进。
而不是一开始努力保证它的正确性，然后就冻结它，不再改变。

很多有关敏捷软件开发的书都声称：加班工作在软件开发中会降低生产率。
经过几次不情愿的试验之后，我完全拥护这种说法。
大约一年以前，我们中有一个团队在疯狂加班。
现存代码库的质量惨不忍睹，他们不得不投入绝大多数时间来救火。
测试团队根本没时间来认真做质量保证工作。
几个月后，我们成功的把大家的工作时间缩短到了适当的范围。
他们正常上下班，除了有时候在项目关键期要加班以外。
令人惊异的是，生产率和质量都取得了显著提高。

别把最慢的一环逼得太紧。
假设验收测试是你最慢的一环，测试人员稀缺，或者低劣的代码质量造成了过长的验收测试周期。
假设你的验收测试团队每星期最多测试3个特性，而开发人员每星期能够开发6个特性。
经理或者产品负责人，甚至团队会觉得不妨安排每周开发6个特性。
千万不要。你最终一定会认识到现实的残酷，可那时伤害业已造成。
实际上，应该每周只完成3各特性，多余的时间用来攻克测试的瓶颈。
例如，让一些开发人员去做测试人员的工作。
实现一些工具或脚本，用来简化测试工作。
增加更多的自动化测试代码。
延长sprint长度，把验收测试放到sprint里面来。
雇佣更多的测试人员。

回顾可以帮助我们更好的识别出最慢的一环。

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

如果注意观察，仔细聆听，也许你会注意到虚拟团队的存在。
你选择了使用大团队，不过观察一下sprint中的交流方式，你就能发现事实上这个大团队自动分成了两个子团队。
你选择了使用三个小团队的方式，不过观察一下sprint中的交流方式，你就会发现团队1和团队2一直在交流，而团队3比较孤立。

从到目前为止观察到的情况来看，3-8个人是最佳的团队尺寸。
假设你有一个10人的Scrum团队，那么就考虑一下把最差的两个人踢出去吧。

曾经有那么一次，在一个大型产品的开发过程中，我们实施不了Scrum，因为团队成员花了太多时间来救火，
拼命忙着修复早起版本的Bug。
这是个恶性循环，影响很坏，他们花了太多时间救火，最后根本没有时间进行前瞻性的工作来防火。
改进设计，自动化测试，创建监控工具和警报工具。