《硝烟中的Scrum和XP》:作者主导Scrum过程的实战经验,四星推荐

本书作者是开发团队Leader,本书记录了他带领团队实施Scurm过程中的经验教训。全书短小精悍,言简意赅。

以下是书中一些观点信息的摘抄:

1:Nokia总结出的迭代开发的基本要求:
1.1:迭代要有固定时长,不能超过六个星期;
1.2:在每一次迭代的结尾,代码都必须经过QA的测试,能够正常工作;

2:Nokia的Scurm标准:
2.1:Scurm团队必须要有产品负责人,而且团队都清楚这个人是谁;
2.2:产品负责人必须要有产品backlog,其中包括团队对它进行的估算;
2.3:团队必须要有燃尽图,而且要了解他们自己的生产率;
2.4:在一个sprint中,外人不能干涉团队的工作;

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

4:我尽力把内部质量和外部质量分开。
4.1:外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣;
4.2:内部质量一般指用户看不到的要素,它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等;

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

6:为了调整不同的人对故事的工作量的估算的差异,我们采用了计划扑克方法:每个人独立估算工作量,然后公开,差异比较大的成员互相沟通直至时间估算趋于一致;

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

8:产品负责人往往不能对技术故事的优先级作出正确的权衡;

9:只要让团队坐到一起,就会有立竿见影的成效。过上一个sprint,团队就会认为挪到一起是绝妙的主意。“一起”具有以下含义:互相听到,互相看到,相对独立(团队突然开始激烈讨论,不会影响团队外的任何人);

10:我们的目标是在每个sprint之间安排一个实验日(这一天员工可以干任何想干的事情),目前实际执行的是每个月有一个实验日,放在每个月的第一个星期五;

11:TDD(测试驱动开发)很难,但是在一开始没有用TDD进行构建的代码库上实施TDD……则是难上加难!

12:如果你深陷手工回归测试的泥潭,打算让它自动化执行,最好还是放弃吧。首先还是应该想办法简化手工回归测试,然后再考虑将真正的测试变成自动化执行;

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

14:我们在实施Scrum的时候,所做的第一件事情就是打乱基于组件的团队,创建跨组件的团队。它减少了诸如“我们没法完成这个任务,因为我们在等服务器那帮家伙完成他们的工作”之类的情况发生;

15:“团队凝聚力”是Scrum的核心要素之一,如果一个团队合作工作达多个sprint之久,他们就会变得非常紧密。他们会学会如何达成团队涌流(group flow),生产力会提升至难以置信的地步。

你可能感兴趣的:(《硝烟中的Scrum和XP》:作者主导Scrum过程的实战经验,四星推荐)