在看了N遍之后，N>10。越觉得Scrum的可行性很好，就准备先拿一个小项目来试试。
首先这个DMM项目只有功能需求，无操作界面需求，提供的文字没超过两行。
之前的做法：做系统设计，数据库设计，UI设计。
Scrum的做法：编写产品backlog,做Sprint计划会。
编写产品backlog是我看这本书的一大亮点，一直以来就为这个如何演示所困扰。因为不清楚这回事，有需求来了就开工，完全不知道如何结束。做到满意为止，当然是个美好的愿望。但做为一个开发人员来说，一个功能反反复复得修改，工作得不到认同，会有失落感。backlog的如何演示解决了这个问题。一个业务需求，配上如何演示，就有了衡量开发是否完成的标准。
操练第一步：编写产品backlog
backlog看书上说得这么轻巧，就列了一下字段。真要写个如何演示出来，还是有难度，它有点象测试用例。不过在编写的时候，有个感觉很好，如何演示就象已经在做好的系统上操作一样，想象着去测试各个功能。自己在写的过程中，还是不自觉得开始罗列一些对象，属性。不知道有没有停留在业务层次上。然后我就列了12个backlog。照书上的方法打印成卡片。
操练第二步：Sprint计划会
虽说书看了N遍，一召集人马开会，就全忘光了。我把卡片往桌上一摊，先让大家看。然后讨论功能，对优先级做了些调整。之后就开始做估计值了。因为之前团队里玩过几次计划纸牌游戏，对这个熟啊。在估计过程中，对几个功能相近，用时偏小的backlog进行了合并。最后得出7个backlog，估计值16。
在做完这些之后，我居然宣布散会了。回来一整理，才发现什么sprint周期，目标，演示日期等提都没提。晕啊。好在我说了下周一来了做任务分解。
整理后，按3个开发人员计算，70%的投入度，得出8天的开发周期。考滤这个项目次要，大家手上还有其它重要的项目在做，这个投入度还得再降一降。下周日会再汇总一下意见，订个目标，演示日期出来。
