过程改进日记之学习Scrum2010-8-17 Backlog or Feature list（一）

今天例会照例只有我和PM站着，不过居然除了我之外没迟到的，可喜可贺。

今天是最近一个月要做的需求review，涉及三个模块，分成三次，参加者包括PM、DPM、UI Design、QAPM（产品测试负责人）主创开发工程师分别进场，轮流参加。这样可以避免浪费时间。（不过，我觉得有机会需要大家一起简单过一下，这样大家可以互相知道各自在做什么）

我们的需求包括了低保真界面和一些相对细致的逻辑，因此，大家很容易形成讨论的基础，虽然PM写的还是比较详细，但还是有些应用场景没有覆盖到。

需求评审实际上是传统模式的一个重要部分，他和Backlog最大的不同，就是需求是整体的目标，而Backlog更适合在一个Sprint中来完成，有些复杂的部分，我们觉得不应该太重要，而PM会说，这个本来就不是优先级很高的任务，将来我们要做这么多，但现在只要最简单的逻辑。
个人觉得，需求评审应该是一种必须的，他有助于确定产品定位，以及整体结构。是达成共识的基础。
Backlog应该是基于低保真的需求，在此基础上分解到每个Sprint中，实际上，讲故事这个环节一直是我们的工作中的必须活动，每次，我们讨论有争议的时候都会有无数个故事来证明各自的观点，但和Scrum模式不同的是，我们讲的故事更多的是讨论中提出问题所用，没有被做为证据保留下来，事实证明，没有记录下故事，会导致我们在将来增加工程师的时候，这些故事被一次次在讨论中重新提起。

之前我觉得一个story包含若干个backlog，有同事指出，应该是一个backlog包含若干个story，看起来应该是我理解错了，明天再确认下。