标签：
本书作者是开发团队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过程的实战经验，四星推荐
标签：
原文地址：http://www.cnblogs.com/zuoqs/p/5236679.html
