这号怎么样，我想我敏捷太低了_百度知道浅谈项目经理在敏捷开发中怎么切分任务 - 敏捷开发当前位置:& &&&浅谈项目经理在敏捷开发中怎么切分任务浅谈项目经理在敏捷开发中怎么切分任务&&网友分享于：&&浏览：60次浅谈项目经理在敏捷开发中如何切分任务
敏捷开发这个概念也出现好几年了，我一直没有实践，除了知道敏捷开发是一种迭代式交付模型以外，其他一无所知。刚好公司来了一位新同事，以前是搞敏捷开发的，前几天给我们做了个《敏捷开发初探》培训，引发了公司的几位“大牛”对敏捷开发的讨论，我也从中学到一些东西，但仍然很粗浅。
传统的瀑布式模型VS迭代式模型
可以看到，迭代式模型就是多次交付，每次迭代都是一个小瀑布。
敏捷宣言：
敏捷开发团队的工作环境：
可以看出，团队之间的交流是比较频繁的，而且迭代式交付，意味着需要团队成员共同完成一个功能模块，再接着共同完成另一个功能模块。
那么作为项目经理，如何切分任务，如何保证团队之间的协同呢？
传统的瀑布式模型中，通常来说任务切分是按功能模块切分的，张三完成功能1，李四完成功能2，王五完成功能3....，最后组装，完成项目。而在敏捷开发中，需要张三李四王五共同完成功能1，然后再共同完成功能2...，这种情况下，可以按层来切分任务，一人做页面，一人写逻辑，一人写数据库存储。这样就能有效的把组员利用起来，让他们都有事做。
以上说的是3、4个人的小团队的情况，如果是十几人甚至几十的团队，不可能几十号人去完成一个功能，可以把他们分为3、4个人的若干小组，每个小组按上述办法去完成功能模块。
最后申明一下，关于任务切分办法不是我想出来的，是一位“大牛”说的，我认为很有道理，希望以后有机会能够实践一下。
另外哪位同学有敏捷开发经验的，欢迎来谈谈自己的看法。
ttion 写道敏捷开发，任务切分(可以称为Story的划分)，以站在客户的角度上来划分故事点，另外一个故事点他应该是完整的，依赖性较小，可测的，而不是“，一人做页面，一人写逻辑，一人写数据库存储。”。在敏捷开发当中有一个实践是“客户签收”可以由测试代替，如果根据LZ的说法，那么做出来的Story根本不可测，如何签收？如何做到测试先行？感谢这位同学，我又学到一个名词，story。不过我理解所谓的故事点相当于我文中说的功能，我所说的任务切分是在划分好story以后的任务分派，这两点似乎并不冲突。TDD大概是敏捷开发中常用的一种方法（我不知道是不是必需的），我理解方法不过是实现目标的一种手段，是不是一定要用，在什么场景下用，怎么用，都要看具体情况，不能生搬硬套。不知道我理解的对不对？欢迎拍砖。抱歉，我把任务理解为一个需求了，如果是任务的话，我也觉得没必要采用“大牛”说的方式，可以采用结对的方式，思维碰撞，保证代码的质量，以及知识共享。
TDD != 敏捷，只是敏捷的一部分；功能 != Story，Story只是功能的一部分；Story是可测的，对用户有价值的最小功能块。所以按照你的“一人做页面，一人写逻辑，一人写数据库存储”完全是错误的。另外，关于结对编程，这要看公司的现状。只要交流的好。。。。我实践过。两个人一周重写了五个人三周的活(包括前面二个人)PS：那些统计用的SQL太变态了。后来用于表现层的抽象又太复杂了。
没有合适的测试方式分工免谈现在做的项目好像就是像楼主说的切分小组，有几个组长完成几个模块。但是却连测试人员都没有，结果项目上线后bug一大堆，客户怨天载道。
我确实没试过，所在在这里向大家取经了，呵呵。前面有人说结对，在培训中老师也提到过，我感觉结对有可能会提高效率，提高代码质量，但是也会使队员在一种高度紧张的状态下工作，也许是我传统或是散漫惯了，还不太适应这种工作方式。结对在国外也许有许多成功案例，在国内有吗？知道的请透露一二。补充一下，请问结对的副作用是什么？有什么办法消除？想尽办法把重复的事去掉的话。结对想实现以前的最佳实践别结。忍不住想改。
那么作为项目经理，如何切分任务，如何保证团队之间的协同呢？传统的瀑布式模型中，通常来说任务切分是按功能模块切分的，张三完成功能1，李四完成功能2，王五完成功能3....，最后组装，完成项目。而在敏捷开发中，需要张三李四王五共同完成功能1，然后再共同完成功能2...，这种情况下，可以按层来切分任务，一人做页面，一人写逻辑，一人写数据库存储。这样就能有效的把组员利用起来，让他们都有事做。这个有点无语.....难道楼主的敏捷就是这个样子..按照模块划分和按照层次划分,是这两个的区别么?魔力猫咪 写道以Scrum为例。产品负责人这个角色提出团队要完成的功能列表，并列出优先级。这个功能列表也称作一系列故事。每个故事都是预估可以在一个迭代周期内由一个人或者结对组完成的、可测试的完整的功能模块。如果不能，则继续***。一定要注意的是这些故事的描述是基于业务的，而不是莫名其妙的如在某表上加个属性之类的要求。因为加属性之类的要求无法反映业务需求。在每个spint的启动会议上，产品负责人向团队讲解这些故事，按照优先级挑选本次spint要完成的故事。挑选完成本次spint的故事后，这些故事一般由团队成员按照自己兴趣选择。也就是大家优先挑选自己最感兴趣的故事，而不是由某个人强制分配。如果有大家都不敢兴趣的，协商解决。很明显的是楼主的思想并没有转换成为敏捷团队思想。还是原来的领导做派。敏捷要求的是团队的自管理。项目经理应该是引导团队和协助团队，不是命令团队。说到点子上了,我给分成几条:1,功能列表(故事).属性:优先级,estimate,可测.2,spint.3,敏捷要求的是团队的自管理. 我再补充一点:1,小版本release.2,tdd(这点,我觉得比较难)
大家对敏捷开发有兴趣，对如何实施scrum有兴趣 可以参考这里q.com/cn/minibooks/scrum-xp-from-the-trenches我们项目70%是按照那篇文档实施这本书确实不错.没有多废口舌的理论,看着有劲,还实在.
其实开发前期在概要设计时对层次、接口作出描述甚至论证还是完全可能的，甚至经常是必要的，许多做过大项目的人都已经养成了这个习惯，所以并不是真的很沉重的事情。的确是可能啦，但我还真不觉得必要，至少在大部分项目中。我工作的前两个公司做的都算大项目，特别是第一家日企，每次开发都会有密密麻麻的一堆概要设计、功能设计、详细设计等等，然后每次都陷入维护代码文档同步的无穷无尽的深渊……mock1234 写道而如何将Story变得足够准确，你觉得很难。这也就是为什么一些人回复说“要注重测试驱动技术”的原因。因为只有那些习惯了高强度的测试驱动开发的人，很自然地“仅凭触觉”就能写出非常讲究“不做不必要的事情”的TDD代码。因为他们凡是做计划必用可执行的TDD来写，于是不存在忽悠的成分（否则一旦到了计划日期那么TDD测试程序就会每隔10分钟就“抛出异常的bug”），而是自然而然地不断追求实际应用中的设计模式。这个建议很不错。mock1234 写道我给一个我“发明”的标准：每个任务只有1小时的任务量，更粗糙的任务描述肯定是无法迅速写出测试用例和测试程序的；每个人（假设一天工作8小时）每天只预先安排30%的时间用于工作，而70%用于机动。 我倒是很想请教一下这个标准，至少从我的直觉来看，1小时的任务划分也太细了。能不能稍详细点说说怎么个弄法的？
mock1234 写道其实开发前期在概要设计时对层次、接口作出描述甚至论证还是完全可能的，甚至经常是必要的，许多做过大项目的人都已经养成了这个习惯，所以并不是真的很沉重的事情。的确是可能啦，但我还真不觉得必要，至少在大部分项目中。我工作的前两个公司做的都算大项目，特别是第一家日企，每次开发都会有密密麻麻的一堆概要设计、功能设计、详细设计等等，然后每次都陷入维护代码文档同步的无穷无尽的深渊……mock1234 写道而如何将Story变得足够准确，你觉得很难。这也就是为什么一些人回复说“要注重测试驱动技术”的原因。因为只有那些习惯了高强度的测试驱动开发的人，很自然地“仅凭触觉”就能写出非常讲究“不做不必要的事情”的TDD代码。因为他们凡是做计划必用可执行的TDD来写，于是不存在忽悠的成分（否则一旦到了计划日期那么TDD测试程序就会每隔10分钟就“抛出异常的bug”），而是自然而然地不断追求实际应用中的设计模式。这个建议很不错。mock1234 写道我给一个我“发明”的标准：每个任务只有1小时的任务量，更粗糙的任务描述肯定是无法迅速写出测试用例和测试程序的；每个人（假设一天工作8小时）每天只预先安排30%的时间用于工作，而70%用于机动。 我倒是很想请教一下这个标准，至少从我的直觉来看，1小时的任务划分也太细了。能不能稍详细点说说怎么个弄法的？Test-Driven Development（测试驱动开发）：它是敏捷开发的最重要的部分。在ThoughtWorks，实现任何一个功能都是从测试开始，首先对业务需求进行分析，***为一个一个的Story，记录在Story Card上。然后两个人同时坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 12345678910 Copyright & &&版权所有您的举报已经提交成功，我们将尽快处理，谢谢！
一开始选择精灵，战士。一转的时候转巡守；二转的时候转银月游侠。这样你的敏捷跟同等级的比就最高了。
大家还关注