一个非常有用而且简单的工具—产品列表（Product Backlog）。团队敏捷转型，在接受了普及培训之后，第一个要做的事情就是建立一个且是唯一的产品列表。这么做最重要的原因就是需求统一入口。
一个产品只有一个产品列表，并且产品列表要符合DEEP原则，即Detailed Appropriately, Emergent, Estimated, Prioritized.
介绍一下DEEP原则，对应的中文分别是：
Detailed Appropriately详略得当的。也就是说产品列表中的需求条目是有粗粒度的，也有细粒度的，不是完全一样的。马上要做的需求，一定属于细粒度的；而1个月后要做的可能就是粗粒度的。
Emergent涌现的。产品列表中的需求是涌现出来的。可能在产品开发过程中，用户或开发人员有一个很好的想法或点子，那么我们就把它加到产品列表中去。
Estimated估算过的。每一个需求条目需要是做过估算的。只有做过估算，我们才知道它的规模大小，再结合已知需求的价值大小，我们就能判断出这个需求的投入产出比。
Prioritized排序的。每个需求条目都有一个唯一的顺序。
「四个基本点：透明 迭代 持续改进 教练」
基本点一：透明。
敏捷软件开发当中最重要的基本点就是，透明。回想一下上面的案例中，团队转型一定要尽量让团队坐在一起，这是保证透明的基础。团队坐在一起之后，团队间的沟通会比原来顺畅很多，信息也就很容易的暴露出来，即团队信息状态的透明。
敏捷转型中的另一个很重要的基础设施是任务板。对于一开始实施敏捷转型的团队，我强烈建议使用物理的任务板。物理任务板有非常多的好处：
团队信息以及团队进展的公开。
每个人每天都需要更新自己的任务，受到同僚压力，团队中滥竽充数的人几乎不存在。
物理任务板可以任意进行重新规划和设计。（相比电子任务板）。
基本点二：迭代。
有些人在说敏捷是什么的时候就说，敏捷就是快速迭代。这个说法有点过于片面，不过也说明了迭代是敏捷当中很重要的一个基本点。
两周一个迭代周期，并且迭代结束的时候一定要交付出潜在可交付的产品增量。这样有什么好处呢？
两周固定的迭代周期，省去预定会议的行政事务，团队可以形成习惯。
两周就会有交付物，相比原来两个月甚至一年才有一次交付物，这是一个极大的提高。
对于软件开发来说，用户能看到（或者使用）产品才是最关键的。因为只有用户看到（或使用）产品，他才可以给出真实的反馈。团队才能基于用户的反馈做出调整，做出用户真正想要的产品。
基本点三：持续改进。
一提到持续改进我就想起一位日本友人的介绍：持续改进在日语中是Kaizen。他跟我们提到1次改进不是Kaizen，10次改进也不是Kaizen，100次改进也不是Kaizen，只有做到1000次改进才能算是真正的Kaizen，即持续改进。为什么一定是1000次呢，他说到只有做到了1000次改进才能养成改进的习惯，才能算作持续改进。
在Scrum中有三个会议可以给团队提供持续改进的机会。
每日站会。每天团队在一起，同步团队整体的进展情况，相互鼓励并改进。
迭代评审会。团队和产品负责人一起回顾一下迭代内的产品增量，以及利益干系人都有哪些反馈。这是一个非常好的改进产品的机会。
迭代回顾会。团队在一起反思，作为一个团队我们哪里做的好，哪里可以做的更好，哪些是我们想要尝试的。回顾会是一个团队工作流程改进的机会。
基本点四：教练。
在我的Scrum Master敏捷训练营培训课上，我会介绍Scrum的三条腿的基础
