敏捷实施笔记：第0章 之前的错误

         我们是一支创意加技术实施的团队，虽然经常累个半死，大家都喜欢自由的工作状态，我们也极力想创造这样的环境。

         之前我以Scrum敏捷模式，加上分析PC Game为什么吸引玩家，将两者结合，做了一些尝试，但是效果不明显。最近公司难得有了一些空余的时间，可以忙一些内部的事情，我也有空重新看一些书籍，上网搜搜关于Scrum细节的文章。大家一起总结了一下原因。

         首先项目流程的改革并不是项目组的事，涉及到全公司所有人的配合。之前我们只是把改革放在了项目组，只让项目组的人配合实施，并且只是在项目工作中实施。其实项目组的改革应该是全公司一同来完成的。换种说法，就是项目组要实施敏捷模式，那么全公司首先要开始敏捷模式。全力配合，提供相应资源才行。

         然后是关键点。考虑到一次性太大的改动，容易让团队因为不习惯而造成效率的急剧下降。所以当时只选择了其中几个小点先开始实施。当时我们是建立了两份表，一份是Milestone，另一份是Barriers Backlog。然后重新划分了项目组人员职责。当时以个人的判断，这两份表应该是比较重要的，而且也很容易让团队的人接受。当我最近看一些Scrum文章时，发现关键点错了。比如Product Owner、迭代才是核心。当然，或许直接全面执行Scrum，而不是分步会更有效果。这个还在分析。

         还有一点就是，给团队每个人都分配了任务，但是当团队还是用原来的模式时（并没有按新的模式进行工作），大家都习以为常，没有人为此提出异议，而且大家慢慢又走回来老路。在例会时我们重新强调，坚持一段时间后又走回了老路。这里有两个原因，一个是因为没有监督者，大家都是身在其中，没有一个时刻提醒的人，加上上一阶段项目特别忙，就更被忽略了。第二个原因是，或许实施新的模式会带来阶段性的效率降低，这一点必须被告知并且接受。

         最近公司正好有一段时间可以用作调整，加上团队加了一些新人，计划重新开始实施Scrum。