We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
在日常的前端项目中,我们经常需要对需求任务进行功能点Task分解,分解Task是为了更合理地进行开发资源分配,也是为了更准确地对项目进行评估和管理。然而如果分配不合理的话,便会带来许许多多的问题,导致开发及管理不畅,甚至会导致项目延期或失败。
我们通常使用什么方式来进行Task分解的呢?作为一个项目的前端负责人,如何进行合理的Task分解并分配给相应的开发?作为业务开发人员,我们该如何安排每天的Task?当在项目中遇到问题时如何抛出问题?
如果没有一个合理且相对统一规范的Task分解,业务开发人员甚至不知道每天需要做什么,遇到问题也感觉无门,而且前端项目管理人员也不好对前端项目的整体进度及状态有个很好地把控,这便给项目带来了风险。
所以,我们需要尽早地建立起适合团队在项目开发中使用的前端Task分解参考,指导着前端团队在项目开发中进行合理且统一的Task分解,让前端项目开发过程更加流畅,让项目的风险降到最低。下面分享的是自己在前端团队中建立的Task分解的一些实践经验。
所有前端项目开发,所有的界面都遵从着结构+表现+行为的三大组成原则。
结构指的是一个界面的整体骨架,从结构中,我们能看到这个界面的所有组件元素,如果是h5项目,那么标签便是界面的结构组成基本单位,如果是react项目,那么等组件便是界面的结构组成基本单位。
表现指的是界面结构的具体样式展现,加上表现,我们便能确定这个界面最终的静态呈现是什么样的,例如设置字体的大小颜色、设置按钮的样式、实现一个动效。
行为指的是这个界面功能动态实现,例如列表的数据请求并渲染、按钮点击事件地响应处理等。
合理分解目的
合理分解原则
不同团队在Task分解上可能存在差异,但应统一保持一些通用原则。
分解方式
前端Task分解参考图
具体的分解方式是为了让前端项目管理者及业务开发者在项目开发中对功能点分解达成一致。分解的粒度要保持适中,不能过粗也不能过细。如果太粗的话,在项目开始前,不利于项目的任务分配,在开发中,不利于观察项目的进度和状态。如果太细的话,则会增大项目管理者及业务开发者对Task的管理成本,反而会影响到具体的开发任务。
按照前端的特性,我是按照一个界面(由结构+表现+行为组成个体)为基本单位来进行Task划分。
1、对一个界面来说,先以界面的静态呈现为一个维度来进行划分,将结构+表现的实现作为一个Task,如果界面有交互效果实现,则将交互效果的实现作为一个Task。
2、然后以界面的行为实现为一个维度来进行划分,将该界面的前端业务功能实现作为一个Task,将接口联调作为一个Task,如果还有第三方依赖,例如跨平台应用开发,需要原生提供相应功能,则将第三方依赖作为一个Task。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
在日常的前端项目中,我们经常需要对需求任务进行功能点Task分解,分解Task是为了更合理地进行开发资源分配,也是为了更准确地对项目进行评估和管理。然而如果分配不合理的话,便会带来许许多多的问题,导致开发及管理不畅,甚至会导致项目延期或失败。
分配不合理导致的问题
我们通常使用什么方式来进行Task分解的呢?作为一个项目的前端负责人,如何进行合理的Task分解并分配给相应的开发?作为业务开发人员,我们该如何安排每天的Task?当在项目中遇到问题时如何抛出问题?
如果没有一个合理且相对统一规范的Task分解,业务开发人员甚至不知道每天需要做什么,遇到问题也感觉无门,而且前端项目管理人员也不好对前端项目的整体进度及状态有个很好地把控,这便给项目带来了风险。
所以,我们需要尽早地建立起适合团队在项目开发中使用的前端Task分解参考,指导着前端团队在项目开发中进行合理且统一的Task分解,让前端项目开发过程更加流畅,让项目的风险降到最低。下面分享的是自己在前端团队中建立的Task分解的一些实践经验。
结构+表现+行为
所有前端项目开发,所有的界面都遵从着结构+表现+行为的三大组成原则。
结构指的是一个界面的整体骨架,从结构中,我们能看到这个界面的所有组件元素,如果是h5项目,那么标签便是界面的结构组成基本单位,如果是react项目,那么等组件便是界面的结构组成基本单位。
表现指的是界面结构的具体样式展现,加上表现,我们便能确定这个界面最终的静态呈现是什么样的,例如设置字体的大小颜色、设置按钮的样式、实现一个动效。
行为指的是这个界面功能动态实现,例如列表的数据请求并渲染、按钮点击事件地响应处理等。
如何合理分解Task?
合理分解目的
合理分解原则
不同团队在Task分解上可能存在差异,但应统一保持一些通用原则。
分解方式
前端Task分解参考图
具体的分解方式是为了让前端项目管理者及业务开发者在项目开发中对功能点分解达成一致。分解的粒度要保持适中,不能过粗也不能过细。如果太粗的话,在项目开始前,不利于项目的任务分配,在开发中,不利于观察项目的进度和状态。如果太细的话,则会增大项目管理者及业务开发者对Task的管理成本,反而会影响到具体的开发任务。
按照前端的特性,我是按照一个界面(由结构+表现+行为组成个体)为基本单位来进行Task划分。
1、对一个界面来说,先以界面的静态呈现为一个维度来进行划分,将结构+表现的实现作为一个Task,如果界面有交互效果实现,则将交互效果的实现作为一个Task。
2、然后以界面的行为实现为一个维度来进行划分,将该界面的前端业务功能实现作为一个Task,将接口联调作为一个Task,如果还有第三方依赖,例如跨平台应用开发,需要原生提供相应功能,则将第三方依赖作为一个Task。
The text was updated successfully, but these errors were encountered: