功能还是任务--制定敏捷计划

前些天对需求讨论确定后开始制定计划安排。
根据最近对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

我一直有一个问题，就是每个人独立的完成各自的story的时候，遇到问题，如果这些问题是与story的具体需求联系在一起的，而其他人并不能深刻的理解这个story，所以要让别人帮忙来一起讨论解决问题的话，还需要跟他们沟通这个需求，而且既然是遇到的难题，所以也并不能指望别人一理解了需求之后就能拿出一个合适的解决方案，所以也会继续跟这个人讨论，一起解决，或者是再去寻求另一个人，沟通需求，然后解决。
其实这也是一个很浪费时间的过程，尤其是在寻求一个人无效而去寻求另外的人的时候。
也许有些人说，举手讨论时，全组的人都聚过来一起讨论，解决，但这样的话我觉得不太现实。

[quote="fly_ever"][quote]在功能开发时，无论是分析，设计，还是实现发现问题都可以立即举手进行讨论。可以说只要有问题就是团队一起解决的[/quote] 我一直有一个问题，就是每个人独立的完成各自的story的时候，遇到问题，如果这些问题是与story的具体需求联系在一起的，而其他人并不能深刻的理解这个story，所以要让别人帮忙来一起讨论解决问题的话，还需要跟他们沟通这个需求，而且既然是遇到的难题，所以也并不能指望别人一理解了需求之后就能拿出一个合适的解决方案，所以也会继续跟这个人讨论，一起解决，或者是再去寻求另一个人，沟通需求，然后解决。 其实这也是一个很浪费时间的过程，尤其是在寻求一个人无效而去寻求另外的人的时候。 也许有些人说，举手讨论时，全组的人都聚过来一起讨论，解决，但这样的话我觉得不太现实。[/quote]


从你的描述中可以看到一个问题就是，在讨论之前，参与讨论的人并不了解需求。这里才是导致你觉得沟通代价高的原因了。其实我们的做法是这样的，当需求收集的差不多时，会拉上所以团队内部的人员（开发，测试，市场），来召开一个需求讨论会，这个会议的目的一个是大家一起讨论来确认或者否决一些需求，另一个目的就是让所有人知道，我们要做的东西是什么。所以，当把story交给某一个开发者开发的时候，其实开发团队内别人对这个需求也是有所了解的。这样当开发者遇到问题来具体讨论的时候，只是讨论他所遇到的问题：这个需求点不明确啊，这个设计是否合理啊，这个实现有什么更好的方案啊等等。至于参与讨论的人，通常情况是自由自愿，就是你听到了问题，你自己可以随时参与到问题讨论中来。但是当有些story格外重要的时候，我会主动发起讨论，把同组的资深开发者邀请进来一起研究解决方案

当然在项目开始前，团队内部成员对整个需求都会去了解，每个成员都会了解要做的东西，并且每个成员对自己负责的部分会了解得更加细致，但是不可能对别人的部分也了解得很细致，很深刻。
其实我说的有些功能或者说遇到的有些问题是要深刻的理解这个story的需求才能给出一个合适的方案的，而不只是了解需求，所以这时候就会出现需求的沟通。

哦，个人认为有两个角度来解决则合格问题
1、story的划分粒度有多大，就是一个人完成的story在给别人介绍需求的时候应该是可以很快并且较为详细的介绍清楚的。（一般来说我划分一个story的plan size不会超过4天）
2、一个story在以后开发中会不断地变更需求进行维护，这时候你不能指望维护的那个人还是当时的开发者，所以我觉得花费在这种沟通之间的代价是有必要的。

比如说一个story预期是6点（两点为一天）完成，结果你用3点就做完了，那么你的考核点就是+3，但是这还没完，当测试后发现这个功能点出现一次bug，你的考核点就要扣除1点，这样最终的考核点就是2点。

这个我不太赞成，就我所在的公司而言，很有可能进行一次Checkin的时候，我就已经知道了其中有很多Bug，但是仍然需要CheckIn，如果不及时CheckIn,就无法让QA进行测试，得到最终的版本。Bug并不能作为考核的主要手段。主要手段仍然是由项目经理来评估你的效绩的，不同的人由于水平不同相同时间的成绩肯定是不同的。如果我愿意的话，我可以一天做完整个星期的任务，事实上也确实如此。当然每个公司的管理手段都是不一样的，我们公司是以Bug进行驱动的，如果Bug改完了，只能等着PM assign 新的bug，feature 也是bug.

最好的方式当然还是Senior开始新的模块，如果很忙的话，由junior来维护这个模块，不忙的话，谁做的谁维护。Junior虽说有点像打杂的，但是review别人的代码对自己的水平提高也是显而易见的。人不管水平高低，都是可以培养出来的。

[quote="cnfree"]最好的方式当然还是Senior开始新的模块，如果很忙的话，由junior来维护这个模块，不忙的话，谁做的谁维护。Junior虽说有点像打杂的，但是review别人的代码对自己的水平提高也是显而易见的。人不管水平高低，都是可以培养出来的。 [/quote]

这个方法是我以前没有想到的，我觉得很好。我原来的想法是，来新人之后开始结对，这样让新人在结对过程中学习，进步。但是我觉得做为一个coder来说，必须要有很强的view code能力。这个是一开始就要培养的。

对于考核的建议来说，我的出发点是完成的功能，不是工作的饱和度，可能各有优劣。我只是觉得做为pm来说主观的来考核别人很不负责的，至少我考核别人的时候觉得比较困难。

 

想问几个问题：

1  目前项目进展到什么程度了? 有没有达到预期的效果?
2  你的Team member的资历大概是什么样的? 是否每个member都有相当的能力做有品质的分析和设计?
3  纵向切分任务，那横向的framework层面的部分谁来负责，你怎样确保设计中大家都follow统一的规则来处理?