摘要：
那用户故事的任务分解和分层开发有什么关系呢？这时就会出现一个问题，即使在系统设计的时候严格规定UI层，领域逻辑层，基础设施层，数据访问层以及应用服务层要严格的分开，但在实际操作的时候，有些人为了赶进度，有些人不想太麻烦，有些人可能是水平达不到，做出来的东西并没有按照这种既定的分层去做。
用户故事是什么呢？用户故事是敏捷开发中，为了和用户交流需求方便而出现的。他站在用户的角度以用户可理解的文字来描述需求。
任务就是为了完成一个用户故事，系统开发和设计人员会把用户故事分解成几个任务，然后把这些任务分配给某些人，让这些人去完成这些任务，进而实现整个用户故事。当然这涉及到一些同步协作的问题。
系统的分层开发相信大家都不陌生，当我拿到一个业务系统的项目时，首先我会使用领域驱动开发模式，然后使用DDD分层，使用分层可以大大降低系统的复杂度。
那用户故事的任务分解和分层开发有什么关系呢？
第一，我们先看一下我们在系统分层的时候一般都会遇到哪些问题。
传统的开发基本上都是以功能块来划分的。例如A负责用户管理模块，B负责日志管理模块。C负责重大项目管理模块。这时就会出现一个问题，即使在系统设计的时候严格规定UI层，领域逻辑层，基础设施层，数据访问层以及应用服务层要严格的分开，但在实际操作的时候，有些人为了赶进度，有些人不想太麻烦，有些人可能是水平达不到，做出来的东西并没有按照这种既定的分层去做。最明显的也是新手最容易犯的错误就是UI层上有太多的领域逻辑的代码，并且里面很多的If判断。
而且这样也不利用充分利用各个人的特长，每个人都在做覆盖全部知识点，但却只是一小部分的工作。而且不便于各个成员之间的交流。除非各个模块之间有交互时，他们才会在一起讨论问题。
第二，让我们再看一下用户故事的任务分解。
例如，有一个用户故事，作为超级管理员，可以批量删除指定日志范围内的日志，以便当系统长时间使用时，可以清理掉时间较长的意义不大的日志。当然这个用户故事比较简单。
我们在分解任务的时候可能分解成以下任务
任务1：在数据访问层，LogDAO类中添加根据日期段，批量从数据库中删除日志。DeleteLogs（DateTime pStartDate，DateTime pEndDate）。
任务2：在业务领域层，LogProvider类中添加相关删除Log的业务逻辑。
任务3：添加批量删除日志的UI，要求有输入开始和结束时间，有确定和取消按钮。
任务3：添加批量删除日志的UI，要求有输入开始和结束时间，有确定和取消按钮。
任务4：把批量删除功能添加到系统菜单中，并和用户权限挂钩。
这样我们至少可以把任务1和任务2分给一个成员，把任务3和任务4分给另一个成员。基本上分配任务的时候，基本上每个任务都不会跨层次，单个任务都会在单个层上实现，而且每个任务都由不同的人实现。即使这些任务都是由一个人实现，也得一个个实现，这样也避免了“偷懒”，或是水平有限而导致层次混乱不清的导致的系统质量问题。
而在敏捷开发的Scrum过程中，用户故事的估算和任务分解一般都是和团队成员在一起完成的，如果在高级开发人员的帮助下，可能把所有的用户故事都能按照系统分层设置好。这样对系统的系统是一个很好的保证。
而在敏捷开发的Scrum过程中，用户故事的估算和任务分解一般都是和团队成员在一起完成的，如果在高级开发人员的帮助下，可能把所有的用户故事都能按照系统分层设置好。这样对系统的系统是一个很好的保证。