精华内容
下载资源
问答
  • 技术评审

    2021-02-27 14:00:28
    火龙果软件工程技术中心 在工作中,我们经常可以听到以下的声音:“我们不进行评审,是因为我们项目比较特殊,没有时间……”。“我们的项目已经进行了测试,不...Why-为什么要技术评审?测试无疑是质量控制最常用的
  • 技术评审规范,增加对技术评审的要求。
  • IPD中的技术评审

    2021-01-30 20:50:09
    通过技术评审可以尽早发现阶段性交付件中存在的问题,避免后续阶段对前期隐藏的缺陷无法纠正或者需要耗费较大的人力、物力和时间才能纠正。本程序明确了技术评审分类和特点,明确产品开发的技术评审点设置和评审内容...
  • 如何做好技术评审

    2020-10-27 15:51:58
    如何做好技术评审 前言 Why-为什么要技术评审? What-什么是技术评审? How-如何做好技术评审? 1、技术评审常见的问题 2、常见的技术评审的类型 3、同行评审简介 When-常见的技术评审点举例 何做好技术...

    目录

    如何做好技术评审

    前言

    Why-为什么要技术评审?

    What-什么是技术评审?

    How- 如何做好技术评审?

    1、技术评审常见的问题

    2、常见的技术评审的类型

    3、同行评审简介

    When-常见的技术评审点举例


    何做好技术评审

    前言

    业界公认评审是质量控制最有效的手段之一,但评审在很多公司却没能很好地实施,甚至没有实施,公司也未能从中获益。一方面因为员工不清楚评审的目的、评审和测试的区别,认为评审只不过是除了测试以外的锦上添花的过场。另一方面也因为许多公司制定的评审流程流于形式,缺乏可操作性,也未对员工进行评审流程的培训,未能在评审流程执行过程中提供适当的指导和监督。

    Why-为什么要技术评审?

    测试无疑是质量控制最常用的方法之一,因此很多公司认为对产品进行了测试就万事大吉了。而评审是一种在产品开发过程中尽早发现缺陷的手段。根据IBM的统计数据显示:大多数企业的产品开发中,2/3的缺陷都是在需求和设计阶段引入的。因此,通过评审尽早发现的缺陷的修复成本远低于在产品开发后期测试中发现的缺陷的修复成本。

    缺乏技术评审,或未严格进行技术评审的后果往往会导致测试阶段发生缺陷的“井喷”,开发人员不得不拼命加班“救火”,而最终由于缺陷越来越多,产品上市时间也所剩无几,不得不遗憾地放弃——产品只能带着缺陷发布给客户,听天由命了。

    案例:某产品由于未经严格评审,而匆促上市,结果发现设计指标不符合规格书要求,设计中未考虑工程和维护的问题,产品质量问题多多,生产的单板直通率低,生产效率不高,结果开发工作重新回炉,导致客户投诉不断,用户怨声载道,严重影响用户关系和公司产品形象;导致所有开发人员全部出去救火,开发周期大大加长,开发投入增加,库存积压占用资金。

    评审的目的在于:越早发现问题,总体成本越低,因此要评审,评审,再评审!等到测试已经太迟了!

    What-什么是技术评审?

    测试和技术评审都是有效的质量控制手段,但也有明显的区别。

    类似地,技术评审和测试的目的都是为了寻找缺陷,寻找缺陷的目标不是证明它是正确的,而是证明产品不能工作。

    测试是在产品运行时进行的动态分析,测试的对象为原型、中间产品和最终产品。相对地,评审是一种静态分析,评审对象通常是技术文档、计划、测试用例和测试数据、测试结果等。

    How- 如何做好技术评审?

    1、技术评审常见的问题

    许多公司虽然执行了技术评审,但却未能从中获益,这往往是因为以下的原因导致的:

    1.  没有评审计划,没有充分的准备
    2.  专家选择不合适
    3.  评审会议偏离主题和重点,过多争论占用大量时间
    4.  没有使用Checklist作为指导
    5.  问题修改后跟踪不力……

    由此可见,评审效率不高的原因主要是因为缺乏可操作的评审规程、评审执行和跟踪不力导致的。因此,针对不同类型的工作产品,应制定包括多种评审类型的规程,并借助检查单的使用来提高评审的可操作性。

    2、常见的技术评审的类型

    常见的技术评审包括了走查(Walkthrough)、轮查(Pass Around)、正式的同行评审(Peer Reviews)等。

    1. 走查(Walkthrough):是大名鼎鼎的面向对象方法学的开发者之一Yourdon 定义的方法,它由作者启动和主持评审,作者向评审者展示文档。优点是启动快,成本低,缺点是容易被作者误导过程。
    2. 轮查(Pass Around):作者向评审者作简要介绍,但不参加评审过程;评审者独立进行评审,并记录发现结果、准备报告。
    3. 同行评审:评审者与作者是地位平等的同行/专家,而不是领导对员工的评价;是最为结构化的评审方法;可以作为同行之间学习和分享经验的机会。

    3、同行评审简介

    在软件CMM中首次提出了同行评审(Peer Reviews)这个概念,它的目标是在产品开发过程中尽早发现缺陷,从而以较低的成本尽早解决缺陷。这种方法借鉴了IBM的范根检查法(Fagan Inspection)的优点,是一种结构化的正式的评审方法。

    同行评审有明确的角色定义:

    •  协调员(Moderator):保证评审按流程进行。
    •  朗读者(Reader):评审的技术领导,把焦点放在有争议的问题方面。
    •  记录员(Recorder):负责记录缺陷。
    •  评审员(Reviewer):负责发现缺陷,除了作者外,所有的其他角色都可以担任评审员。
    •  作者(Author):负责修正缺陷。

    同行评审通常包括六个步骤:制定计划、召开准备会议、评审人员独立预审、召开评审会议、返工、跟进返工结果。各个步骤的活动说明如下:

    1. 计划:选择参与者;准备检查单。
    2. 准备会:分配各参与人员的角色;作者对产品作概要介绍。
    3. 个人预审:评审者研究评审文档,使用检查单寻找缺陷,记录发现结果。
    4. 评审会议:读者阅读评审文档,评审员发现缺陷,对有争议的问题进行讨论;作者一般保持沉默,除非读者要求对产品作解释。
    5. 返工:作者修正错误。
    6. 跟进:检查修正工作的进展;分析错误原因;分析评审过程,补充完善检查单。

    附:做好技术评审的小贴士

    •  不因为时间紧迫和缺少预算而省略评审
    •  评审前充分准备和沟通
    •  安排合理的预审时间以便评审人员阅读评审材料
    •  技术评审应当“就是论事”,不要把评审会开成“批斗会”,不要打击有失误的开发人员的工作积极性,更不准搞人身攻击,如挖苦、讽刺等
    •  评审人员的职责是发现工作成果中的缺陷,并帮助开发人员给出消除缺陷的办法,而不是替开发人员消除缺陷
    •  把技术评审作为交流、提高的机会
    •  记录评审中出现的问题,跟踪改进
    •  定期改进技术评审检查单,把检查单作为持续改进的重要载体
    •  评审者必须是领域内的专家

    When-常见的技术评审点举例

    在对工作产品建立基线之前进行评审,目的是发现缺陷。 

    附:TR2中使用的检查要素节选

    项目 评审要素

    • 需求分配与系统架构 产品包需求是否充分转换成设计需求?
    • 所有产品包需求(包括客户需求、可服务性/可维护性/可靠性等)是否清晰地定义并映射到产品概念中?
    • 产品概念的功能分解是否清晰地描述(譬如已经画成框图)?
    • 硬件和软件的集成方案是否考虑并确定好?
    • 根据被选产品概念形成的系统架构是否满足需求文档中的性能目标要求?
    • 技术方案选择 产品选择的技术的生命周期是否符合产品的规划?
    • 硬件概念是否可以用已有的芯片技术来实现,或者该技术的成熟度是否满足开发和交付的需要?
    • 选择的产品概念的风险和局限是否进行评估和记录?
    • 所有和包需求、设计需求、产品概念相关的问题是否被记录和进行风险评估?
    • 是否已经确定产品的标准和规范?
    • 在选择产品概念过程中是否对方案提供商进行了深入分析(包括产品选用的技术、平台、OS、关键物料等)?  

     

    展开全文
  • 技术评审方法与指南[3]软件测试2.2指南结构走查的特点是:相对其他评审方式而言,评审员在评审活动上的工作量开销比较大。这是一种比较正式的评审方式。如果方法应用得当,评审人员具备相应的业务技能和评审技巧,...
  • 技术评审节点

    2017-02-06 14:08:08
    技术评审节点

    产品开发中,TR是技术评审节点。 .

    在工作中,我们经常可以听到以下的声音:

      “我们不进行评审,是因为我们项目比较特殊,没有时间……”。
      “我们的项目已经进行了测试,不需要再进行评审了”。
      “评审都是在走过场,没有效果……”。
      业界公认评审是质量控制最有效的手段之一,但评审在很多公司却没能很好地实施,甚至没有实施,公司也未能从中获益。一方面因为员工不清楚评审的目的、评审和测试的区别,认为评审只不过是除了测试以外的锦上添花的过场。另一方面也因为许多公司制定的评审流程流于形式,缺乏可操作性,也未对员工进行评审流程的培训,未能在评审流程执行过程中提供适当的指导和监督。

    Why-为什么要技术评审?

      测试无疑是质量控制最常用的方法之一,因此很多公司认为对产品进行了测试就万事大吉了。而评审是一种在产品开发过程中尽早发现缺陷的手段。根据IBM的统计数据显示:大多数企业的产品开发中,2/3的缺陷都是在需求和设计阶段引入的。因此,通过评审尽早发现的缺陷的修复成本远低于在产品开发后期测试中发现的缺陷的修复成本。

      缺乏技术评审,或未严格进行技术评审的后果往往会导致测试阶段发生缺陷的“井喷”,开发人员不得不拼命加班“救火”,而最终由于缺陷越来越多,产品上市时间也所剩无几,不得不遗憾地放弃——产品只能带着缺陷发布给客户,听天由命了。

      案例:某产品由于未经严格评审,而匆促上市,结果发现设计指标不符合规格书要求,设计中未考虑工程和维护的问题,产品质量问题多多,生产的单板直通率低,生产效率不高,结果开发工作重新回炉,导致客户投诉不断,用户怨声载道,严重影响用户关系和公司产品形象;导致所有开发人员全部出去救火,开发周期大大加长,开发投入增加,库存积压占用资金。
    评审的目的在于:越早发现问题,总体成本越低,因此要评审,评审,再评审!等到测试已经太迟了!

    What-什么是技术评审?

      测试和技术评审都是有效的质量控制手段,但也有明显的区别。
      类似地,技术评审和测试的目的都是为了寻找缺陷,寻找缺陷的目标不是证明它是正确的,而是证明产品不能工作。
      测试是在产品运行时进行的动态分析,测试的对象为原型、中间产品和最终产品。相对地,评审是一种静态分析,评审对象通常是技术文档、计划、测试用例和测试数据、测试结果等。

    How- 如何做好技术评审?

    技术评审常见的问题
    

      许多公司虽然执行了技术评审,但却未能从中获益,这往往是因为以下的原因导致的:

      ◆ 没有评审计划,没有充分的准备
      ◆ 专家选择不合适
      ◆ 评审会议偏离主题和重点,过多争论占用大量时间
      ◆ 没有使用Checklist作为指导
      ◆ 问题修改后跟踪不力……

      由此可见,评审效率不高的原因主要是因为缺乏可操作的评审规程、评审执行和跟踪不力导致的。因此,针对不同类型的工作产品,应制定包括多种评审类型的规程,并借助检查单的使用来提高评审的可操作性。

    常见的技术评审的类型
    

      常见的技术评审包括了走查(Walkthrough)、轮查(Pass Around)、正式的同行评审(Peer Reviews)等。
      1) 走查(Walkthrough):是大名鼎鼎的面向对象方法学的开发者之一Yourdon 定义的方法,它由作者启动和主持评审,作者向评审者展示文档。优点是启动快,成本低,缺点是容易被作者误导过程。
      2) 轮查(Pass Around):作者向评审者作简要介绍,但不参加评审过程;评审者独立进行评审,并记录发现结果、准备报告。
      3) 同行评审:评审者与作者是地位平等的同行/专家,而不是领导对员工的评价;是最为结构化的评审方法;可以作为同行之间学习和分享经验的机会。

    同行评审简介
    

      在软件CMM中首次提出了同行评审(Peer Reviews)这个概念,它的目标是在产品开发过程中尽早发现缺陷,从而以较低的成本尽早解决缺陷。这种方法借鉴了IBM的范根检查法(Fagan Inspection)的优点,是一种结构化的正式的评审方法。

      同行评审有明确的角色定义:

      ◆ 协调员(Moderator):保证评审按流程进行。
      ◆ 朗读者(Reader):评审的技术领导,把焦点放在有争议的问题方面。
      ◆ 记录员(Recorder):负责记录缺陷。
      ◆ 评审员(Reviewer):负责发现缺陷,除了作者外,所有的其他角色都可以担任评审员。
      ◆ 作者(Author):负责修正缺陷。

      同行评审通常包括六个步骤:制定计划、召开准备会议、评审人员独立预审、召开评审会议、返工、跟进返工结果。各个步骤的活动说明如下:

      1) 计划:选择参与者;准备检查单。
      2) 准备会:分配各参与人员的角色;作者对产品作概要介绍。
      3) 个人预审:评审者研究评审文档,使用检查单寻找缺陷,记录发现结果。
      4) 评审会议:读者阅读评审文档,评审员发现缺陷,对有争议的问题进行讨论;作者一般
        保持沉 默,除非读者要求对产品作解释。
      5) 返工:作者修正错误。
      6) 跟进:检查修正工作的进展;分析错误原因;分析评审过程,补充完善检查单。

    附:做好技术评审的小贴士

      ◆ 不因为时间紧迫和缺少预算而省略评审
      ◆ 评审前充分准备和沟通
      ◆ 安排合理的预审时间以便评审人员阅读评审材料
      ◆ 技术评审应当“就是论事”,不要把评审会开成“批斗会”,不要打击有失误的开发人
        员的工作积极性,更不准搞人身攻击,如挖苦、讽刺等
      ◆ 评审人员的职责是发现工作成果中的缺陷,并帮助开发人员给出消除缺陷的办法,而不
        是替开发人员消除缺陷
      ◆ 把技术评审作为交流、提高的机会
      ◆ 记录评审中出现的问题,跟踪改进
      ◆ 定期改进技术评审检查单,把检查单作为持续改进的重要载体
      ◆ 评审者必须是领域内的专家

    When-常见的技术评审点举例

      在对工作产品建立基线之前进行评审,目的是发现缺陷。

    产品开发中,TR是技术评审节点。

    下面是某产品的技术评审点,供参考:
    TR1——概念阶段技术评审点:产品需求和概念技术评审(业务需求评审)
    TR2——计划阶段技术评审点1:需求分解和需求规格评审(功能需求评审,产品级规格)
    TR3——计划阶段技术评审点2:总体方案评审(系统设计,架构设计,概要设计)
    TR4——开发阶段技术评审点1:模块/系统评审(详细设计,BBFV测试结果)
    TR4A——开发阶段技术评审点2:原形机的质量SDV结果和初始产品的准备情况
    TR5——开发阶段技术评审点3:初始产品的质量(SIT结果)(SIT Alpha测试技术评审)
    TR6——验证阶段技术评审点:发布评审(SVT Beta测试、制造系统验证等)

    SDV就是system design verification,即系统设计验证
    BBFV就是building block fuction verification,即编译模块功能验证
    SIT就是system integration testing,即系统集成测试
    SVT就是system verification testing,系统验证测试

    展开全文
  • 技术评审意见书.doc

    2021-09-21 21:10:21
    技术评审意见书.doc
  • 技术评审到底需要评审哪些东西

    千次阅读 2017-05-16 14:59:37
    技术评审到底需要评审哪些东西

    一:系统模块的划分

    主要是对系统整体的梳理,将问题大而化小。同时保证系统的单一职责,减少耦合。

    模块划分是指在软件设计过程中,为了能够对系统开发流程进行管理,保证系统的稳定性以及后期的可维护性,从而对软件开发按照一定的准则进行模块的划分。根据模块来进行系统开发,可提高系统的开发进度,明确系统的需求,保证系统的稳定性。

    二:涉及到的外部系统及交互方式

    主要是列出当前系统需要交互的系统和交互的方式。判断交互方式是否高效合理。判断系统调用是否正向,是否循环调用等。

    三:各个模块的部署方案

    根据各个模块的特点,性能,压力等因素,来选择单机部署或者多机部署等,拟定最后的一个部署方案。

    四:重要模块的技术选型

    针对模块中的技术问题,在解决时,需要对多个技术方案进行调研和选择。需要记录选择的技术方案和原因。

    五:重要逻辑中的问题的考虑

    比如数据一致性,比如耗时操作的处理等问题的一个考虑和应对措施。

    六:模块中的重要设计和性能考量

    比如数据库设计,流程设计等对程序性能的影响。提出衡量程序的性能的标准和指标

    七:系统的拓展性

    系统拓展性展示


    展开全文
  • 技术评审方法与指南[4] 软件测试 3.2指南 审查的特点是: 相对其他评审方式而言,审查的工作量开销最大。 这是一种最正式的评审方式,评审效果会很好,但是成本很高,不一定是最经济的评审方式。 结构走查的...
  • 职业卫生技术服务机构认可技术评审准则.doc
  • 技术评审方法与指南[1]软件测试1走查(Walkthrough)走查是一种常用的非正式评审方式,评审在作者的主导下进行。走查过程中作者会给评审员详细介绍软件制品,走查员也可以就评审发现进行沟通。由于在走查前没有要求...
  • 悬浇箱梁技术评审方案.pdf
  • 项目经验 需求评审与技术评审

    千次阅读 2021-04-07 11:49:46
    做开发应该对需求评审,技术评审并不陌生。 但常有小伙伴抱怨,需求评审会参加了不少,会上定下来的东西却不多,需求朝令夕改也是常态。久而久之,需求评审就变成了立项动员会,走个过场,没起到实际作用,开发小...

    做开发应该对需求评审,技术评审并不陌生。

    但常有小伙伴抱怨,需求评审会参加了不少,会上定下来的东西却不多,需求朝令夕改也是常态。久而久之,需求评审就变成了立项动员会,走个过场,没起到实际作用,开发小伙伴当然不想参加啦。

    那有人说了,技术评审应该不会这样了吧,毕竟是开发内部自己讨论。但从我的实践经验来看,也不一定,大家规划的好好的摩天大楼,盖着盖着就变成了草房的事情也发生过。

    现实就是这样魔幻。本文,我将站在开发的角度,结合真实经验,给大家说说,怎样开好需求评审会,技术评审会。

    需求评审

    需求评审,是产品,开发和测试的双向沟通(诶诶?怎么会把测试拉进来?没错,我司需求评审就是要求测试参与,原因后面会讲到)。

    产品就好像老师在台上讲,但开发,测试作为学生不能(断句)不懂装懂,有问题一定要大胆提出来!我们强调***双向沟通***!以免发生需求评审会上,开发拍着胸脯说,没问题没问题,开发到一半才发现实现不了,灰溜溜地跑去给产品说,然后双方大打出手的事情。

    那么需求评审需要做哪些事情呢?

    • 原型图
    • 理解需求
    • 定结论
    • 通知相关人员
    原型图

    作为开发,测试,我们对需求没什么话语权。但是!在需求评审会上,我们要求产品必须给出***原型图***!就算没蓝湖画的,在笔记本上画,那也得有照片!

    俗语说:说者无意,听者有心。人说出来的,和自己心里想的,不一定匹配!同一句话,不同人也会理解出不同意思!

    而落在画面上的原型图可以消除这种差异。点这里出这个弹框,如果这样还能理解出花样来,那你的脑洞优秀的。

    需求评审会决定之后的开发方向,如果方向都错了,然后就没有然后了。

    建议

    使用线上原型图工具,这样大家通过一个地址都能看到。

    如果中途修改了需求,尽快更新到原型图上,并***通知大家***。

    定结论

    如果一个会议开完都没有结论,那就等于没开。所以我们至少得确定以下几点:

    • 开发,测试理解了需求解决的业务问题。
    • 需求优先级
    • 参与人员,时间节点
    • 通知相关部门
    开发,测试理解了需求解决的业务问题

    首先,需要开发纠正一个观念,那就是——产品要求的我做就是了,其他的我一概不管。我说了,产品需求会是一个双向沟通的过程。在过需求时,开发在理解需求后,最好根据自己的经验,对原型做出评价。

    什么意思呢,举个栗子,产品新增了一个用户退款的需求,用户不用联系客服,自助退款。这时,我会把自己代入用户的角色,来看看用原型图的方式退款,一,是否能完成操作流程,二,是否方便,三,同类产品退款功能是怎么做的。同时,我也会把自己代入管理员的角色,后台,退款要不要自动操作?如果需要人工介入,管理员怎么操作?退款人数过多,是否需要批量操作?如何审计?可能会出现哪些风险?

    比如,别人退款都是按一个套路做的,产品搞个特立独行的设计,我脑袋里模拟了一下,哪有这样搞的啊,那我就得提出来呀——你这是什么鱼唇的需求?!我第一个不同意这门亲事!

    再比如,我发现操作到某一步骤,我想反悔,而原型图上没有相关功能,那我就得提问。

    重要的不是喷,你得提出你的观点!你得提出产品没有看到,没有想到的地方。帮助产品去补完原型。产品改不改需求是ta的事,但你必须参与其中。互联网公司大家都是阅历相近的人,大多都是讲道理的,产品觉得你说的有道理,ta自然会去改。

    这样,就避免了一部分做到中途改需求的事发生(当然,可不能百分百不改需求,但我这样做之后,自感需求变动较之前少了很多)。当然,产品不改,那我们就拿小本本记着,毕竟开发没有决定权。

    如果需求有不理解的地方,或者有歧义的地方,无论开发,测试都应该当场提问。坚持***需求不明确就不动工***!

    测试为什么要理解需求?你测试都不知道这个需求在搞什么事情,你测啥?

    建议

    需求不合理处,提出同行一般解决方案。

    若你提出的方案被产品否决,记录下来,等待正式服用户验证(也许这种做法也不是错的,只是不常见,万一用户接受呢?万一用户喜欢呢?现实是很魔幻的)。

    需求不明确不动工。

    需求优先级

    如果只有一个需求,break。

    如果有多个需求,必须确定优先级。这个没什么好说的,永远***先***开发***最重要***的需求,就算项目延期,至少核心功能还能上。

    参与人员,时间节点

    这个也没什么好说的。这里着重说一下时间问题。

    有时,有些需求不急,产品不会给死线,但从我的经验来看,没有时间节点=没有目标,没有目标=根本没人会主动去做。

    还有时,产品不定时间节点,我们吭哧吭哧一会儿搞完了,产品又说这个需求不搞了(呵呵,你这个善变的人)。

    所以,不管需求急不急,也定一个时间节点吧,产品不定时间的需求也不要慌着去搞。

    如何评估开发时间?其实这是一个无解的问题,你一定对下面的场景非常熟悉:

    产品:什么时候能做完?

    开发:大概XXX天吧。。。(心虚)

    产品:啊?这么久?不行啊!这时候做出来黄花菜都凉啦。

    开发:那你什么时候要?

    产品:当然是越快越好啦,再不济,也得XXX号之前吧。

    开发:好。。。好吧(哭唧唧)

    一般而言,开发对死线没有话语权,不过问题你总得回答吧,这里给出我的方式:

    首先确认产品的死线定的是***上线时间***,还是***提测时间***,还是***开发完成时间***。这点非常重要!你不问他不说,最后大家都哦豁(GG的意思)!

    开发天数=预估天数*风险系数。

    预估天数根据经验定,风险系数根据团队研发效率定(这个系数一般是1.x,当然也可以是0.x)。

    这里测试也要给到测试时间。测试知道开发死线,也可以变相监督开发按时完成(因为那天ta会找你要测试地址呀)。

    建议

    每个需求定下时间节点。

    明确时间节点到底是上线时间,还是提测时间,还是开发完成时间。

    任何需求变化通知开发Leader,而不是具体开发人员,Leader没通知到开发是Leader的失职。

    通知相关部门

    有些需求需要其他部门配合,在需求评审会结束后***立刻***通知相关部门。

    某次,有个需求需要其他部门提供接口,这事在很久之前碰过一次。我们这边开发的时候没有通知对方,结果我们都开发完了,正准备找他们联调的时候,才发现他们根本没开始做。。。因为我不知道呀,你没告诉我呀!

    建议

    确定合作方接口人,大小事宜只找接口人。

    对方最好能提供他们的死线。

    需求评审会的结论,必须落到协同办公工具上,然后发送给每一位与会者。

    对于极善变的产品,保留第一版代码,设计,因为大概率ta都会改回去(这不是段子,这不是段子,这不是段子)。

    技术评审

    技术评审会比需求评审稍微好一些,毕竟都是圈内人。但会议的目的是定结论:

    • 选型——语言?必须
    • 架构——单体?负载集群?分布式?必须
    • 框架——组件?版本?必须
    • 中间件——可选
    • 风险及预防措施——并发?大流量?异常?必须!别告诉我没风险!
    • 前后端对接——可选

    后端需要考虑的东西很多,这里不细讲,后面会单独讨论。

    后端

    技术评审,我个人倾向敲得越细越好。

    我也是从小项目干过来的。那时候项目小,需求一下来,根本不用技术评审,一梭子代码就敲上了。也会时常遇到搞到一半大修大改,甚至推翻重来的情况。但毕竟是小项目,就算艹了重来,时间也够。可后来随着项目规模越来越大,吃过几次大亏之后发现,对于中大型项目,如果搞到中途才发现路走不通,基本就没退路了!

    那要细到什么程度?

    对于后端,你得把所有接口,入参,出参,过程查询哪些表,更新哪些表,经过哪些中间件,在业务流程中,各个接口如何配合,全部在脑戴里过一遍!

    什么?这太变态了?不,从我的经验来看,即使做到这种程度,在开发过程中还是有的改!你一定听过8分时间设计,2分时间编码的理论。我最早也对此嗤之以鼻,但现在却奉为圣经。从效果上看,这样做,虽然不能保证完全不改,但至少可以保证不会推翻重来!

    前端

    对于和前端对接的项目,最好在评审时拉上前端,先简要描述一下接口的出入参,让前端评估是否需要修改参数,字段。别自己先做出来了,粗暴的丢给前端,前端一接,这也是问题,那也是问题。

    至于出现矛盾,前后端谁改的问题,我认为要秉承公平原则:

    • 分页的事儿总该你后端做吧,那就别让前端假分页。
    • 数据格式转换的事儿,最好也让后端来做。
    • 数据展示,要拼接一些字段,这个事儿前端就别让后端冗余字段了吧,自己拼吧。
    • 前端需要一些额外参数辅助,后端就帮忙加一下。
    • 后端对参数格式有要求,前端传的时候就帮忙转一下。
    • 等等

    谁也别让谁养成了坏毛病,该谁干就谁干,久而久之,默契了,就不会出这么多幺蛾子了。一般来说,即使前后端一起评审,开发过程也难免需要前或后端改动,但我们尽量在前期规避掉大部分。

    建议

    事先约定错误码,包括HTTP码,和业务逻辑码。

    后端给出在线接口文档,不要自己写,用工具生成。

    如果团队氛围活跃,要避免争论不休,当有多个方案,或没有优质方案时,使用最保守的那一个(我是保守派)。

    如果团队氛围沉闷,要一锤定音,Leader要定下方案,即使错的,也要执行,团队必须要有执行方向。

    技术评审会的结论,必须落到协同办公工具上,然后发送给每一位与会者。

    最后

    虽然开发专注于技术,但你会发现文中很多重点却不在技术,而是在做人做事方面。你会换位思考,站在他人的角度看问题,你尊重他人,才会去想这个事应该我来做,你会揣测他人的意图,ta表达的到底是不是这个意思,等等。

    我一向认为,开发,技术是硬实力,它关乎做不做得出来的问题,沟通协作是软实力,它关乎做不做得好的问题。

    我自己虽然技术不怎么样,但做事的时候,会去主动思考这些问题,会尽量让大家配合得更丝滑一些,大家和和气气,顺顺利利地朝同一目标整活,这难道不香吗。

    本文到此结束,谢谢大家。欢迎提出意见,也欢迎参与讨论。

    展开全文
  • 职业卫生技术服务机构资质认可技术评审准则.docx
  • 技术评审方法与指南[2]软件测试作者在走查活动的组织过程中,需要和项目管理人员充分沟通,确保走查活动在项目工作计划中得到体现,保证走查员有时间参加走查会议,而且,评审员必须承担相应的责任。为了保证走查的...
  • 铁路信号安全数据网网络安全保护技术方案通过技术评审.pdf
  • 技术评审报告 项目名称 版本号 评审名称 评审时间 评审地点 评审级别 公司级别 部门级别 室级别 评审类型 首次评审 回归评审 部分评审 阶段评 审 评审方式 会议方式 审查方式 走查方式 轮查方 式 记录人 是否复审 不...
  • CMMI中的技术评审

    2012-02-08 14:54:46
    基于CMMI的技术评审资料,用于搭建技术评审框架。
  • 信息系统项目管理工程师 技术评审
  • IT项目管理表单大全-技术评审篇(13个文档),包含:技术评审技术评审计划;技术评审通知;技术评审报告;技术评审检查表。。。。。。
  • 6、技术评审计划模板
  • cmmi--技术评审规则

    2015-04-28 23:02:30
    技术评审规程
  • 怎样做好技术评审

    千次阅读 2019-06-06 11:57:59
    在产品开发的过程中,耳熟能详的一句话是“通过控制过程质量,来保证结果质量”,而对于关键交付件的“技术评审”,正是有效保证过程质量的重要举措之一。从咨询的过往情况来看,绝大多数企业在意识层面对技术评审的...
  • 技术评审计划的制定与实施.doc

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 66,872
精华内容 26,748
关键字:

技术评审