前些天对需求讨论确定后开始制定计划安排。
根据最近对agile的一些体会我这次制定计划是这样的：

1、根据需求的功能点定义，把需求纵向切割成一个个较为独立的story，然后把这个story归入到计划中。
解释：对于一个story来说，所有的分析、设计、实现都是由一个开发者来完成的。当然在开始实现前对于一般的设计都是要一起讨论的
这时候story可以确立的基本属性有：title（标题）description（描述）

2、我把story收集好之后，根据需求的复杂度和优先级作了一个初步的分析，然后再和资深的developer做一次沟通，大概预估以下每个story需要花费的时间，然后根据老大给我的时间要求把story分成了两个iteration
这时候可以确定的story属性有：Iteration（迭代周期）  Priority（优先级） Release（发布版本） Status（状态） PlanSize（计划时间）

3、当我确定了在当前迭代周期需要完成的story之后，我就会在开发小组内部召开一个小讨论，罗列出这个迭代周期内有哪些功能需要完成，然后由大家自己选择感兴趣的story
在选择story的同时可以经过讨论确立的属性有：developer（开发者）

至此一个迭代发布版本的粗略计划，一个迭代周期的详细计划就已经出来了。

but，当我把这个计划提交给我老大的时候，他们提出了几个问题：
1、一个功能纵向开发，如何知道开发者每天的工作任务，如何知道他现在是在做设计和还是在做开发
2、以前的开发是有一个专门负责实现设计和后台接口实现，一个专门负责调用接口和前台实现，这样由一个人开发后，有些人可能会在模型和接口的实现上因为经验不足而造成失误
3、让一个人独立开发一块功能，是不是破坏了项目组内部的协作机制，是否会让开发者感觉到他是孤独的
4、如何考察一个开发者的工作是否饱和？

对于上面的问题，我经过思考和讨论后给出了这样的回答：
1、每天都会由我发起一个简短的状态了解，了解每个story的进度，是在分析，是在设计，设计还是在实现了我都会对story做一个记录
2、一个人纵向开发也许会经验不足造成接口不够全面，但是由于是他一个人开发，他可以方便的根据自己需求来修改接口。而且两个人在横向开发时会有一些沟通交流问题而造成成本增加。（实际上在完全的agile中是由两个人结队开发，而且通常的组合是一个经验丰富的带一个经验少的）
3、在功能开发时，无论是分析，设计，还是实现发现问题都可以立即举手进行讨论。可以说只要有问题就是团队一起解决的。
4、这其实是只如何对开发者进行工作量考核了，我觉得从敏捷的角度来看考核的问题比较简单，就是你最终实现的完整功能（因为只有完整的功能才能给产品带来价值）所花费的时间和预期时间的差值。比如说一个story预期是6点（两点为一天）完成，结果你用3点就做完了，那么你的考核点就是+3，但是这还没完，当测试后发现这个功能点出现一次bug，你的考核点就要扣除1点，这样最终的考核点就是2点。

经过和老大的讨论之后，他们觉得以功能story来分配的方法和以前已工作任务来分配的方法是有些难以控制的，但是还是同意我开始在项目组试行（这里要赞一下我老大的开明态度）

最后提一下我用于agile项目管理的工具，相信很多人都猜到了，就是mingle

下篇预告：mingle使用小记    时间：2007-9-11