《修改软件的艺术》读书笔记

实践1: 在问如何做之前先问做什么、为什么做、给谁做

不要说如何

一旦开发团队听到或看到描述如何做事的需求, 他们就被束缚了双手. 这等于直接说"用这样的方式做". 然后开发者照着编码, 通常情况下他们机械性地堆砌代码, 而不会后退一步去问一句"我怎么能够创建一组交互的对象以实现这个行为呢".

将"如何"变为"为什么"

要有一个产品负责人

一方面, 产品负责人是一个超级明星. 另一方面, 产品负责人对产品来说生死攸关. 有时候产品负责人被称为产品的七寸. 这个角色必须有绝对的权威.

产品负责人是沟通的中枢.

故事描述了做什么、为什么做、给谁做

许多团队花费了大量时间在需求文档和设计文档上, 忘记了软件开发实际上全在于编码. 这些团队最后让那些不连贯的文档和代码分离. 实际上代码本身应该承载着那些知识.

为验收测试设立明确的标准

• 验收标准是什么？
• 和开发者展开对话需要了解多少细节?

自动化验收标准

通过验收测试来描述需求, 验收测试就容纳了丰富的信息. 它帮助开发者理解用户真实的业务需求, 所以我们能够正确的编写代码, 而且代码具有非常好的可读性. 验收测试帮助定义系统行为, 提供输入和期望输出的真实样例.

无论是否使用自动化测试, 把验收标准和边界情况写在用户故事卡片上都是好办法, 可以用来提醒你需要处理哪些异常. 知道一个功能在满足了特定验收标准之后就算完成了, 这样可以让开发过程更加专注.

让我们付诸实践

产品负责人的7个策略

• 成为特定领域的专家
• 在开发过程中探索
• 帮助开发者理解为什么和为了谁
• 描述你想要什么, 而不是怎么做
  • 产品负责人必须注意不要告诉开发者如何做某一件事情, 而是告诉他们要做什么. 这样可以给开发者更多的自由, 想出更容易维护的解决方案.
• 及时回答问题
• 消除依赖
• 支持重构

编写出更好故事的7个策略

• 把它当做一个占位符
• 关注"什么"
• 把"谁"人格化
• 知道为什么会有一个功能需求
• 开始时简单, 日后再加强
• 心系边界情况
  • 用户故事陈述了快乐路径, 但我们也需要考虑有多其它路径, 包括次要路径、宜昌路径、错误路径.
• 使用验收标准

实践2: 小批次构建

度量软件开发的7个策略

• 度量产生价值的时间
  • 我们生产软件是为了满足需要, 从开始构建产品到用户发现价值的时间, 可以用来有效度量我们的效率. 对整体进程没有影响的局部优化都是没有意义的. 度量"产生价值的时间"帮助我们着眼大局——值得度量的东西.
• 度量编码时间
  • 好的开发流程是, 开发者可以花大部分时间在实际开发商上的流程.
• 度量缺陷密度
• 度量发现缺陷的时间
• 度量功能的客户价值
• 度量未交付功能的损失
• 度量反馈回路的效率

分隔用户故事的7个策略

• 把复合的故事拆分为组件
  • 如果故事里面有子故事, 则把它们分割为多个故事.
• 把复杂的故事分割为已知和未知
  • 故事之所以复杂, 通常是因为其中包含位置因素. 我们也许不知道客户到底想要什么, 或许不知道如何实现客户所想. 把已知和未知分离是分隔包含未知因素的故事的第一步.
• 对未知持续迭代直至完全理解
• 根据验收标准分隔故事
• 最小化依赖
• 保持目的的单一
• 保持故事可测试性