我的产品团队成员并不多，开发人员三个，产品负责人我兼了技术经理，不过技术在经理一职我将站在更高的层次上去指导团队，并计划在开发团队中培养技术接班人。这一次，我的角色为产品负责人，在开发人员当中挑选一位质优者当ScrumMaster，而这个Master其实也是新手，不过我会帮助他组织日会议，为他过程方面的疑惑等。

产品Backlog我称之为产品总目标，Sprint backlob我称之为短跑目标，Sprint还是如实叫短跑。第一次Sprint启动会议在本周星期四，持续时间的确如想像中一样，相当长。从分析产品目标，确定Sprint 1实现目标，到细化目标到故事，再到任务，估算各任务工作量等，上午到中午休息再继续。共计耗时四个小时左右，比起八小时的Sprint启动会议要短了。另外，每日的会议安排在上午九点半召开，开发团队成员每次的会议要解决的问题有：
一、从上次会议到现在，我做了什么。
二、从现在开会到下次会议，我会做什么。
三、上次会议到现在，我遇到了什么问题需要大家帮助解决。
日会议我并不参与，会议记录和主持交给准Master负责。

当我决定引进Scrum，并给队员讲述该过程的时候，他们都挺欢迎这种做法，他们全部参与到需求细化与工作量评估上面来，对他们来讲是一项挑战，也是一项提升。总的来讲，对产品有好处，对团队成员也有利。

当然，过程才刚刚启动，团队可能在工作量评估和故事细化等方面能力有所欠缺，但不要紧，燃尽图会老老实实地反映出来，到Sprint验收会议的时候，初次尝试Scrun的问题会凸现出来，第二次短跑的时候会有更多的经验。

接下来看一个Timebox（我定了是三周）之后效果如何。

最后，上一张白板。看，多么草根。没办法，我们这里的办公室还是很原始的那种格子式的。。白板的内容也相对简单，一张燃尽图，三个状态的任务队列，和未计划区，其他如Sprint目标并没有写上去。。更多的信息是保存在Wiki上了。日会议要做的一件事就是把任务卡从一个地方挪到另一个地方。