以人治天下,贤则大治,不贤则大乱。

以术知天下,术高多宵小。

以法治天下,法令莫不从,民生定。

研发流程不只是一个流程-LMLPHP

一、总要有个流程

作为一个研发,你最讨厌什么?

"小功能,十分钟能搞定吧!"

"需求都清楚了吧,明天老板要看效果!"

"有个急事,插一下!"

"这个地方,还要调整下,稍后给你更新的文档!"

"这个当初肯定不是这样定的,是你们的问题"

"代码怎么被覆盖了?"

"测过的代码怎么没上线?"

"这个线上问题是谁谁的变动引起的。"

"这个为什么没测到?"

... ...

需求张口就提,说变就变;开发时间不明确,无法控制;测试不规范,不全面,质量无法保障等等,不一列举。

没有规范约束,没有流程限制,没有章程遵循。 可能对于某些场景会很高效,但问题也是层出不穷。

一个公司成长到了一定的规模,如果还是如上这种,那么唯一的结果只有:混乱。

二、需要一个怎样的流程

一个完整的研发过程包括哪些活动?

需求 => 开发 => 测试 => 上线。

1、需求怎么提?

a)需求阶段需要做什么?

确定要做什么 + 做成什么样 + 怎么做

比如:

要做什么:发表文章的功能页面要改版,以更好的适应用户的操作习惯。

做成什么样:新的功能布局 + 新的编辑器支持 + 表情符号支持 + 话题插入支持 + 图片编辑支持 + 自动实时保存支持。

怎么做:输出详细的 prd 需求文档 + 需求评审 + 资源调配 + 排期 + 进度控制。

相对来说,前两步多是产品自身范围内的工作活动,是需求的基础。最后一项则是和关联研发人员的协作,支持。以成品 prd 文档作为媒介,进一步展开后续的流程。

b)需求优先级界定

一个公司会有很多个产品,每个产品负责不同的业务范畴,那么便会衍生出不同方向的需求。

需求有大有小,重要性也不尽相同,所以需要有一个排序的流程。

将所有的需求都摆在桌面上,由上层来结合公司发展方向及公司战略来筛选哪些需要做,每一项的优先级。

2、需求评审

产品形成成熟的需求文档后,则要进行需求的宣讲,评审。也就是把上述的过程内容阐述给后续流程的研发人员(包括开发和测试等)。

所谓评审,既要评,又要审,也并不会是一锤定音,一遍过。 对需求内容的整体方向,产出,roi等综合进行考评,合适的的方保留,不合适的去掉,可以改进的继续改进。

对于比较大的,比较重要的或者比较复杂的需求,项目,可能需要经过多次评审,多次改进才能最终定稿。

这一流程节点产出是要作为整个研发流程的指导性文件,应该做到不厌繁琐,力求能够尽善尽美。否则越是往后流程的返工,成本越大。

3、排期

我们讲一个需求或者项目,即为在特定的资源条件下实现特定的目的。

既定的资源包括时间,人力及设备成本等。

需求周期一般是既定的,比如,老板说下个月什么功能上线,你就得上线,转圜余地不大。

所以涉及到人力需求则要在如上既定时间周期下去安排,调配人力资源。包括开发及测试等。

其它成本包括服务器,网络,外部付费技术资源(安全、校验)等,是不是需要采购新的服务器,是不是需要拓宽网络,是否是需要引入外部的校验API等。

这一阶段,主要是确定每个流程节点的时间需求,确保每个流程能够在合适的时间开始和结束。

4、技术方案评审

需求确定后,流程流转至开发人员,此时,开发人员应根据既定的 prd 需求文档,产出详细的技术方案文件。

闻道有先后,术业有专攻,每个人都有自己擅长的领域。单人主导的技术方案至少要经过交叉人员评审后方可定档实施。

比如,

数据怎么存储?表字段设计的合不合理?需不需要分表?

需不需要介入缓存层?需要哪种形式的缓存?

系统间怎么交互?交互方式?

接口设计是否合理?前后端交互流程?

哪些是核心业务逻辑?哪些业务可以拆分异步处理?

需不需要引入新的技术?

... ... 等等。

5、编码开发

编码开发其实占用的时间并不多。

就好像炒菜一样,菜品的清洗,准备往往是最耗时的,反而入锅翻炒也就一会儿的事。

6、Code Review

我一直秉信 Code Review 是能够极大保障代码质量的。

Code Review 关注点包括:代码设计、功能实现、复杂性、测试友好性、代码风格、命名、注释、文档等。

Code Review 的形式可以采取代码库流程,或者集体拉会形式等。

7、提供测试

开发流程结束后,流程流转至测试。

研发环境一般要提供完整的开发、测试、灰度、线上环境区分,以供不同阶段不同流程需要。

这一阶段,开发人员需要将开发结果部署到测试环境,提供给测试人员。

如有必要,也需要提供相关测试数据支持。

8、测试案例评审

测试案例输出及评审通常和开发并行,由技术方案流程确定后起始。

测试人员根据既定的需求及技术方案文档设计测试用例,包括新功能、变动功能及回归功能等。

测试用例完结后,需要和开发人员进行沟通评审,确保测试用例的完整性。

9、测试

测试环境及测试用例就绪后,开始流转测试流程。

测试包括功能测试、集成测试、回归测试、灰度测试、线上验证等。

由此节点开始可能需要横跨所有后续流程。

测试往往是产品质量的最后一道防线。

及早发现问题、提出问题应为首要,尤其不要试图掩盖问题。

上线前一秒发现问题都是居功至伟。

10、上线、验证

功能上线,不同公司可能操作方会略有不同,开发、测试、SRE人员都有可能操作这一流程。

上线后功能验证必不可少,由测试或者产品执行,确保产出和目标相符。

流程至此完结。

06-23 19:55