敏捷整洁之道 -- 第三章 业务实践

全文学习于 《敏捷整洁之道》
作者：[美] 罗伯特·C.马丁
译者：申健 何强 罗涛

0. 引子

• 为了成功，软件的开发必须遵循许多面向业务的实践；

  • 计划游戏；
  • 小步发布；
  • 验收测试；
  • 完整团队；

• 业务实践简图：
  

1. 计划游戏

如何正确估算一个项目？

1.1 三元分析

1. 一种非常适用于大型任务的技术是三元估算；
   • 这种估算分别由 3 个数组成：
     • 最佳情况； --> 意味着你有 5% 的信心估算正确；
     • 正常情况； --> 意味着你有 50% 的信心估算正确；
     • 最坏情况； --> 意味着你有 95% 的信心估算正确；
2. 对于整个项目的长期估算而言，三元分析法异常强大，但是对于项目内部的日常管理，这种技术的精准度过差，因此使用 故事点法：

1.2 故事和点数

1. 故事点技术获得确切性和精准性的途径是非常紧密的反馈循环：

   • 根据实际情况反复校准估计值；
   • 一开始的估算很不精准，但在几个周期后，不精准度就会降低到可管理的水平；

2. 故事：也称用户故事，是从用户角度对系统功能的简短描述；

3. 故事只是占位符，而不是需求：

   • 不需要再故事卡上投入太多精力；
   • 故事卡上不需要太过于细节的东西；
   • 由于细节的缺失，所以故事卡才可以管理、计划、估算；

4. 故事必须低成本启动：

   • 因为很多故事都将被修改、拆分、合并甚至丢弃；

5. 对故事进行估算：

   • 每当添加了新故事或者了解到旧故事的新知识，就需要对故事进行估算；

6. 迭代 0 的时候需要选择一个大家认为具有平均复杂度的故事；

   • 这个具有平均复杂度的故事可以称为黄金故事（Golden Story）；
   • 被用来作为评估其他故事的标准；

7. 选择了故事之后，需要为这个故事选择故事点数；

   • 故事点数代表的是工作量而不是时间；
   • 故事点数应该大致呈线性；
   • 这些只是估计，并且估算的精准度是一个比较宽的范围；
   • 这些估计值与真实时间没有直接关系；

8. 迭代计划会议，应为迭代持续时间的 1/20；

9. 迭代 1 需要进行迭代计划会议：

   • 整个团队都需要参加；
   • 团队需要猜测一个速率，是完成故事点的速率；
   • 猜测不需要确切，只是一个完成故事点的最佳猜测；

10. 投资回报率：

    • 是用来对故事的优先级进行排序的一个指标；

    	高成本	低成本
    高价值	晚点做	现在做
    低价值	永远不做	更晚做

    • 根据投资回报率对之前的故事进行排序，当选出的故事累计到迭代 1 猜测的速率时，就停止，完成本次迭代计划；

11. 中期检查

    • 所谓的中期，就是迭代的中期，比如两周一个迭代，应该是迭代第二周的周一早上；
    • 中期检查就是根据迭代第一周完成的故事数，来动态调整故事点数，比如本迭代安排了 30 个故事点数，迭代第一周完成了 10 点，则将根据需求将故事点删减为 10；
    • 到迭代第二周周末进行检查，最终只完成了 18 个故事点，不代表迭代失败；
    • 迭代的目的就是为管理者生成数据；

12. 根据迭代 1 完成的故事点数来计划迭代 2 的故事点数，为 18；然后下一个迭代继续调整；

13. 项目结束：

    • 不是做完所有的故事项目才结束；
    • 当故事卡堆中没有值得继续开发的故事时，项目就结束了；

1.3 故事

故事遵循一组简单的指导原则，INVEST；

1. Independent（独立）：

   • 用户故事彼此相互独立，意味着在实现它们时不必遵守特定的顺序；
   • 这是一个软性的要求，因为有一些故事很可能依赖于其他故事的先行实现；

2. Negotiable（可协商）：

   • 这是不在卡片上写所有细节的另一个原因，这样开发人员和业务人员就可以就这些细节进行协商；

3. Valuable（有价值）：

   • 用户故事必须对业务有明确且可量化的价值；
   • 重构永远不可能是故事；
   • 架构设计永远不可能是故事；
   • 代码清理永远也不可能是故事；
   • 故事永远是有业务价值的东西；

4. Estimable（可估算）：

   • 用户故事必须足够具体，可以允许开发人员进行估算；

5. Small（小）：

   • 用户故事不应大于一到两个开发人员可以在一个迭代中实现的工作量；
   • 一个迭代包含的故事数量应该与团队中开发人员的数量大致相当；
     • 如果团队有 8 个人，则每个迭代应包含大约 6~12 个故事；（只是一个指导方针）

6. Testable（可测试）：

   • 业务部门应该能够提出用户故事的测试标准，通过这些测试就能表明用户故事已经完成；
   • 一个故事必须足够具体，可以用测试来说明；

1.4 故事估算

故事大小估算的方法，大多数都是传统的宽带德尔菲法 的变体；（就是之前的三元分析）

1. Flying Fingers（伸指头）：

   • 开发人员凭自己的理解对故事卡进行评估，然后所有人的数值进行对比：
     • 如果偏差小，则写入故事卡；
     • 如果偏差大，则讨论原因，然后重复上述过程，直到达成一致；

2. Shirt Sizes（衬衫尺码法）：

   • 讲故事分为大中小三档；
   • 操作估摸着和 伸指头 法类似；

3. Planning Poker（计划扑克）：

   • 与之前类似，但需要用到扑克；
   • 计划扑克使用斐波那切数列，但是正常的估算不会存在很大的故事点数；
   • 所以可以使用 1，2，3，5，8；

4. 对于无法估算的故事，需要用到穿刺(spike)；

5. 合并：

   • 合并故事很简单，将几张故事卡片夹在一起，把他们当做一个故事对待，只需要将所有故事点相加即可；
   • 如果故事点数都为 0，几个加起来的估算很可能不为 0，需要根据最佳判断来求和；

6. 拆分：

   • 程序员的工作是将故事拆分，直到分解成一行行代码；
   • 拆分过程需要贯彻 INVEST 原则；

7. 穿刺：

   • 穿刺是一个元故事，即用于估算故事的故事；
   • 之所以称之为从穿刺，是因为需要开发一个 长而很薄的切片，来打穿系统的所有层；
   • 假如有一个无法估算的故事，如打印 PDF；
     • 因为你没有用过 PDF 库，所以不确定其工作方式；
     • 因此，需要新增一个名为“估算打印 PDF 工作量”的故事；
     • 这个新的故事就是需要弄清楚如何使用 PDF 库，估算相对容易一些；
     • 这两个故事都会被放入故事卡中；

1.5 对迭代进行管理

1. 每个迭代的目标是通过完成故事来产生数据；

   • 团队应该专注于故事，而不是故事中的任务；
   • 完成 80% 的故事总比每个故事都完成了 80% 要好得多；
   • 要专注于驱动故事的完成；

2. 迭代计划会议结束后，各程序员应该选择各自负责的故事进行开发；

3. QA 应该在迭代计划会议之后开始编写验收测试；

   • 全部验收测试的编写完成应该在当前迭代的中期节点之前；
   • 如果没有在中期节点之前准备好所有的验收测试，那么一些开发人员应该停止开发故事，并开始编写验收测试；
   • 要确保开发该故事的程序员不负责编写该故事的验收测试；
   • 如果迭代中期节点之后，所有的验收测试都已经完成，则 QA 应该着手下一个迭代的验收测试；

4. 完成的定义：验收测试通过；

5. 迭代以向利益相关者简要演示新完成的故事结束，演示中应包含：

   • 所有验收测试（包括所有先前的验收测试）
   • 所有的单元测试都可以正常运行；
   • 展示新添加的功能；
   • 最好由利益相关者自己来操作，以避免开发人员试图隐藏那些不起作用的功能；

1.6 速率

1. 迭代的最后一步就是更新速率图和燃尽图；

   • 这些图仅记录了那些已经通过验收测试的那些故事点；
   • 经过几个迭代后，这两张图都将开始呈现出一条斜线；
     • 燃尽图的斜线可用于预测下一个主要里程碑的 日期；
     • 速率图的斜线则告诉我们团队管理的如何；
       • 期望的是，速率斜线的斜率为零；

2. 速率上升：

   • 速率斜线呈现正的斜率，未必表示该团队更快的前进，有可能是来自于外界的压力，导致开发速度加快；
   • 但并不是真正的开发能力提升；
   • 在迭代计划会议中估计迭代的容量只是为了让利益相关者得知可能完成多少故事，是让利益相关者选择故事和做计划的；
   • 低速率不代表失败；
   • 唯一的失败是迭代无法生成数据

3. 速率下降

   • 最有可能导致速率图明显持续的负斜率的因素是代码质量；
   • 团队很有可能没有进行足够的重构，而且可能坐视代码的腐烂；
   • 团队无法充分重构的原因之一是由于没有充分的单元测试，因此他们担心重构会破坏过去可运行的部分；

4. 不管是速率上升还是下降都会导致通货膨胀：

   • 所谓的通货膨胀：是因为团队在外部的压力下令其编制，就算短暂使得迭代完成的故事点数保证，但是下一个项目可能就不能保持这种高点数的故事完成度；
   • 为了避免通货膨胀，最好是将最初的黄金股市作为计量其他故事的准绳，可以持续将实现故事所需的故事点数估算值与其比较，来保证不会出现通货膨胀；

2. 小步发布

• 小步发布的意思就是希望开发团队应尽可能频繁的发布其软件；
• 目标就是持续交付；
• 从缩短交付周期到缩短整个项目中的所有周期；

3. 验收测试

验收测试是所有敏捷时间中最不理解、使用最少也是最混乱的实践之一；

1. 验收测试的基本思想：
   • 应该由业务方负责说明需求的规格；
   • （问题在于业务方如果写测试则可能与程序员使用的技术不匹配，如果程序员来写测试，可能不会以业务方的视角来写）

3.1 行为驱动开发

1. 行为驱动开发：BDD（Behavior-Driven Development）
   • 目标：从测试中去掉技术术语，是的测试看起来更像业务人员会喜欢的样子；
   • 3 个特定的副词：
     • Given（给定）；
     • When（当）；
     • Then（则）；

3.2 验收测试的实践

1. 验收测试的实践：

   • 业务方编写形式化的测试来描述每个用户故事的行为，开发人员负责将这些测试自动化；

2. 这些测试由业务分析和 QA 编写，需要在迭代前半部分把测试写好；

   • 这些测试就会成为迭代中故事的完成定义；
   • 如果没有写好验收测试或者验收测试没有通过，则故事就不能算完成；

4. 完整团队

1. 完整团队的时间最初被称为现场客户（On-site Customer）；
2. 其理念是：用户和程序员之间的距离越短，交流就越好，开发就越快，越精确；
   • 客户是一个隐喻，指的是理解用户需求并与开发团队共同工作的某个人或某个团队；
   • 理想状态下，客户和程序员坐在同一个房间里；
   • 在 Scrum 里，客户被称为产品负责人；