浅谈项目经理在敏捷开发中如何切分任务

敏捷开发这个概念也出现好几年了，我一直没有实践，除了知道敏捷开发是一种迭代式交付模型以外，其他一无所知。刚好公司来了一位新同事，以前是搞敏捷开发的，前几天给我们做了个《敏捷开发初探》培训，引发了公司的几位“大牛”对敏捷开发的讨论，我也从中学到一些东西，但仍然很粗浅。

?

传统的瀑布式模型VS迭代式模型

可以看到，迭代式模型就是多次交付，每次迭代都是一个小瀑布。

?

敏捷宣言：

敏捷开发团队的工作环境：

?

可以看出，团队之间的交流是比较频繁的，而且迭代式交付，意味着需要团队成员共同完成一个功能模块，再接着共同完成另一个功能模块。

?

那么作为项目经理，如何切分任务，如何保证团队之间的协同呢？

传统的瀑布式模型中，通常来说任务切分是按功能模块切分的，张三完成功能1，李四完成功能2，王五完成功能3....，最后组装，完成项目。而在敏捷开发中，需要张三李四王五共同完成功能1，然后再共同完成功能2...，这种情况下，可以按层来切分任务，一人做页面，一人写逻辑，一人写数据库存储。这样就能有效的把组员利用起来，让他们都有事做。

?

以上说的是3、4个人的小团队的情况，如果是十几人甚至几十的团队，不可能几十号人去完成一个功能，可以把他们分为3、4个人的若干小组，每个小组按上述办法去完成功能模块。

?

最后申明一下，关于任务切分办法不是我想出来的，是一位“大牛”说的，我认为很有道理，希望以后有机会能够实践一下。

另外哪位同学有敏捷开发经验的，欢迎来谈谈自己的看法。

我再补充一点:
1,小版本release.
2,tdd(这点,我觉得比较难) 19 楼 君淋天下 2010-03-29 大家对敏捷开发有兴趣，对如何实施scrum有兴趣 可以参考这里
http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches
我们项目70%是按照那篇文档实施 20 楼 wuhoufeng 2010-03-30 根据我对敏捷的一点了解，这种方式是要有很多必要前提条件，如果不具备，实施起来的话很难成功。有开发经验的人员用起来的可能行比较大，对于本来就过程不完整，水平不高的团队来说这个没用。如果人数多了以后，对管理人员的能力要求会比较高。 21 楼 orcl_zhang 2010-03-30 君淋天下 写道大家对敏捷开发有兴趣，对如何实施scrum有兴趣 可以参考这里
http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches
我们项目70%是按照那篇文档实施
这本书确实不错.没有多废口舌的理论,看着有劲,还实在.
22 楼 ccxw1983 2010-04-13 敏捷敏捷，字面意思就是快速响应，如果是这样，那么核心的东西应该是沟通的效率＋开发的效率，应该从团队建设、工作方式、工作能力、业务培训……多方面下手了。
而不是盲目的结对编程…… 23 楼 zyeming 2010-04-13 同问。一直在想如何切分任务最合适，但一直都没有发现比较好的办法。按层划分个人认为是不太合适的，因为在开发前期很难确定各层直接的接口，开发过程中就会有很多无效的交流和返工。

当然如果能把每个Story划分到足够小，那是最好的，但有时候很难做到这一点。不过总的来说，纵向的划分，即使是把一个模块的里不同的页面（比如查看页面和编辑页面）划分成两个任务，也比按层划分好很多。不知道有没有高手有更好的办法？？

另外，硝烟中的Scrum和XP的确是个好东西啊~~ 24 楼 zyeming 2010-04-18 mock1234 写道
其实开发前期在概要设计时对层次、接口作出描述甚至论证还是完全可能的，甚至经常是必要的，许多做过大项目的人都已经养成了这个习惯，所以并不是真的很沉重的事情。

的确是可能啦，但我还真不觉得必要，至少在大部分项目中。我工作的前两个公司做的都算大项目，特别是第一家日企，每次开发都会有密密麻麻的一堆概要设计、功能设计、详细设计等等，然后每次都陷入维护代码文档同步的无穷无尽的深渊……

mock1234 写道
而如何将Story变得足够准确，你觉得很难。这也就是为什么一些人回复说“要注重测试驱动技术”的原因。因为只有那些习惯了高强度的测试驱动开发的人，很自然地“仅凭触觉”就能写出非常讲究“不做不必要的事情”的TDD代码。因为他们凡是做计划必用可执行的TDD来写，于是不存在忽悠的成分（否则一旦到了计划日期那么TDD测试程序就会每隔10分钟就“抛出异常的bug”），而是自然而然地不断追求实际应用中的设计模式。

这个建议很不错。

mock1234 写道
我给一个我“发明”的标准：每个任务只有1小时的任务量，更粗糙的任务描述肯定是无法迅速写出测试用例和测试程序的；每个人（假设一天工作8小时）每天只预先安排30%的时间用于工作，而70%用于机动。

我倒是很想请教一下这个标准，至少从我的直觉来看，1小时的任务划分也太细了。能不能稍详细点说说怎么个弄法的？ 25 楼 ucetgg 2010-06-17 楼主谈敏捷完全不提测试 ，不好吧 26 楼 ucetgg 2010-06-17 zyeming 写道mock1234 写道
其实开发前期在概要设计时对层次、接口作出描述甚至论证还是完全可能的，甚至经常是必要的，许多做过大项目的人都已经养成了这个习惯，所以并不是真的很沉重的事情。

的确是可能啦，但我还真不觉得必要，至少在大部分项目中。我工作的前两个公司做的都算大项目，特别是第一家日企，每次开发都会有密密麻麻的一堆概要设计、功能设计、详细设计等等，然后每次都陷入维护代码文档同步的无穷无尽的深渊……

mock1234 写道
而如何将Story变得足够准确，你觉得很难。这也就是为什么一些人回复说“要注重测试驱动技术”的原因。因为只有那些习惯了高强度的测试驱动开发的人，很自然地“仅凭触觉”就能写出非常讲究“不做不必要的事情”的TDD代码。因为他们凡是做计划必用可执行的TDD来写，于是不存在忽悠的成分（否则一旦到了计划日期那么TDD测试程序就会每隔10分钟就“抛出异常的bug”），而是自然而然地不断追求实际应用中的设计模式。

这个建议很不错。

mock1234 写道
我给一个我“发明”的标准：每个任务只有1小时的任务量，更粗糙的任务描述肯定是无法迅速写出测试用例和测试程序的；每个人（假设一天工作8小时）每天只预先安排30%的时间用于工作，而70%用于机动。

我倒是很想请教一下这个标准，至少从我的直觉来看，1小时的任务划分也太细了。能不能稍详细点说说怎么个弄法的？
Test-Driven Development（测试驱动开发）：它是敏捷开发的最重要的部分。在ThoughtWorks，实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的Story，记录在Story Card上。然后两个人同时坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。