在开发过程中，很多团队会采用前后端分离架构，用户故事也分成前端开发任务和后端开发任务，问题来了：
①按照前后端拆分开发任务的动因是什么？
②这种拆分任务的方式有何利弊？
③如何避免前后端开发工作量不均衡，“忙的忙死闲的闲死”的问题？”
在传统开发模式中，leader难免会希望招聘full stack的全栈工程师。
在用jsp的时候，公司倡导前后端分开，早期的UI工程师写好html，后端转化为jsp，当出现问题的时候还需要UI去调整，效率低下。
但显然，由于全栈工程师知识体系过于庞杂、不纯粹，反而不能专注的提高，所以前后端分离是职业细分的必然结果。
前后端拆分在技术上是好事，每一块可以更聚焦，不需要混合在一起。
但前后端任务拆分往往看起来容易，但是怎么拆，怎么合，沟通是最大的问题。
由于知识体系和技术栈不同，往往在需求开发过程中，会耗费大量的精力进行沟通。
近年来，程序员前后端分离成为主流，最主要原因还是一个人短时间内很难同时精通这两个领域的技术，导致市场上已经很难找到合格的全栈工程师。
而对于团队来说如何更有利于工作展开才是最重要的，一般情况下在没有合格的全栈工程师的时候，按前后端拆分任务几乎成了唯一选择。
那么基于前后端拆开的动因是什么呢？
首先，用户故事更多交付的是用户价值，根据前后端分开创建子任务可以很好的统一开发的步骤，有助于减少block降低等待，同时成员能力提升相对显著。
说句题外话，团队中的人员需要任务体现自己的工作量，而用户故事拆分后的开发任务会更能明确个人在团队中的工作责任——他可以把某个需求拆分成子任务，进而让不同的开发者能够更好的关注核心功能，进行更有针对的功能开发。
同样，这种拆分任务的方式也会有正反两面：
优势：
- 将用户故事分解为前端任务和后端任务，对于非全栈团队能够在地学习成本时就任务完成；
- 便于不同的开发者领用与自己相关的功能，并及时的更新状态；
- 完成任务时更加专注，只用将精力集中于自己的责任任务中；
- 对前端、后端技能的能力增长会更加快速；
- 符合很多开发团队脑子中拆分方式；
- 符合某些团队的特点。
劣势：
- 子任务往往让同一需求中的其他开发者更倾向于只完成自己的子任务，而不关注其他与其相关、但不会直接处理的任务；
- 可能出现前端写得快，页面都写好了，后端接口可能还没有出来，会存在等接口的情况；
- 可能让前后端人员看待业务实现较片面，不能完整的看待整个业务场景；
- 前后端拆开，同时增加了管理成本和沟通成本，需要持续跟踪依赖；
- 估点时前后端评估标准不同，开发速度不易确定。
在这种前后端拆开的情况下，由于能力不一致，开发工作量可能不均衡时，你应该怎么办？
我给出两个建议：
第一种：长期解决方式
①在开发能力上能够前后端应该可以相互了解，每个人都去尝试既要做前端，也尝试做后端；
②团队能力达到后，可以跟根据实际情况，部分卡不拆分前后端任务；
第二种：短期解决方式
①如果出现空闲的问题，可以在迭代内加入一些并非立即要完成的内容；
如果出现忙的问题，可以根据团队技术能力，做好tasking和技术点讲解后，让前端开发做后端任务，或让后端开发做前端任务。
综上，需要明确某个单一需求的直接负责人、执行人、咨询者、知情人；前后端的衔接应做好接口格式的统一化，尽量把沟通上可能存在的时间延迟提前消除；团队之间建立信任，及时沟通，提升评估准确度。
以上内容整合自【极限编程中国 | 实践者】 微信群今日讨论，内容供参考。
今日内容贡献者
加入【极限编程中国 | 实践者】微信群
和前ThoughtWorks总监咨询师熊节实践敏捷开发
观点
年长的老人还在努力学习新语言，而好多年轻人在抱怨技术太多技术，无法做到掌握太多，那么技术应做到掌握还是精通？
今日分享 
来自【极限编程中国|微信群】@溪源
若有收获，就点个赞吧
0 人点赞
