最初技术团队接到产品需求后，对需求进行任务拆分。拆分的规则是每一个任务必须是完整的、可测试的、没有交叉的；任务允许在后期进行继续细化拆分；任务要可以并行开发。在任务拆分后，我们借助公司会议室的大玻璃墙作为我们的Scrum任务板，所有的任务直接贴上，大家随时路过都可以看到。

任务墙纵向分成四列，分别表示待实现任务（Backlog）、进行中任务（In Processing）、待检验任务（To Be Verified）和已完成任务（Finish）。每一个任务对应一张小纸条，上面要明确的标注任务内容、负责人、预计提测时间、预计完成时间（测试通过）。初始的任务停留在待实现任务的格子中；当任务开始开发的时候则移至进行中的格子；当开发完成可提测则移至待检验的格子；然后测试工程师对任务进行专门测试，测试通过后任务完成。
任务墙横向分成几行，每一行表示一个里程碑，所有的里程碑的任务都在这一行的四个格子里游走。这里我们没有采用Scrum的故事的形式而是里程碑，主要是考虑到团队对这种开发模式的接受程度的问题，因为以往的开发是没有故事的概念的。当一个里程碑的所有任务都完成之后，这个里程碑宣告完成。

保证项目能够顺利进行的另一个重要的措施是每日站会（晨会）。每天早上第一件事就是大家凑在任务墙前，逐一的和整个团队分享任务进展状况和遇到的技术问题。这样整个团队能够在第一时间了解到整体进度；通过晨会也增加的不同工程师之间的交流，让潜在的问题、对需求的误解等及时暴露出来，这样就算是走了弯路，最多一天后就可以发现并纠正。直到先在我们还继续保持着早会的习惯。

因为团队刚刚组建，随着项目的进行，会有新的工程师补充进来。加之需求变更和技术细化，我们都会对任务进行重新估算和拆分。新拆开的任务同样贴在任务墙上受到监控。当我们的项目结束时候，任务墙的小纸条的数量已经是最初的一倍多了。

任务卡的引入，保证了项目进度的透明和可监控；任务拆分的原则保证了不同开发组的并行和测试提前介入；每日站会保证了项目成员的及时沟通，让隐患快速发现并解决。项目临近结束就是单纯的修改各项任务中的各种Bug，而没有出现一般项目中容易发生的需求和技术反复、或者是哪里没考虑到导致返工的情况。通过这些努力，最终我们的项目按时上线。

项目历时一个月，但是大家加班都是很辛苦的，工作量相当于两个月，在最后我们看着所有的任务都安安静静的排列在已完成这个格子里的时候，那种对团队认同、信任、自豪是无法用言语表达的。也希望这支团队越来越强。加油！

完成了第一版的几乎所有功能，当然仅仅是完成了功能。在使用ScrumWorks进行自我管理的时候还是可以的，但是自己一个人就有一个大问题，就是基本上想到了什么任务就做什么任务，而没有从最初就设定一系列的任务然后自我分配，这就是项目管理的最大的问题。我想也许是因为一个人的缘故吧。
但是这里面存在的一个问题就是，这样干到哪想到哪的方式，是很混乱的，几乎就是没有管理嘛。要非说有，也是存在于一个自己脑子里面的一时干不完的TODO list。

为了改变这个龌龊的做法，我对自己进行了如下的要求。

1. 设定最终完成要达到的状态，也就是做的这个东西要满足什么需求
2. 根据这些需求拆分功能和组件
3. 设定Milestone，每一个Milestone要完成什么东西
4. 根据情况设定工作时长，每一个Milestone的完成时间（这个可以酌情）
5. 使用一个工具记录下来这些
6. Just Do It

这里面的几个难点

1. 针对上面的要求1，很多时候我们是做不到的，也就是我们在做一个东西的时候，大多的时候只有一个笼统的想法，和最后我要把这个东西做成一个什么样子。但是具体的是什么，也许我们并说不清楚。这个东西越大，越说不清楚。
   所以，我要求自己停下来，好好的想，我到底要一个什么东西，我要干什么，要实现什么功能，要满足我什么需求，这个一定要想清楚。
2. 针对上面的要求2，我们大多时候，是不能非常好的进行拆分的，我们缺乏的是经验，没办法，多做吧。
3. 针对上面的5，一定要用一个工具记录下来，因为你不记录下来，没有监督，那不就是自我安慰了么。现在的工具很多，Trac，Redmine，很多很多的。最不济的，记事本你总有吧，纸笔你总有吧。

在这个为期两天的一个土鳖小项目里面，我发现工具的重要性，我现在是Bug，REF，什么的都放在Trac上面，但是我的Task，时间管理都是使用ScrumWorks（而且这个还是一个试用版）。我没有找到一个能够把他们都管理起来并且很容易结合的东西。对了，Trac 还不支持bzr。

看来没办法，只能自己写了。
现在正在缓慢的进行一个项目，就是做一个完整的 Ticket，代码，时间管理的工具，最好天然的支持Scrum。

刚刚看完Scrum，发现和我平常期望的，理想的，使用的方法很像很像（看来我有慧根）。所以打算自己一个人试试看。并结合TDD等方法，把自己管起来。

毕竟，刚刚入门，而且一个人，难免有东施效颦，丢三落四的情况出现。

第一天，也就是今天凌晨
1，项目初创
开始新项目，使用bzr开启一个新的repository，开工。
采用TDD，构建一个最简单的，最土鳖的测试用例，不要求很完整，只是一个对大多数常用功能的简单使用，目的是为了尽快的搭建出项目原型和框架。
遵照Uncle Bob的谆谆教诲，在完成一个土鳖测试用例之后，成功的让Eclipse画出来一坨坨的小红线（编译不过嘛）。然后撰写真正的Interface，还有Abstract Class，真不错，终于编译成功。

收获：这个过程并不是一个浪费时间的过程，而是结合了思考，设计，具体请参见我的《初涉敏捷编程》。这过程中出现了很多的对API的推敲，对类的职能的思考。
而且，在写真正的接口的时候，可以不用过多的考虑用不到的方法，也就是我总说的，关注一个类的职能。Duty Oriented.

2，开始功能实现
有了用例和接口，就可以写实现了。因为项目的特性，一个只读的数据存储结构是最合适的。但是无奈项目时间紧迫，所以我没有这么充裕的时间去选型，甚至设计实现一个适合这个场景的存储结构。所以我把实现分成了多个部分，第一部分，也就是使用传统的数据库作为存储，这样可以最快的实现功能，并且满足现在访问量并不大的情况。以后随着访问量的增加以及时间的充裕，可以继续完善甚至更改存储体系。

醒目的目录结构是这样的
./src
./src/com/yes7080/saybar （存放所有的接口，并且这是使用时候的统一入口）
./src/com/yes7080/saybar/impl （存放实现）
./src/com/yes7080/saybar/impl/datamodel （存放使用datamodel，亦即使用数据库的实现）
./test
./test/src
./test/src/com/yes7080/test/saybar （测试代码）
实现使用了二级目录结构，也就是使用impl/datamodel，这样的目的就是因为以后可能出现其他的存储方式。而且，正因为这样从目录解耦，就可以更好的进行设计了（具体的设计思想，我以后会撰文解说的）。

很爽的写了很多，很土鳖的没有采用任何的项目管理。工具使用Trac，但是更多的是一个用于文档和Ticket跟踪。
所以我决定对自己采用Scrum进行管理。也对自己有一个监控。

最开始，实话实说，我真的忘记了Scrum具体应该怎么开始了，但是非常简单，用户故事（是这样么说么）只有一个，就是实现一个用数据库的存储。我给自己两天的时间，也就是后天天亮之前完成，大约是还有10-16小时的工作时间。然后在看情况进行修改吧。嘿嘿~
暂时给自己定一个时间，然后，继续工作鸟~~