• 研发流程不只是一个流程


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

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

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

    image

    一、总要有个流程

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

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

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

    "有个急事,插一下!"

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

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

    "代码怎么被覆盖了?"

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

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

    "这个为什么没测到?"

    ... ...

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

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

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

    二、需要一个怎样的流程

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

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

    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人员都有可能操作这一流程。

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

    流程至此完结。

    三、附加订阅

    订阅

  • 相关阅读:
    CSS超出两行隐藏
    12、乐趣国学—践行《弟子规》的“信”懂得处世之道(下篇)
    TiFlash 源码阅读(九)TiFlash 中常用算子的设计与实现
    深入理解 PostgreSQL 中的 MVCC(多版本并发控制)机制
    MogDB企业应用 之 Rust驱动
    python爬虫自学首次大捷
    算法笔记(一)
    .NET 8 Release Candidate 1 (RC1)现已发布,包括许多针对ASP.NET Core的重要改进!
    Spring面试题20:Spring怎样开启注解装配?
    【OpenStack云平台】Packmaker 集群
  • 原文地址:https://www.cnblogs.com/niejunlei/p/17496599.html