《硝烟中的 Scrum 和 XP》总结

这事我读了《硝烟中的 Scrum 和 XP》后的总结，希望可以帮助到大家。

《硝烟中的 Scrum 和 XP ——我们如何实施 Scrum 》总结

• 怎样编写产品 backlog
  • 故事（Story）或 backlog 条目（事项）
    • ID
      • 统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。
    • Name
      • 简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。
    • Importance
      • 产品负责人评出一个数值，指示这个故事有多重要。例如10或150。分数越高越重要。□　我一直都想避免“优先级”这个说法，因为一般说来优先级1都表示“最高”优先级，如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢？优先级0？优先级-1？
    • Initial estimate（初始估算）
      • 团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（storypoint），一般大致相当于一个“理想的人天”（man-day）。
        • 问一下你的团队，“如果可以投入最适合的人员来完成这个故事（人数要适中，通常为2个），把你们锁到一个屋子里，有很多食物，在完全没有打扰的情况下工作，那么需要几天，才能给出一个经过测试验证、可以交付的完整实现呢？”如果答案是“把3个人关在一起，大约需要4天时间”，那么初始估算的结果就是12个故事点。
        • 不需要保证这个估值绝对无误（比如两个故事点的故事就应该花两天时间），而是要保证相对的正确性（即，两个点的故事所花费的时间应该是四个点的故事所需的一半）。
    • Howtodemo（如何做演示）
      • 它大略描述了这个故事应该如何在sprint演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果。
        • 如果你在使用TDD（测试驱动开发），那么这段描述就可以作为验收测试的伪码表示
    • Note（注解）
      • 相关信息、解释说明和对其他资料的引用等等。一般都非常简短。
• 怎样准备 sprint 计划会议
  • 在 sprint 会议之前，确保产品 backlog 井然有序
    • 只能有一个产品 backlog 和一个产品负责人（对于一个产品而言）
    • 所有重要的 backlog 条目都已经根据重要性被评估过，不同的重要程度对应不同的分数
      • 其实，重要程度比较低的backlog条目，评分相同也没关系，因为它们在这次sprint计划会议上可能根本不会被提出来。
      • 无论任何故事，只要产品负责人相信它会在下一个sprint实现，那它就应该被划分到一个特有的重要性层次。
      • 分数只是用来根据重要性对backlog条目排序。假如A的分数是20，而B的分数是100，那仅仅是说明B比A重要而已，绝不意味着B比A重要五倍。如果B的分数是21而不是100，含义也是一样的！
      • 最好在分数之间留出适当间隔，以防后面出现一个C，比A重要而不如B重要。当然我们也可以给C打一个20.5分，但这样看上去就很难看了，所以我们还是留出间隔来！
    • 产品负责人应该理解每个故事的含义
      • （通常故事都是由他来编写的，但是有的时候其他人也会添加一些请求，产品负责人对它们划分先后次序）。他不需要知道每个故事具体是如何实现的，但是他要知道为什么这个故事会在这里。
  • 注意
    • 产品负责人之外的人也可以向产品backlog中添加故事，但是他们不能说这个故事有多重要，这是产品负责人独有的权利。他们也不能添加时间估算，这是开发团队独有的权利。
• 怎样定制 sprint 计划会议
  • srpint 产生的实实在在的成果
    • sprint 目标
    • 团队成员名单及投入程度
    • sprint backlog（sprint 包含的 story 列表）
    • 确定好 sprint 的演示日期
    • 确定每日 scrum 立会的时间和地点
  • 为什么产品负责人必须参加？
    • 原因在于，每个故事都含有三个变量，它们两两之间都对彼此有着强烈依赖。下图中的范围（scope）和重要性（importance）由产品负责人设置。估算（estimate）由团队设置。在sprint计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。
    • 如果产品负责人坚持没时间参加该怎么办？
      • 试着让产品负责人理解，为什么他的直接参与事关项目成败，希望他可以改变想法。
      • 试着在团队中找到某个人，让他在会议中充当产品负责人的代表。告诉产品负责人，“既然你没法来开会，我们这次会让Jeff代表你参加。他会替你在会议中行使权利，改变故事的优先级和范围。我建议，你最好在会议开始前尽可能跟他沟通到位。如果你不喜欢Jeff当代表，也可以推荐其他人，只要他能全程参加我们的会议就行
      • 试着说服管理团队为我们安排新的产品负责人。
      • 推迟sprint的启动日期，直到产品负责人找到时间参会为止。同时拒绝承诺任何交付。让团队每天都可以自由做他们想做的事情。
  • 为什么不能在质量上让步？
    • 内部质量和外部质量
      • 外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。
      • 内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
    • 牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间，接下来的日子里你就要一直为它付出代价。一旦我们放松要求，允许代码库中暗藏问题，后面就很难恢复质量了。
  • 无休止的 sprint 计划会议
    • 会议拖的时间太长，应及时打断，选择迅速结束会议或者第二天再来。
  • sprint 计划会议日程
    • 典型时间表
      • sprint计划会议：13：00–17：00（每小时休息10分钟）
        • 13：00–13：30　产品负责人对sprint目标进行总体介绍，概括产品backlog。确定演示的时间和地点。
        • 13：30–15：00　团队估算时间，在必要的情况下拆分backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的backlog条目都要填写“如何演示”。
        • 15：00–16：00　团队选择要放入sprint中的故事。计算生产率，用作核查工作安排的基础。
        • 16：00–17：00　为每日scrum会议（以下简称每日例会）安排固定的时间和地点（如果和上次不同的话）。把故事进一步拆分成任务。
  • 确定 sprint 长度
    • 最佳时长
      • 三星期
  • 确定 sprint 目标
    • sprint目标需要回答这个根本的问题，“我们为什么要进行这个sprint？为什么我们不直接放假算了？”要想从产品负责人的口中诱导出sprint目标，你不妨一字不差地问他这个问题看看。
    • 目标必须用专业术语表达，而不是技术术语，让团队以外的人也能理解
      • 挣更多的钱
      • 完成优先级排到最前面的三个故事
      • 打动 CEO
      • 把系统做的足够好，可以作为 beta 版发布给真正的用户使用
      • 添加基本的后台系统支持
      • 等等
  • 决定 sprint 要包含的故事
    • 在sprint中包含多少故事由团队决定，而不是产品负责人或其他人。
  • 产品负责人如何对sprint 放哪些故事产生影响？
    • 重新设置故事优先级
    • 更改故事范围
    • 拆分故事
  • 团队怎么决定把哪些故事放到 sprint 里？
    • 本能反应
      • 如果 sprint 的时间不长，小团队根据知觉进行评估可以收到很好的效果
    • 生产率计算
      • 得出估算生产率
        • 有一个很简单的办法：看看团队的历史。看看他们在过去几个sprint里面的生产率是多少，然后假定在下一个sprint里面生产率差不多不变。
      • 计算在不超出估算生产率的情况下加入过少故事