[Specification by Example][ch5 Deriving scope from goals]-[读书笔记]-[4]

Don't look only at the lowest level

---

许多团队受到需要将发布条目减少到一个迭代中的影响，会将后备条目的优先级降低。尽管这会帮助使得流程合理化，但是这回导致整个团队失去整体概貌的视角。

作为一个流程， Spec By Example同时为高级别用户故事也为低级别用户故事服务。一旦我们有了高级别的某些事情为什么会特别有价值的示例，我们能够捕获其为高等级的Spec。 这样高等级的示例允许我们客观评价我们是否应该发布某个特性。【As a process, Specification by Example works both for high-level and lower –level stories.  Once we have a high-level example of how something would be useful, we can capture that as a high-level specification. Suc high-level examples allow us to objectively measure whether we’ve delivered a feature.】

Ismo Aro 在Nokia Siemens的一个项目上由于没有高级别的Spec而经历了一些挫折。他说：“用户故事需要安排到迭代中， 当有一大批的用户故事完成后，他们是被分别测试的，大一些的用户故事实际上没有测试完整。当用户故事划分的比较少的时候你不能从任务列表中说这些事情是否真的完成。”。

将大的用户故事划分为较少的用户故事以便能够通过个人来发布是比较好的实践。但是当我们完成的时候我们仍然需要看一下较高级别的用户故事。和平滑的顺序的BackLog不同，我们需要一个树状的BackLog以便能够在所有的级别上工作。

低级别的Spec和测试告诉我们在发布的是在逻辑上部分正确的，高级别的验收测试将会告诉我们所有的这些内容工作在一起仍然是符合期望的。

Make Suer Teams Deliver complete featrues when: Large multisite projects

---

在多个团队协作来完成一个系统的时候，需要保证最终发布是完整的特性集合，而由于团队发布的是系统的不同的组件，所以需要将团队重新组合以便能够发布完整的产品。

Remember

---

• when you’re given requirements as tasks, push back: get the information you need to understand the real problem; then collaboratively design the solution.
• if you can’t avoid getting tasks , ask for high-level examples of how they would be useful  - this will help you understand who need them and why, so you can design the solution.
• To derive the appropriate scope, think about the business goal of a milestone and the stakeholders who can contribute or be affected by that milestone.
• Start with the outputs of a system to get the business users more engaged.
• Reorganize component teams into teams that can deliver complete features.
• Invertigate emerging techniques, including feature injection, user story mapping, and effect mapping to derive scope frm goals effectively.