使用云效公有云版本三个多月，对于任务拆分的一点心得，现在这里分享一下。
任务的定义
任务是从产品到开发到测试一个可以贯穿的概念，在Jira、github 等项目管理软件中，叫做 Issue，Issue 在不同的项目、项目中不同的环节都不太一样。称之为任务的确也没啥太多问题。
开发中过的任务，简单的来说，要完成的一个定义明确的功能项，不依赖内部别的功能，需要的时间根据难易度在两小时到一天左右，且一个人可以独立完成。
我们看到有些项目组的任务会定义为一个人完成的一个大的功能点，可能需要 2-3 天完成，这也是可以的。任务的重要边界是完成本身不依赖其他任务 ( 和定义好的接口通讯不属于此 )。
在开发过程中的任务大部分就是从产品需求而来，
下面这些都可以是一个独立的任务：
- 一个 40 行代码左右的函数
- 一个有三个方法的独立的类的定义和实现
- 一个 3 屏幕高的网页视觉设计
- 5 个表，每个表大约 20 个字段的数据库设计
- 增加一个接口函数
- 为了测试一个接口准备 50 个 test case
- 某种 SAAS 服务的一种功能的接口对接
开发任务的详细设计具体怎么进行，这里就不展开了，因事而异。
任务的基本属性
在云效中新建一个任务会看到下面这些属性，有很多。
建议下面这些属性是必须要输入的，如下图中蓝色框出的：
- 标题
- 描述
- 指派给
- 优先级
- 迭代
- 归属项目
- 版本
- 标签
- 预计工时
- 实际工时
任务标题和描述
任务的标题非常重要，我们建议任务标题按照如下规则来进行：
- 颗粒度一致
- 字数不要太多
- 句式尽量一致
- 不要有歧义
好的任务标题如下：
- 机具底层，回写发卡行脚本
- 刷卡收款，完成交易轮询
- 外部调用，提供获取商户的收款方式接口
- SDK 初始化，完成统一初始化入口
写的不太好的任务标题如下：
- 创建 jsp
- 用户信息查询（商户）
- 控台功能修复-交易查询
- 单笔交易查询接口返回状态优化
推荐使用在以一个项目中： AAA，BBBBB。这样的句式。其中AAA 是某个大模块的名称，一个项目中的模块划分可以由项目经理确认，一般也不会超过5个，如果每个标题中的 AAA 都不太相关，说明颗粒度太细了。这样的描述还有个好处就是视觉上比较整齐。在有的项目中我也会建议 AAA 这里试用新增、修改、删除这样的描述，特别是一些底层的支持类的项目，变化也比较频繁的，可以用这类描述方式。
任务描述是对这个任务的详细描述，可以对这个任务更好的理解。很多程序员不太愿意写文档，经常看到一些程序员详细设计写的简单，项目评审流于形式，有些程序员急于想编码。这样的风险很大，使用尽量标准的项目开发流程可以约束这样的行为。任务的描述并不能替代详细设计，但是也是不可缺少的，因为对任务的标题的字数等有一定要求，不能太啰嗦，所以在描述这里可以尽量将当前任务的内容描述清楚，解决什么问题，可能会碰到的技术问题，包括一些业务和程序流程，甚至是伪代码。
云效系统的描述是支持 Markdown 格式的，所以在表现形式上完全不用担心，可以节约很多排版时间。
任务标签
任务标签也是重要的，对比 jira 这样强大的自定义工作流来说，基于公有云的云效的项目体系相对比较简单，状态有限（私有云版本的云效也可以做比较复杂的定义），至少我们可以通过标签来区分任务的属性。另外目前也是在尝试从产品需求到开发测试的全流程管理，所以用标签可以来区分不同的种类。
任务标签会显示在：
- 迭代管理的任务项
- 任务管理的任务项
- 任务明细页
我们建议在开发项目的时候用下面这些标签，标签在一个项目或者最好在一个公司的所有项目中，保持一致，标签不要颗粒度太小：
- 数据库
- 控台
- server
- api
- h5
- app
任务的完成时间
任务的属性中有一个任务时间，有如下建议：
- 一般情况下，不要小于两小时，或者大于三天，这个和前面说的任务的分拆原则要一致
- 一天按照六小时有效开发时间计算，如果是加班的话，可以增加三小时左右；时间不要排的太满，因为一天之中总会有些开会、电子邮件回复、各种局部讨论等，时间排得太满，会影响项目进度控制
拆分任务的颗粒度一致性
分拆任务时候并不是颗粒度越小越好，在一个项目中，注意颗粒度的一致性非常重要。
在一个纯开发的项目里，可以把任务分拆成都是需要 20-80 行代码实现，按照一个函数一个类为最小颗粒度，也可以是按照源文件，比如所有的基于一个源文件的增加修改代码，还可以按照产品功能点来拆分，或许一个功能点也会涉及到好几个源文件，这种拆法在有些项目中也会有好处。
相对来说，建议按照下面方式来拆分：
- 按照技术的详细设计的功能划分，基本基于单个文件的修改，由一个人完成
- 更细颗粒度的，可以按照一个函数的拆分
任务颗粒度和合并代码的复杂度
对于目前大部分项目基于版本代码分支的管理来说，任务的颗粒度到一个源文件，在代码合并时候比较容易，相对冲突会比较少。
如果任务影响到几个文件，并且这几个文件同时也被别人编辑的话，我们是推荐使用 git ，并进行每日合并，这样包括代码评审的过程一并进行，这部分在 git flow 流程中进行详细解释。
任务的生命周期
任务从建立开始，有一个生命周期，并且任务在这个生命周期里面，内容是可以修改的，有些属性是可以变化的。这也是我们强烈推荐使用系统来进行任务管理的原因之一，要达到同样的效果，可以减少大量的人工工作量。
任务的生命周期分为：
- 待处理
- 处理中
- 已完成
- 已取消
在看板中，可以通过拖放来调整任务所处的生命周期，并且云效工具支持对看板进行配置。
看板
看板管理是一个从工业管理中移植过来的管理名词：
来自于维基百科的定义：看板管理，常作“Kanban管理”（来自日语“看板”，カンバン，日语罗马拼写：Kanban），是丰田生产模式中的重要概念，指为了达到及时生产（JIT）方式控制现场生产流程的工具。及时生产方式中的拉式生产系统可以使信息的流程缩短，并配合定量、固定装货容器等方式，而使生产过程中的物料流动顺畅。
在看板标示系统中常将塑料或纸制成薄板，将产品名称及数量写于其上，故此得名。及时生产方式的看板在生产线上分为两类：领取看板和生产看板，旨在传达的信息是：“何物，何时，生产多少数量，以何方式生产、搬运”。
敏捷中的看板管理大家都熟悉了，现在已经不需要小贴纸在白板上了。非常建议使用本文中的看板模式，虽然看板模式从显示信息数量来说并不太有效率，但是对于产品经理、项目经理等来说，对于进度的控制的一目了然是最重要的。
图表
图表可以给团队和管理层提供一个可视化工具，有助于定义过程中的障碍，并且让每个人持续关注交付有价值的产品。
图表的作用：
- 信息传递可视化
- 真实反映（或者至少部分反映）团队正在进行的过程
- 描述工作过程的情况
- 用于控制工作过程
- 任何人均可查看
任务的评论功能
我们觉得这是现代项目管理软件非常有特色一个地方，不管是 jira、github 以及云效，都可以很容易的进行对任务的评论。有时候我们在详细设计的时候，并不能真正的考虑周全，或者因为时间的关系，有些内容先简单的写一下。项目开发的组长、其他开发人员、在准备测试的测试同事以及产品经理，都可以在一个任务下面进行评论，提出自己的问题。开发人员可以在这个小小的讨论区进行针对性的讨论。我们称这样的过程可以看到一些变化的过程，对于项目后期评审以及其他新加入项目组的同事学习有很大的好处，你看到的不光是结果，还有所有相关人讨论的过程。
云效的任务评论功能可以像微信等，用@符号在评论中指定需要额外看到的人，除了任务的创建者以外。并且通过邮件来发送到和这个任务相关的同事。
任务拆分的注意事项
不要把任务拆分为：立项、详细设计、开发、测试等这样，这是项目的流程环节，而不是项目中的任务。
需求中的任务可以是任务的功能，有点像我们平时说的 feature list 中的项目。
开发中的任务就是技术的详细设计的拆分，有些比如时序图等文档可以以附件形式存放。
每个任务有一个 ID，就像是 Issue number，这是一个唯一的 ID。
需求池管理
在敏捷开发中，我们称之为 Backlog，我们观察到，大部分项目其实开发总是来不及在指定的版本完成的，而需求每天会因为各种情况层出不穷，所以需要一个需求池来存放这些不能马上开发的需求。
需求池中的需求的走向：
- 因为紧急程度，成为目前版本中需要开发的需求；这样的话，需要重新评估需求影响、开发、测试等细节，这也是会造成项目延误的原因；
- 需求池中的需求最好的走向是成为之后上线版本的需求，这样既不影响这个版本的开发，也可以让各方面同事对整个项目有更好的理解，比如为某些优化、某些分级在设计数据表、设计类结构等的时候留好足够的余地；
- 需求取消；
- 需求合并，不管是产品需求、功能优化等都可以在需求池中先列出来，然后产品经理、项目经理等经常检查审视的话，就可以进行一些合并，抽象出一些共通的内容等，所以这也是我们一直觉得要有一个需求池的好处；
既然是需求池，所以其中的任务可以是比较简单的，前面说过，在任务的标题这里需要说明清楚，但是具体的详细设计、关联影响等可以暂且省略。
