美文网首页
《硝烟中的Scrum和XP》读书笔记

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

作者: 筒中窥猫 | 来源:发表于2016-06-21 10:17 被阅读780次

    断断续续大概花了一天多时间,读完这本书――《硝烟中的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没有所谓的放之四海而皆准的最佳实践,只有在指导思想框架下的适合本团队的相对的最佳实践。这才是追求真理之路上应该持有的态度。

      推荐书目

    相关文章

      网友评论

          本文标题:《硝烟中的Scrum和XP》读书笔记

          本文链接:https://www.haomeiwen.com/subject/hpqgdttx.html