怎样应对突发性的开发需求

许多企业的开发需求是存在波动的,这就要求技术支撑能力也有一定的伸缩弹性。本文简单谈一下怎样构建有弹性的技术支撑能力。立足点是技术团队具备全栈能力,但人员配置偏少,在需求突然增加的时候,需要引入外包人员。

这种情况下,需要有一个完善的管理体系,来确保外包人员能够真正发挥作用,并且其贡献的代码不会成为将来自由团队的负担。

管理层面

需求控制

要建立比较强的需求控制能力,包括:

  • 能迅速识别并整理需求,形成规范、全面、详细的需求文档,对开发团队而言,比较重要的就是:交互原型设计文档,视觉设计相关的材料,算法具体描述等。
  • 需求文档能够做到整齐详尽,不遗漏需求,尽量减少歧义,各种逻辑分支描述清楚,不能只有一个主干流程。
  • 设计文档要有规范,手机端、PC端基于什么尺寸进行设计,给出的设计图最好可以通过工具自动标注和切图,避免设计图的缺失,减少技术和设计师沟通的工作量。

配置管理

要建立规范的代码和配置管理体系。

  • 代码权限控制,原则是程序员尽量只拥有其工作所需的最小权限。
  • 分支、主干、测试环境、生产环境之间的对应规则要清晰。
  • 代码合并由谁来控制,合并之前要满足哪些条件。

项目管理工具

要有成熟可用的项目管理工具,方便监控项目进度,需要有以下功能,可以由一个或者多个工具共同满足。

  • 任务和进度监控。
  • Bug管理。
  • 测试用例管理。
  • 文档管理(用来管理项目各类文档)。
  • 知识共享(用来向团队所有成员公开各类规范)。

技术层面

持续集成

代码的提交和合并来触发自动化的代码规范检查、持续打包、自动化测试(如果有的话),尽早发现代码层面的低级问题。

在线联调环境

考虑到外包的人员未必总是在甲方办公室,也考虑到远程加班的可能性,必须有在线的联调环境。

接口文档工具

最好使用RAP2/Swagger/Showdoc/YAPI之类的接口文档工具,方便文档的生成,通过mock server方式来提高前端开发效率。

统一的技术栈

  • 统一的技术栈,有利于人员在不同产品、项目之间进行调配。
  • 开发时使用的各类工具代码,也应该尽量统一,比如发邮件、发短信、生成随机数这类日常工具代码,也要统一,减少重复工作,也方便维护。
  • 开发环境的配置、IDE的使用,可能的情况下也尽可能统一,目的是减少因环境差异引起的不必要问题(不强求)。

解耦复用

对系统进行解耦,对模块进行复用。原则是降低代码的逻辑复杂性,降低对程序员的要求。

  • 前后端要分离。
  • 必要的时候做服务拆分,建立微服务架构体系。
  • MVC里面的层级拆分,数据层,业务层,控制层等。

以上的管理体系建设,是一个基础,有了这些,需要应对额外的需求时,就可以更从容有序,工程质量也更可控。外包力量的引入,有两种方式。

项目外包

如果需求中有一部分比较独立,与其他系统之间关联不大,可以考虑作为一个项目整体外包。管控重点是:

  • 需求必须清晰明确,需求文档的描述尽量细致,避免疏漏以及歧义。
  • 有清晰全面的需求文档之后,再谈价格和工期。
  • 外包商必须基于我方技术规范进行开发。
  • 数据库表设计、架构设计、新技术的引入和选型,必须经由甲方技术负责人同意。
  • 项目开发阶段,持续以一定的频率评审代码,并及时跟踪修正情况。

人员外包

需求没有足够清晰全面,时间紧张,或者很难切出一个相对独立的模块时,可以考虑采用人员外包的形式。管控重点是:

  • 对人员进行技术面试,确保其技术能力基本达标后才可同意其到岗。
  • 人员到岗后,第一时间提供各种规范、要求以及说明文档,并限定期限对外包人员进行相关考核,确保其对我方现有体系有足够了解。
  • 工作安排上,和内部员工在能力偏差不大的情况下,要一视同仁,以同样的标准来进行要求,避免区别对待。
  • 公司福利上,对外包人员也尽量提供一视同仁的待遇,避免区别对待。
  • 其他方面,对公司内部员工如何管理,对外包员工如何管理,就可以了。

猜你喜欢

转载自www.cnblogs.com/zhaoxizhe/p/12559640.html