在Scrum中，任务细分有几个必须要遵守的基本原则：
1、 子任务必须小于5小时
主要是为了每天都能看到进展。
2、 子任务必须是可检视的
对所有人都要可检视，包括不懂开发的人。
3、 子任务间必须相对完整独立
即完成1个后，可以选择延期或放弃下1个任务；完成的步骤是逐个逐个完成的。
4、 多个子任务要进行排序，要区分轻重缓急
先做必需的功能特性，然后再做其他高级特性
基本原则看起来很就简单，但是很多开发人员细分任务时，还是很难准确把握。1、4两个原则很容易懂，不用过多解释。对于难于把握2、3两个基本原则，本文将逐个来分析，帮助大家很好的理解它们、运用它们。
一、如何做到任务可检视
开发人员习惯于从开发的视角细分任务，很多时候会出现细分后的任务是不可检视的。
类似下列的任务，不懂技术的人基本无法检视。就算是开发人员，如果没有详细阅读代码，也不知道到底完成没有。这种情况应该尽量避免：&
1）&完成xx框架
2）&完成xx公共类
3）&完成xx逻辑
举例说明：任务细分实例1
&“报损单逻辑”这个任务项，明显是不可检视的。你说你做完了，如何展现，我从哪里看的出来，又怎么检查？
按照对最终用户可见的功能或功能特性来划分来看能否解决问题：
报损单统计基本查询（条件，查询结果）& 4小时
报损单统计列表功能&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& & 2小时
报损单统计明细账本功能&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& & 1小时
报溢单统计&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& & 1小时
调拨单统计基本查询&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &4小时
调拨单统计列表功能&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& & 2小时
调拨单统计明细账本功能&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& & 1小时
这样的划分的好处，所有人都知道子任务的实现目标，也很好验证你是否完成了。&
特别提醒一点：因为使用的是业务上的通用语言，不管是开发、还是测试，甚至客户都能很好的沟通。&
二、为什么要做到任务相对完整独立、如何做到
任务相对完整独立的好处分析
1、就拿修改后的实例1做法来说，各个任务相对独立，我们随时都有一个接近交付的程序。因为如果有时间问题，我们完全可以在本次发版中舍弃高级功能，马上就能进入测试。
2、如果子任务间无法做到相对独立就不可能做到这一点，比如必须完成3个子任务，才能拼成一个可交付的功能。除了不能灵活的放弃某些高级功能外，还需要面对的是很长时间都看不到实际可运行的结果，这样会加大出现偏差的风险。
在实例1中，界面和逻辑的细分法，实际上就是没有做到相对完整独立。它们各自不是完整功能，更谈不上独立。按照功能特性重新细分后，就满足了相对完整独立的要求。比如，我们做完报损单的基本查询后，发现没有时间了，这时完全可以不做后面的。
这个例子中没有做到完整独立很清楚，但是实际上还有另外一种形式也会影响任务的完整独立性：
一个人手中有多个任务，任务的划分也很合理（可检视、相对完整独立、有排序、小于5小时），但是他在开发的时候因为几个任务都是改同一个模块，就把几个任务同时进行了。这种情况实际上是实现层面上的没有分开，开发人员把它们当做是一个任务了。既然没分开，那么上面的好处自然就没有了。
几个任务同时进行的实例：
三、从上面分析中抽出三个附加执行原则
1、按照对最终用户可见的功能或功能特性来细分
2、使用业务通用性语言来描述，便于沟通
3、一个人同一时间只进行一个任务。
目标就是要达到：可检视、相对完整独立、有排序、小于5小时
本文已收录于以下专栏：
相关文章推荐
原创文章，如有转载，请注明出处：http://blog.csdn.net/yihui823/article/details/6778351
记得自己第一次当PM。那是接手的项目，原来的PM，在项目需...
最近把之前学习 Scrum 的资料整理为一篇文档，在接下来的团队和项目开发中，根据项目的情况引入 Scrum 的一些实践，提高团队成员之间的协作能力和项目的交付质量。
        参考资料：...
1.   看板简介
看板管理，常作Kanban管理（来自日语“看板”，カンバン，日语罗马拼写：Kanban），是丰田生产模式中的重要概念，指为了达到JIT(Just in Time, 及时生产)方式控...
首先，把根据sprint历史数据得到的估算，称为 历史数据估算，把commitment之后的估算 称为 承诺估算。
历史数据是以前的定量情况，包括但不限于资源利用率、sprint可以完成的stor...
前两天，有群里的朋友在管理团队开发过程中有一些敏捷方面的疑问，类似如何评估工作量、如何高效的进行早会等问题。今天开一篇敏捷开发相关的文章，说说我对敏捷的理解和实践。
     Scrum 是什么？
...
他的最新文章
讲师：姜飞俊
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)常见项目管理工具介绍
项目管理最重要的内容
谁来撰写以及分配任务
如何有效地分配任务
项目管理工具
在我工作的10多年中，使用过不少的项目管理系统，, , dotProject, , , , , ...。比我谈过的女朋友还多。
这里不讲哪个工具更优秀，只能说应人而异吧。目前市场上用的比较多的有Redmine, Jira等传统老兵，也有类似Teambition,Worktile看板式的新秀。
Redmine是我现在用的项目管理系统。它是基于ROR框架开发的一套免费开源的跨平台项目管理系统，数据可以很方便地存放在本地，插件也算丰富。
Teambition看板风格的界面更为时尚，还有APP方便随时随地查看。
我个人倒是没有深入使用，不知道相应的任务和BUG状态追踪是否好用，比如一个BUG从“新建-&分配-&处理-&已解决-&待验证-&关闭/拒绝”。另外，看板视图的拖来拖去，在状态追踪过程中会不会容易拖错地方。有了解的可以说一下使用的感受。
项目管理最重要的内容是什么？
用什么工具不是最重要的，重要的是要把工具真正用起来。功能再强大的工具你没有用起来，或者太复杂使用的成本太高，那也是白搭！
往往工具越复杂，使用的成本就越高，运用到项目中的机率也越低。
可以选择一个最简单的工具，而不要一上来就整一个“巨无霸”，号称“全宇宙第一”（你有不是Visual Studio!）。
那种全家桶式的工具，除了对日外包之外的公司，我感觉它的管理成本、学习成本应该不低，你们有真正用起来吗，如果有的话，欢迎说下你们的感受。
不少人认为Redmine功能过于简单，我倒是认为Redmine功能还是有点复杂了。如果由我来负责Redmine的产品设计，一上来我就会先砍掉一半的功能。
工具不能成为给领导汇报的形式。这样只会浪费时间，增加毫无意义的管理成本。
无论选择哪个工具，包括如下信息才能算作一款好的项目管理工具：
计划完成日期 该任务计划在哪一天完成。
预期工时 细分后的任务要给出一个合理的预期工时，必须以小时为单位。
实际完成日期 指定的任务实际完成时的日期。
实际工时 该任务完成时实际所耗的工时。
优先级 任务以及BUG都应该有一个优先级，将影响别人的任务优先级设置为更高，避免团队其他成员”Waiting for you“。
其中任务分配时的预期工时必须足够细，越细越好，一般控制在半天之内，最多不超过一天，不过这也增加了管理上的成本。这需要管理者根据自身的研发团队作一个权衡。
我们是如何做的？见下图：
当然如果你们的研发团队是自带鸡血的，总是能完美收工的话，你只需要粗略地将一周的任务安排给他们，那就爽歪歪了。
谁来分配任务
老板让你2个月开发出一个产品，研发吭哧吭哧地搞了2个月，到了第2个月的30号交给老板，老板很开心地打开系统，发现连TM登录都登录不了。
老板心情好的话，可能你会被狠K一顿；心情不好的话，你就得去账务室，结下工资，出门左转...
造成这个问题的原因有两种：
老板催着你必须在2个月内完成。
这个好办，你只要跟老板讲两个字：尽量。如果老板回你两个字：必须！。你有两套方案，先进入疯狂加班模式，到第2个月中，发现还有80%尚未完成，启动Plan B，你该好好更新下简历了！
任务分配者对任务的时间预估偏差太大。
要想项目的分配尽可能地准确，任务分配者必须了解项目研发相关的技术，倒不是要非常熟练，至少有所了解。另外最好工作经验在6年以上。
当然如果这个任务只是用来应付老板的，找过最闲的手下去做就可以了。
每周一开会过一下本周的任务
任务一般在细分后，在周一上午，团队在一起过一下每个人本周所要完成的任务功能点，这样有如下几个好处：
尽快摆脱”星期一综合症“。
让大家了解彼此所做的事情，方便研发过程中的沟通。
了解一下自己本周要完成的任务，看看有哪些可能会遇到的坑，方便自己合理安排时间。
项目任务之间难免会有一些依赖关系。比如后台必须先写好接口，APP才能做获取服务器数据的工作，需要对任务进行优先级上的调整，避免“A等待B的现象”。
不要低估内外部沟通成本
碰上项目需要对外跟客户进行沟通，那你就惨了。客户在软件项目上的智商只有真正打过交道的人才知道！
加上习惯性被忽视的内部沟通成本，产品经理、项目经理、研发经理、研发团队内部...
对了，还有那可恶的销售人员，不知啥时跟客户喝酒时说产品啥功能都有，1个月就可以交付使用。终于知道心中一万只奔腾而过是什么感受了。
还有从来都是被遗忘的产品测试和调试时间，其实这是项目研发过程中耗在这上面的时间是很长的，甚至于超过编码时间。
加上老板有事没事来看望你两眼，总会打断了你的思路。（表示关心，其实是催一下进度，看你有没有混日子，但你还要对老板讲，谢谢老板关心）
不要高估程序员的效率
在我工作的十年中，说来忏愧，记不得哪个项目是真正意思上按时完成的！
什么，你说你们的项目都是按时完成的？我的第一反应会是：这兄弟绝对在逗我！
如果你的工作计划做得很细，以小时为单位的总预期工时非常准，但如果你是按一天8小时算的，不好意思，这个项目一定会延期！而且会延期双倍时间。
你真认为你的程序员们真的像发动机一样，在8小时高速运转吗？基础上99.99%的公司不是（还有0.01%留给你们公司，供你们YY）。
你要说美国FAG？我告诉你那些牛逼的公司更不会是。正常的有效工作时间只有8的一半：3小时！
还有现在所想不到的”不可抗力因素“：程序员恋爱了、失恋了、结婚了、吵架了、怀孕了...；办公室突然断电了、断网了...
要是突然一个重要的程序员生病了，离职了，在老板看来，办法无非两种：（其实这两种办法都不明智）
加班 加班是最不明智的方法，常态的加班只能让程序员效率变低，最终的效率还不如正常下班的带来的效率高。当然项目进度很紧的话，短时间内的加班还是有必要的。
加人 &赶紧招一个补上&。天那！这也不是工厂，招一个新人的成本太高了，这兄弟啥时能上手啊，等上手的时候估计项目已经延期很久了。还要考虑一个老兵带新兵带来的”内耗”。
欢迎点赞！
阅读(...) 评论()分享给朋友：如何做好员工临时性任务的指派下载至电脑扫码用手机看用或微信扫码在手机上继续观看二维码2小时内有效如何做好员工临时性任务的指派扫码用手机继续看用或微信扫码在手机上继续观看二维码2小时内有效，扫码后可分享给好友没有优酷APP？立即下载请根据您的设备选择下载版本
药品服务许可证(京)-经营- 请使用者仔细阅读优酷、、、Copyright(C)2017 优酷
版权所有不良信息举报***: