08月01, 2018

关于团队流程化规范的小总结

这里记录一些团队流程化规范的小总结,个人总结,欢迎大家提意见:

立项

  • 技术选型:分析产品需求,结合团队技术情况分别给出合理的选型方案;纵向比较A、B、C技术方案的优缺点;如果选用新技术,考虑应用新技术的上线风险,分析潜在困难;如果上线风险较高,应给出合理的保底方案,以确保项目正常上线。

  • 项目跟进流程:需求评审(沟通需求细节以及了解需求整体情况)、技术评审(给出需求实现方式以及能否实现和目前存在的潜在问题)、给出排期(排期拆分为具体的模块化计算工作量,以提高排期的准确性)、需求开发、测试case评审(根据需求评审QA同学测试的功能点)、自测(根据case以及自我驱动进行提测前自测)、校对UI、show case(提测前QA同学检查当前项目需求完成情况,case通过率达到90%以上可以提测)、测试跟进(bug整体解决原则是:统一查看统一处理,但是有阻塞测试流程和高优先级的bug时,应优先立即处理)、上线回归测试。

  • 工作流跟进:配合需求的大小迭代,进行流程化跟进。一般会拆分到jira中,大版本迭代根据迭代拆分为小迭代,每个jira中记录:需求文档(wiki)、需求排期(邮件 & wiki)、相关开发人员、相关测试人员、目前流转节点。

  • 文档跟进:基础工具配合wiki有必要的文档记录;公共开源组件应在git中有对应的readme,上线之前要有对应的上线邮件,周知项目相关的人员确认上线,明确上线责任人。

  • CodeReview: 定期CR项目代码,大版本迭代一般是版本上线后统一CR,小版本迭代一周一次。主要内容:熟悉团队业务逻辑,减少代码交接成本。规范团队写码风格。提升团队整体的能力和水平。及时分享和抛出遇到的问题,共同解决和探讨。

  • ESLint规范: 规范编码习惯,注释习惯,统一化技术架构,减少工作交接的压力和复杂度。

  • 紧急开发情况:需求合理拆分,根据团队同学的能力拆分到具体同学手中;每天早晨站会,沟通当前进度,抛出目前遇到的问题;一到两天一次CR,细化需求进度,及时解决目前的问题,保证项目进度。期间如果遇到时间紧张人力匮乏的情况,分析目前的需求形式为暂时的,还是长期处于目前状况,计算需求的工作量,以及团队内每人的产出,给出准确的缺少人数并及时向leader反馈。

  • 项目调度:尽量保证固定的人负责固定的项目以确保项目合一短频快的完成的同时,也要关注团队同学的成长方向,及时给予新的机会的挑战。

  • 复盘:一般大版本迭代之后,会有一次复盘,主要用来抛出迭代过程中遇到的问题,在下一次开发过程中尽量解决或规避掉。

  • 周报: 周报中总结和整理团队同学中本周内的工作内容和项目进度,合理把控各项目的风险。安排下周的具体工作内容。及时暴露目前存在的问题以及提出解决问题的方案。

团队成长

  • 定期的技术分享与组会。
  • 关注团队成员成长需求。
  • 团队内技术工具产出。
  • 若团队人员较多,可进一步拆分业务线团队,选出能力较强的同学来带领团队。

关于生态环境的理解

区分为 C端 和 B端两个方向:

C端

C端项目多数对SEO和浏览器兼容性以及服务响应速度有极大的依赖,所以目前来讲,我总结了以下方案:

PC端:如果有兼容IE低版本的要求的话,采用Jquery;如果没有硬性要求,则可以采用Vue、React等新技术栈中服务端渲染。

移动端: H5 页面(zepto、webview、vue server render)、React Native App 等。

B端

偏后台系统:

对 SEO、兼容性、高并发、用户UI体验的要求并不特别高,我总结了以下方案:

  • 开发过程中利用 nodejs 前后端分离,创建前后端解耦的SPA

  • 线上也可以尝试MVVM的模式,进一步管理接口数据结构。

  • 团队内部系统健全: Mock服务系统、UI规范系统、CodeReview系统、前端线上监控报警系统以及相应的脚手架等。

后续补充: 和吉吉涛涛讨论了关于ToC端使用SSR可能会带来的影响,总结一下: SSR可能会带来不可规避掉的内存泄漏的问题;对于react框架体积大的瓶颈问题,提出使用preact替换方案;针对reactdui IE 6的兼容问题,提出使用anujs(优势在于 anujs 与 react 具有相同的api)替换方案。

本文链接:https://www.imwineki.cn/post/teamowner.html

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。