前端如何更精准的评估开发时间

分配不合理导致的问题

• 不好进行任务分配
• 不好对前端项目有个整体进度及风险把控
• 开发不好对具体点的实现聚焦
• 相关依赖遇到风险时，前端的开发也受到阻塞
• 前端项目出现风险时，不好进行资源调配来解决风险

我们通常使用什么方式来进行Task分解的呢？作为一个项目的前端负责人，如何进行合理的Task分解并分配给相应的开发？作为业务开发人员，我们该如何安排每天的Task？当在项目中遇到问题时如何抛出问题？

如果没有一个合理且相对统一规范的Task分解，业务开发人员甚至不知道每天需要做什么，遇到问题也感觉无门，而且前端项目管理人员也不好对前端项目的整体进度及状态有个很好地把控，这便给项目带来了风险。

所以，我们需要尽早地建立起适合团队在项目开发中使用的前端Task分解参考，指导着前端团队在项目开发中进行合理且统一的Task分解，让前端项目开发过程更加流畅，让项目的风险降到最低。下面分享的是自己在前端团队中建立的Task分解的一些实践经验。

结构+表现+行为

所有前端项目开发，所有的界面都遵从着结构+表现+行为的三大组成原则。

结构指的是一个界面的整体骨架，从结构中，我们能看到这个界面的所有组件元素，如果是h5项目，那么标签便是界面的结构组成基本单位，如果是react项目，那么等组件便是界面的结构组成基本单位。

表现指的是界面结构的具体样式展现，加上表现，我们便能确定这个界面最终的静态呈现是什么样的，例如设置字体的大小颜色、设置按钮的样式、实现一个动效。

行为指的是这个界面功能动态实现，例如列表的数据请求并渲染、按钮点击事件地响应处理等。

如何合理分解Task？

合理分解目的

• 有利于任务的分配，让不同的开发人员负责各自擅长的事，优化资源利用
• 有利于前端项目的整体进度及风险把控
• 让开发人员在开发的时候更聚焦，不会东做一点西做一点
• 当遇到依赖不能及时提供时，可以暂时搁置，不影响其他Task的开发
• 当前端项目出现风险时，协调资源，分担Task，解决项目风险

合理分解原则

不同团队在Task分解上可能存在差异，但应统一保持一些通用原则。

• 以界面作为基本单位
• 遵从结构+表现+行为的原则
• 保持对前端开发中的其他依赖进行解耦

分解方式

前端Task分解参考图

具体的分解方式是为了让前端项目管理者及业务开发者在项目开发中对功能点分解达成一致。分解的粒度要保持适中，不能过粗也不能过细。如果太粗的话，在项目开始前，不利于项目的任务分配，在开发中，不利于观察项目的进度和状态。如果太细的话，则会增大项目管理者及业务开发者对Task的管理成本，反而会影响到具体的开发任务。

按照前端的特性，我是按照一个界面（由结构+表现+行为组成个体）为基本单位来进行Task划分。

1、对一个界面来说，先以界面的静态呈现为一个维度来进行划分，将结构+表现的实现作为一个Task，如果界面有交互效果实现，则将交互效果的实现作为一个Task。

2、然后以界面的行为实现为一个维度来进行划分，将该界面的前端业务功能实现作为一个Task，将接口联调作为一个Task，如果还有第三方依赖，例如跨平台应用开发，需要原生提供相应功能，则将第三方依赖作为一个Task。

实际案例

项目需求

实现豆果美食学烘焙中的精华模块。包含三个界面，精华文章列表界面，发帖界面和文章详情界面。

UI设计图

Task分解

将精华模块按照如下方式分解后，并进行对应Task的开发评估。

精华模块Task分解图

精华模块包含三个界面，分别对三个界面进行Task分解，下面对精华文章列表页的分解进行详细解释。

对于精华文章列表页，按照界面展现来分解，可以将精华文章整体界面结构+表现实现作为一个Task，可以分配给擅长UI绘制的人员，评估开发时间为1人天。

将精华文章动效处理-列表滑动控制界面元素作为一个Task，让开发人员对动效的处理更聚焦且用心，评估开发时间为0.5人天。

将文章列表页的业务功能实现作为一个Task，业务功能实现可以分配给另外的人来做，评估开发时间为1人天。

将列表页的接口联调作为一个Task，当接口不支持联调时，Task则转化成问题，放入问题列表中进行跟踪，评估时间为0.5人天。

将看大图功能调用作为一个Task，假设列表页的实现是通过跨平台技术（rn、weex）来实现，看大图功能由原生提供，同样，如果原生不能按时提供，同样也作为问题放入问题列表中由前端项目管理者统一监控。

结语

由上可看出，Task的划分合理起到的作用还是很大的。既有利于资源的合理分配，又能提高项目开发中的规范流程，而且还有利于前端项目的管理。当在团队中推行Task分解规范的时候，最重要的还是要基于自己团队，要与团队成员进行充分沟通和指导，一起高效地完成前端项目任务。