实践1: 在问如何做之前先问做什么、为什么做、给谁做
不要说如何
一旦开发团队听到或看到描述如何做事的需求, 他们就被束缚了双手. 这等于直接说"用这样的方式做". 然后开发者照着编码, 通常情况下他们机械性地堆砌代码, 而不会后退一步去问一句"我怎么能够创建一组交互的对象以实现这个行为呢".
将"如何"变为"为什么"
要有一个产品负责人
一方面, 产品负责人是一个超级明星. 另一方面, 产品负责人对产品来说生死攸关. 有时候产品负责人被称为产品的七寸. 这个角色必须有绝对的权威.
产品负责人是沟通的中枢.
故事描述了做什么、为什么做、给谁做
许多团队花费了大量时间在需求文档和设计文档上, 忘记了软件开发实际上全在于编码. 这些团队最后让那些不连贯的文档和代码分离. 实际上代码本身应该承载着那些知识.
为验收测试设立明确的标准
- 验收标准是什么?
- 和开发者展开对话需要了解多少细节?
自动化验收标准
通过验收测试来描述需求, 验收测试就容纳了丰富的信息. 它帮助开发者理解用户真实的业务需求, 所以我们能够正确的编写代码, 而且代码具有非常好的可读性. 验收测试帮助定义系统行为, 提供输入和期望输出的真实样例.
无论是否使用自动化测试, 把验收标准和边界情况写在用户故事卡片上都是好办法, 可以用来提醒你需要处理哪些异常. 知道一个功能在满足了特定验收标准之后就算完成了, 这样可以让开发过程更加专注.
让我们付诸实践
产品负责人的7个策略
- 成为特定领域的专家
- 在开发过程中探索
- 帮助开发者理解为什么和为了谁
- 描述你想要什么, 而不是怎么做
- 产品负责人必须注意不要告诉开发者如何做某一件事情, 而是告诉他们要做什么. 这样可以给开发者更多的自由, 想出更容易维护的解决方案.
- 及时回答问题
- 消除依赖
- 支持重构
编写出更好故事的7个策略
- 把它当做一个占位符
- 关注"什么"
- 把"谁"人格化
- 知道为什么会有一个功能需求
- 开始时简单, 日后再加强
- 心系边界情况
- 用户故事陈述了快乐路径, 但我们也需要考虑有多其它路径, 包括次要路径、宜昌路径、错误路径.
- 使用验收标准
实践2: 小批次构建
度量软件开发的7个策略
- 度量产生价值的时间
- 我们生产软件是为了满足需要, 从开始构建产品到用户发现价值的时间, 可以用来有效度量我们的效率. 对整体进程没有影响的局部优化都是没有意义的. 度量"产生价值的时间"帮助我们着眼大局——值得度量的东西.
- 度量编码时间
- 好的开发流程是, 开发者可以花大部分时间在实际开发商上的流程.
- 度量缺陷密度
- 度量发现缺陷的时间
- 度量功能的客户价值
- 度量未交付功能的损失
- 度量反馈回路的效率
分隔用户故事的7个策略
- 把复合的故事拆分为组件
- 如果故事里面有子故事, 则把它们分割为多个故事.
- 把复杂的故事分割为已知和未知
- 故事之所以复杂, 通常是因为其中包含位置因素. 我们也许不知道客户到底想要什么, 或许不知道如何实现客户所想. 把已知和未知分离是分隔包含未知因素的故事的第一步.
- 对未知持续迭代直至完全理解
- 根据验收标准分隔故事
- 最小化依赖
- 保持目的的单一
- 保持故事可测试性