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

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

 

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

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

 

敏捷宣言：

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

 

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

 

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

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

 

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

 

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

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

没有合适的测试方式分工免谈

小项目（大项目我不知道） 这样子分工确实效率高些，而且代码风格在同一层面也比较同一，瀑布还是敏捷和这种分工方式没啥关系。

但是需要好的文档 定义接口/概念/命名规则===

否则也很恶心

敏捷开发，任务切分(可以称为Story的划分)，以站在客户的角度上来划分故事点，另外一个故事点他应该是完整的，依赖性较小，可测的，而不是“，一人做页面，一人写逻辑，一人写数据库存储。”。在敏捷开发当中有一个实践是“客户签收”可以由测试代替，如果根据LZ的说法，那么做出来的Story根本不可测，如何签收？如何做到测试先行？

感谢这位同学，我又学到一个名词，story。
不过我理解所谓的故事点相当于我文中说的功能，我所说的任务切分是在划分好story以后的任务分派，这两点似乎并不冲突。
TDD大概是敏捷开发中常用的一种方法（我不知道是不是必需的），我理解方法不过是实现目标的一种手段，是不是一定要用，在什么场景下用，怎么用，都要看具体情况，不能生搬硬套。
不知道我理解的对不对？欢迎拍砖。

楼主说的是任务划分的方法，与可测试性又有什么关系呢？不解

抱歉，我把任务理解为一个需求了，如果是任务的话，我也觉得没必要采用“大牛”说的方式，可以采用结对的方式，思维碰撞，保证代码的质量，以及知识共享。

TDD != 敏捷，只是敏捷的一部分；
功能 != Story，Story只是功能的一部分；
Story是可测的，对用户有价值的最小功能块。
所以按照你的“一人做页面，一人写逻辑，一人写数据库存储”完全是错误的。
另外，关于结对编程，这要看公司的现状。

只要交流的好。。。。
我实践过。
两个人一周重写了
五个人三周的活
(包括前面二个人)
PS：那些统计用的SQL太变态了。
后来用于表现层的抽象又太复杂了。