关于前端:需求研发流程节点及关键产出总结

49次阅读

共计 2038 个字符,预计需要花费 6 分钟才能阅读完成。

全流程图示

参加人员及职能阐明

  • 产品经理(PM):需要的布局和设计者。收集用户诉求和反馈,确定需要收益,设计零碎的性能和交互细节。一线业务诉求都会通过 PM 的消化确认后才会输入给开发人员。针对每个需要都要产出精准详尽的需要文档。(需要文档须要涵盖交互图)
  • 开发人员(RD/FE):依据需要文档,产出技术方案设计文档,并开发具体性能。开发细节全副参考需要文档,如果 PM 没写能够要求其补全。每个需要都会有一个对应的开发负责人,也叫次要开发 RD,用来协调和反馈整体开发周期进度,通常由本次后端次要内容改变人负责。
  • 交互和视觉设计(UI/UE):负责产出交互图和设计图,交互最终会体现在需要文档中,要求研发人员严格实现,而 UI 的设计图则独自提供前端,具体实现水平会和前端开发协调。大多数时候我的项目并没有 UE,都是 PM 本人设计的交互图。
  • 测试人员(QA):依据需要文档产出测试用例,并依赖测试用例测试和反馈发现的问题。

次要流程节点

  1. 需要圈定
    决定本次迭代能够开发哪些具体的需要,每个部门的圈定形式不太一样,但后果都是确定了本次迭代的需要池和优先级,并打回业务价值绝对很低或显著不符合规范要求的需要。圈定的意义在于,每次迭代依据产能确定正当的需求量,并确保整体业务价值最大化。执行详情可参考需要圈定执行概要
  2. 需要评审(以下都是针对单个需要)

    1. 发动人员:产品经理(PM)
    2. 参会人员:产品经理(PM)、开发人员(RD/FE)、设计人员(UI/UE)、测试人员(QA)
    3. 须要筹备:需要文档草案(PM)、交互图草案(PM/UE)
    4. 次要产出:需要文档定稿(含交互)、各方排期状况及预期上线工夫、技术评审工夫节点
    5. 探讨内容:各方人员需在需要文档草案的根底上,确认每个性能点是否能够 / 应该实现,在这个环节须要表白所有有异议的中央,并和 PM 探讨后确认最终履行的计划,定稿需要文档。另外还须要探讨各方参加人员的排期状况,确认各环节及上线的大体工夫节点。针对设计和前端合作,还须要给出交付前端设计图的工夫节点。最初还须要本次需要的次要开发人员给出技术计划评审,也就是下一个环节会议的具体工夫。须要留神的是,需要文档定稿后如果还有(非细节补充类)改变,则须要发动需要变更流程,从新排期和估时,一般来说不会轻易发动需要变更
  3. 技术计划评审

    1. 发动人员:本次需要的开发负责人(次要 RD)
    2. 参会人员:开发人员(RD/FE)(蕴含其余技术骨干,个别是组长等)、测试人员(QA)
    3. 须要筹备:技术方案设计草案(RD)、接口设计草案
    4. 次要产出:技术方案设计定稿、接口设计定稿、前后端联调工夫节点、提测工夫节点
    5. 探讨内容:本次需要的次要开发人员,须要邀请其余技术骨干来评审,确保本次实现的计划是科学合理的,并最终产出技术计划定稿。同时还须要和前端确认接口设计方案,并定稿接口文档。QA 也须要参加则是为了加深对实现的理解,不便写出更有针对性的测试用例文档。计划都确认后即可明确排期打算,所以还须要确定前后端联调工夫和提测工夫(准确到半日)
  4. 开发 / 联调 / 测试用例编写
  5. 测试用例评审

    1. 发动人员:测试人员(QA)
    2. 参会人员:测试人员(QA)、开发人员(RD/FE)、产品经理(PM)
    3. 须要筹备:测试用例草案(QA)
    4. 次要产出:测试用例定稿
    5. 探讨内容:QA 凭借本身对需要文档和技术计划的了解,产出系统性的测试用例文档。在本次会议上须要针对一一 case 和 PM、RD 确认是否合乎预期,会后须要定稿测试用例,定稿后可要求 RD 严格实现用例中的每一个 case
  6. 我的项目自测
    RD 依据测试用例,实现自测工作,可参考对于晋升开发品质,升高提测 Bug 率的探讨
  7. 我的项目提测
    提测是有提测动作要求的,不同部门不太一样,可能是状态管理系统的工作状态批改,也可能是提测邮件确认。提测后 QA 如果还发现问题,则须要提出 Bug 并指派给对应 RD。QA 是有权打回提测的,通常都是因为问题太多、主流程跑不通等
  8. 问题修复
  9. 四方验收(可选)

    1. 发动人员:本次需要的开发负责人(次要 RD)
    2. 参会人员:产品经理(PM)、开发人员(RD/FE)、设计人员(UI/UE)、测试人员(QA)(可选)
    3. 须要筹备:测试通过后待上线的性能
    4. 次要产出:确认上线可行性
    5. 探讨内容:本次会议是为了上线前的性能确认,以及设计图实现成果确认(设计确认也能够提前就开始做)。个别都是间接运行并展现性能,都确认通过后则能够开始筹备上线
  10. 上线及回归测试
    上线前须要 RD 整顿 CheckList 文档,用来确保上线后性能都合乎预期,也不会影响其余相干性能。等顺利完成上线后,须要和 PM 一起,依赖 CheckList 进行线上验收,验收通过后整个流程完结

要害文档

  1. 需要文档(含交互图):整个研发流程的外围,定稿后不能轻易批改是整个研发流程的基石
  2. 技术方案设计文档:多为后端技术计划,用来确保本次实现科学合理,也不便将来查阅
  3. 测试用例文档:在需要评审后便能够开始编写,提测前肯定须要实现评审,是系统性测试的保障,也是开发人员自测的依赖
  4. 线上 CheckList 文档:线上回归须要涵盖的范畴,用这种模式是为了防止脱漏
正文完
 0