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

断断续续大概花了一天多时间，读完这本书――《硝烟中的Scrum和XP——我们如何实施Scrum》。我只能说，如果你的团队正在实施敏捷实践，还不得要领，磕磕绊绊，那么还等什么呢？这本是绝对让你眼前一亮，边看边大呼：妈蛋，相见恨晚呐！

下面是阅读过程中，随手截屏和记录的文字，记录下来，仅供以后参考。

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

  为什么不能在质量上让步

• Sprint的开发周期因团队而异，需要在实践中去摸索尝试。

  Sprint的开发周期需要在实践中摸索

• 问产品经理：我们为什么要进行这次sprint？

  为什么要进行这次Sprint

• 一群傻拉吧唧的程序员，哈哈。

  一群傻啦吧唧的程序员

• 呵，有多少团队在使用这种纯粹扯淡的方法呢？！

  为何使用索引卡

• 使用索引卡对产品的backlog进行讨论分析。

  使用索引卡的优点

• 时间估算使用的计划扑克。

  计划扑克

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

  故事和任务的区别

• 的确是真知灼见，很多开发团队遇到的现实问题就是别人不知道自己的团队在做什么，整日陷入沟通和解释的泥沼中。通过这种方法，让别人清楚的了解自己团队目前正做的工作，省去很多的交流成本。

  发布信息很重要

• 贴在墙上的大白纸制作而成的任务板，简单好用。贴纸掉在地上那段是不是特别有感受，因为我们也经常碰到，的确是经验之谈。

  使用大白纸制作任务版

• 任务板的警示信息：

  • 任务消耗的太慢了，可能是有些任务比较难，前期估算不准。需要根据优先级去掉一些任务。
  • 任务消耗的太快了，可能是有些任务在实际中并没有那么难，前期估算的故事点太多。需要根据优先级添加一些任务。
  • 做任务的优先级出现问题，重要的任务没有消耗掉。需要调整任务的次序。
  任务版上的警示信息

• 对于sprint每日例会中迟到的人，这个办法的确很赞。既起到了警示的作用，又不伤了和气。最后还能给大家带来点福利。

  处理迟到的家伙

• 对于团队中刺头的策略，哈哈。

  对付团队中的刺头策略

• 为什么我们坚持所有的sprint都结束于演示？增加仪式感。

  为什么坚持做演示

• sprint演示检查列表。

  Sprint演示检查列表

• 如何组织sprint回顾。

  如何组织回顾

• 回顾中的经验之谈。圆点投票的想法很赞，有效、民主、防扯皮啊。

  回顾经验之谈

• 用降低团队的投入程度来抗争，也真是醉了。不过话说办公室环境太吵确实很苦逼，值得威胁一下领导，哈哈。

  办公室环境太吵啦

• 大爱实验日！！！只有那些真正关心员工成长进步的公司才会赢得我们的尊重和信任，那种把员工当拉磨的驴使的公司还是赶紧拜拜吧。

  实验日

• 关于结对编程的好处显而易见，但在项目实践中怎么就那么难呢？我想大部分时候都不是因为结对编程本身的人体，而是来自于领导层的重视程度和项目的压力。

  结对编程

• TDD的确是XP实践中最有价值的投入，它跟结对编程的结合，简直是珠联璧合、天下无双。但TDD比较适合于新系统，而对于遗留系统实施TDD想对要困难很多。同时TDD也催生增量设计，避免了前期的过度设计，好的想法会在TDD的过程中自己冒出来。

  测试驱动开发

• 拒绝加班，是保证可持续的开发速度和精力充沛工作的充分条件。

  拒绝加班

• 理想与现实的落差。

  理想与现实的落差

• 要想不被bug拖累，关注代码质量是关键。如果前期不控制代码质量，依靠后期的测试发现bug进行修复，只能是自己给自己团队挖坑。

  关注代码质量是关键

• 根据实际经验，一旦团队人数超过8个人，信息同步就会变得比较困难。相对独立的小团队，的确可以节约成本，提高开发效率，但前提时比较独立，不太受其他团队的制约。

  团队规模

• 虚拟团队的现象一直存在，也就是所谓的小圈子。在我的上家公司，这个现象尤其严重，虽说在一个团队，但实际上分成了两大阵营。领导者如果不能及时根据虚拟团队进行调整，就会严重影响团队的协作，甚至导致最后一个小圈子里的成员全部离开的结局。

  虚拟团队

• 团队的最佳规模，竟然也符合心理学里面神奇的7±2效应。

  最佳的团队规模

• "Pigs and chickens”是Scrum软件开发模式中的一个比喻，用来比喻参会者在每天的Scrum会议中所起的作用。

  Pigs and chickens

• 人员分配的策略：先集中，后分散；先控制，后优化。

  人员分配的策略

• 两种典型的团队组织方式：按照技术组件分，还是按照功能模块分。实际上映射了目前两种典型的系统架构模式：单体架构模式和微服务架构模式。目前看来，基于微服务的按照功能模块划分团队的方式越来越成为趋势，因为这种方式更加灵活、机动、合理，也是软件开发实践中不断摸索优化出来的方式。

  两种团队组织方式

• 纸来的来终觉浅，绝知此事要躬行。各种理论看起来很美，很有道理，但为什么在实践中都不能那么完美呢？就在于人本身是事情成败的一个最大的因素。人的需求，人的心理，人的情感，方方面面影响着事态的发展。所以任何僵化的观点都是不可取的，唯有适应变化才能顺利前行。

  纸来的来终觉浅，绝知此事要躬行

• “因为Scrum必须针对每一种不同的环境来进行具体实施，所以很难站在通用的角度上讨论何谓最佳实践。” 作者放在结尾的一这段话相当的靠谱和诚恳。没错，scrum没有所谓的放之四海而皆准的最佳实践，只有在指导思想框架下的适合本团队的相对的最佳实践。这才是追求真理之路上应该持有的态度。

  推荐书目