开发视角下的标准化流程

在进行分享的开头, 请大家思考一下, 企业推行标准化流程的意义是什么? 思考完毕之后, 可以带着疑问去看本篇文章, 当然我也会在文章末尾给出我的看法, 希望大家能从本文中得到这个问题的答案.

在这里插入图片描述

以企业信息管理系统流程开发为例, 介绍以开发人员为角色下的标准化流程

企业信息管理系统, 即X系统. 作为部门第一个标准化开发的项目, 整个开发流程, 按照规范, 分为了很多环节, 每个环节都有许多人投入了大量的时间和精力. 下面我将以该项目开发人员的视角 , 来回顾标准化开发的流程, 并反思项目中的不足之处.

一. 背景

在我的印象中, 这个项目始于2022年08月12日. 当时负责该项目项目经理第一次找到我, 让我负责做此项目技术可行性研究. 自此, 这个项目便开始了,至今过去已一年有余. 期间各位领导, 专家, 产品/项目经理, 开发, 测试等人员的倾力合作, 让这个项目得以顺利进行下去. 项目也在今年年前正式上线. 至该文撰写时版本已经迭代至v1.4.8. 在此特别回顾一下整个项目的开发流程, 和大家分享一下开发视角下的标准化流程.

二. 过程

整个项目关键节点时间线梳理如下:

在这里插入图片描述

2.1 可行性研究

事前学习:

可行性研究就是从技术、经济、社会、环境等多方面对即将实施的项目的必要性、可行性、合理性进行细致深入的评估和审查，以确定项目是否可行，从而为投资决策提供科学依据

软件项目可行性研究主要包括以下五个方面：

• 经济可行性：主要考虑投入与产出的比例，也就是开发软件是否具有经济效益
• 技术可行性：主要是指现有技术（或其他技术）是否能实现软件的功能
• 操作可行性：主要是系统的操作方式用户能否认可
• 法律可行性：主要考虑的是否存在违法的，侵权的方面
• 时间可行性：主要是考虑软件能否在规定的时间完成

过程回顾

根据技术可行性要求, 开发人员需要通过一个demo 验证下技术可行性要求的内容,. 进而评估和验证当前技术是否满足项目需求. 并且通过对demo的实现, 将项目风险提前识别并进行预知. 然后供技术可行性的解决方案，包括技术选型、技术实现方法等… 最后, 根据前面的分析，判断项目的技术是否可行.

事后总结:

1. 理解技术可行性研究的内容 不能看到需求就立马开始做, 不理解的可以多和项目经理沟通, 避免因开发的demo偏离原本技术验证需求而导致的返工
2. 评估技术风险 在技术可行性研究中，开发人员还需要评估可能存在的技术风险，如技术实施过程中可能出现的问题、技术实施的效果是否达到预期等. 通过对这些风险进行评估，可以提前采取相应的应对措施
3. 对demo后续开发做提前考量 因为进行技术可行性研究的人一般也会是后续项目的开发者. 因此需要考虑接口调用频率, 是否采用缓存, 是否采用队列等等造成影响. 分析项目风险, 并思考解决方案, 提前为项目架构设计做好规划.

2.2 项目启动会

事前学习:

项目启动会是为了让所有相关方了解项目目标、计划、角色和期望，并明确项目启动的注意事项. 参与项目启动会的人通常包括: 公司相关领导, 相关领域专家, 产品/项目经理, 开发人员, 测试人员以及客户方代表(如果有)

项目启动会通常包括以下工作:

• 确定项目的目标和范围：明确项目需要实现的目标和范围，以确定项目的方向和重点
• 确定项目的利益相关方：识别项目的相关利益相关方，并了解他们的需求和期望
• 确定项目的资源需求：确定项目所需的人员、技术和资金资源，并规划如何获得这些资源
• 确定项目的风险和问题：初步识别可能出现的风险和问题，并制定应对措施
• 确定项目的沟通和协作方式：规划如何与利益相关方进行沟通和协作，以确保项目的顺利进行
• 确立项目管理团队和角色：确定项目管理团队和各角色的职责，以确保项目的有效管理和控制
• 审查和批准项目计划：经过审查和讨论，让所有相关方都知道项目计划，并获得他们的批准

过程回顾:

在启动会时, 主要由项目经理提出项目说明、目标和计划说明, 各干系人一起识别项目中的风险. 当时我们邀请了相关领域的专家, 负责在业务、开发流程、团队管理上提出意见 开启项目启动会后, 项目经理会组建项目开发群,

通过后来和项目经理交流之后得知, 前期整个主要流程为： 项目需求调研——明确总体方向和关键需求——项目可行性研究——项目立项（立项完成）——项目启动会（项目正式开始）——项目需求分析及设计——需求评审——……

事后总结:

1. 重视启动会 对于开发人员来说, 项目启动会最大的作用是让我们明确项目职责以及整体项目安排. 明白自己项目职责, 方知自己的该做什么; 熟悉整体项目安排, 方知自己什么时候做什么.
2. 重视项目启动会后到正式开发这段时间(如果有) 可以在这段期间进行项目概要设计工作, 项目概要设计内容包括: 架构设计、部署设计、技术选型、信息安全设计、运维设计等.

2.3 需求评审

事前学习:

需求评审是指在软件开发项目中，对需求文档进行逐一检查和评估的过程. 确保需求文档的准确性、清晰性、可行性，以及需求是否满足用户的期望需求和研发周期的评估. 在评审过程中，通常会涉及项目经理、客户代表、开发人员、测试人员等相关利益相关方的参与.

过程回顾:

在进行需求评审会前, 项目经理会提前准备需求说明清单表. 然后开发人员需要对需求进行分析, 找出设计中的缺陷和问题, 并提前进行排期(如下图)

项目经理根据此排期表进行评审, 在此期间, 各开发人员需共同讨论, 初步确定实现这些需求遇到的风险, 以及寻找风险的解决方案. 然后对需求进行适当的修改, 得出较为完整的需求说明书 在评审会议后, 项目经理会根据前后端, 测试, 运维的排期制作项目里程碑计划.

事后总结:

1. 开发人员可以和项目经理商议, 在需求评审之后, 再确定需求排期文档 因为对项目的排期计划的制定需要在项目进行充分理解的情况下进行的, 否则容易忽略项目中的工期进行误判
2. 通过转换视角来评审需求 需要从产品或者系统整体来理解需求，而不是只关注自己负责的一部分. 不然多人开发的时候，容易造成代码元余、对接混乱，一个系统，多种风格
3. 重视需求评审之后时间到下一个阶段的时间 这里可以进行项目详细设计， 项目详细设计的内容主要包括：数据库设计， 接口设计、代码结构设计等.
4. 认真核验需求内容以及自己的项目工时 提前识别出有问题的需求, 尽量避免后续开发中才遇到而导致的返工情况 在核验项目工时时，开发一般可以直接估算, 如果当中过程比较复杂可以采用单代号网络图来检验.

2.4 正式开发 & 数据库评审

事前学习:

对于开发人员而言, 在需求评审通过之后, 可以进行正式的开发. 项目的开发包括项目架构设计, 业务流程设计, 数据流程, 数据模型设计, 数据库设计. 在数据库设计完成后需要进行数据库评审.

数据库设计评审是指对数据库设计文档进行审查、评估和反馈的过程。评审的目的是确保数据库设计满足业务需求、遵循规范、安全可靠、易于维护和扩展.

以下是数据库设计评审的主要步骤:

• 确认业务需求：评审人员应了解业务需求和关键业务流程，以便确认数据库设计是否满足这些需求
• 检查规范：评审人员应检查数据库设计是否符合所选用的数据库规范和标准，包括命名规范、数据类型、约束、索引等
• 确认数据模型：评审人员应检查数据库设计的数据模型是否正确，包括实体、属性、关系、范式等
• 安全性评估：评审人员应评估数据库设计的安全性和访问控制措施，以确保敏感数据得到保护
• 性能评估：评审人员应评估数据库设计的性能，包括查询性能、事务处理性能、存储和索引性能等
• 维护和扩展：评审人员应评估数据库设计的可维护性和可扩展性，以确保数据库在未来的需求变化中能够持续发挥作用
• 提供反馈：评审人员应向设计人员提供具体的反馈和建议，以帮助改进数据库设计，确保其质量和可靠性

过程回顾:

在数据库设计完成之后, 相关设计人员与开发组内所有成员及项目经理等一起参加了数据库的评审. 开发者需要由数据库设计为基础, 向与会人员简述业务流程, 一起发现在数据库设计的不足之处.

事后总结:

1. 注意检查规范 需要关注表命名以及数据库字段的规范, 尽量做到统一, 例如在数据库字段命名时, 规范创建时间, 创建者, 更新时间, 更新者的命令和字段类型
2. 注意结合原型图进行设计 注意潜在数据，就是项目原型中未表现出来的，但实际的数据流或功能中可能会用到的数据. 以及根据原型和业务进行字段长度和数据类型的设计.
3. 注意在表中增加1-2个预留字段. 预留字段的作用是为以后可能发生的改动或新增需求留出空间，方便系统的扩展和维护。预留字段的一般不作限制，可以根据具体需求自由设置。通常建议在表设计时将预留字段放在表的末尾，以避免对已有字段的修改或删除
4. 将评审内容记录下来, 形成文档 数据库设计评审得到的内容是由团队内所有人员认可的, 通过实践得出来的结论. 评审的结果应被记录下来，以便在以后的数据库维护和扩展中进行参考

2.5 测试用例评审

事前学习:

测试用例评审是指在软件测试过程中，对测试用例进行审查和检查的过程，以确保测试用例的质量和有效性

测试用例评审包括以下几个方面：

• 检查测试用例是否符合测试策略：评审人员需要了解测试策略和测试计划，确保测试用例能够覆盖所有测试目标和测试场景
• 检查测试用例是否清晰明确：评审人员需要检查测试用例的标题、条件、操作步骤和预期结果，以确保测试用例描述清晰明了、易于理解
• 检查测试用例是否具有可重复性：评审人员需要检查测试用例的执行步骤是否具有可重复性，并确保测试用例中的测试数据和预期结果等信息是否准确
• 检查测试用例是否一致性：评审人员需要检查测试用例与需求说明、业务流程是否一致，以避免测试结果的偏差
• 检查测试用例是否具有可行性：评审人员需要评估测试用例是否符合实际情况，包括测试内容可行性、测试资源可用性等
• 检查测试用例是否完整性：评审人员需要检查测试用例是否覆盖了所有测试场景和测试目标，并考虑边缘测试用例

评审人员会基于上述的工作内容对测试用例进行系统性的审查，同时提供改进点和建议，以此为依据最终制定出一个更优质和高效的测试用例文档。

过程回顾:

在数据库设计完成后, 我们便进行了用例评审, 主要参与者包括产品经理, 测试, 开发人员等. 目的是确定测试用例是否符合实际情况, 以及测试用例和产品需求是否一致. 大家对不符合要求的用例提出意见, 测试根据大家的意见来修改测试用例. 事后测试会将修改好的测试用例发送给开发, 后续开发进行单元测试后可作为参考.

事后总结:

1. 注意测试用例的一致性 一定要注意测试用例与自己的业务流程逻辑是否一致 , 尽量避免发生"真假美猴王"的桥段. 否则后续在测试期间可能与测试就某些模糊的测试用例存在拉扯的情况( 都觉得自己做的没问题而找项目经理"评理" )
2. 测试用例评审逻辑, 可作为后续开发逻辑的补充 总得来说就是在保证一致性的情况下, 测试打算怎么测, 我们怎么写. 顺便还能帮助测试检测到测试用例的范围和边界. 当然实际情况大多是在项目开发快完成时才会出测试用例. 这个时候我们可以和需求说明一起将其作为业务逻辑检测的工具.

2.6 项目测试

项目测试是指在软件开发过程中，通过运行软件或者系统来评估软件或者系统的质量、可靠性、性能和安全性等指标的过程。通俗来说，项目测试就是对软件或系统进行各种测试，以发现其中的问题、错误或不足，并对其进行修复和改进，以确保软件或系统能够正常运行并满足用户需求。

事前学习:

项目测试可以分为以下几类:

• 单元测试(Unit Test) 单元测试是针对代码中最小的可测试单元进行的测试，通常是针对函数或方法进行的。单元测试主要检查代码中的逻辑错误和性能问题
• 集成测试(Integration Test) 集成测试是测试不同模块或组件之间的交互是否正常，主要检查模块之间的接口是否正确，以及模块之间数据的传递与处理是否正确
• 系统测试(System Test) 系统测试是在整个软件系统完成后进行的测试，主要验证系统是否满足用户需求，并且能够以正确的方式运行。测试范围包括功能测试、性能测试和安全测试等
• 验收测试(Acceptance Test) 验收测试是由客户或最终用户进行的测试，主要测试软件是否满足用户需求和期望。验收测试通常是在所有其他类型测试完成后进行的
• 回归测试(Regression Test) 回归测试是在进行了修改后针对原有测试用例进行的测试，主要针对已经修复的缺陷、添加的新功能以及对现有功能的影响等
• 性能测试(Performance Test) 性能测试是测试系统在不同负载情况下是否能够满足性能需求和要求，主要测试响应时间、吞吐量和资源利用率等方面

过程回顾:

1. 11月16日-12月1日 在十一月中旬的时候, 测试给到我们checkList, 让先我们自测. 由于开发任务比较重, 各自对自测不够重视, 并且各自为战, 导致在12月1日第一轮测试没有通过. 这是给我们的一个惨痛的教训!

在这里插入图片描述

1. 12月15日-12月28日 由于第二轮测试既包含了第一轮遗留的bug, 又包含新功能产生的bug, 因此那段时间改起bug来异常困难. 项目开发小组内仿佛也笼罩着一层阴云… 但在磕磕绊绊中还是完成了这轮测试.
2. 1月5日-1月13日(2023) 为了确保项目上线后可以顺利运行, 以及部分需求的改动, 我们又进行了一次回归测试, 即第三轮测试 由于这轮测试问题还是不少, 我们决定在发包的前一天晚上加班搞定这个项目. 好在最后大家齐心协力下, 最终让项目如期上线…

在这里插入图片描述

事后总结:

1. 一定要重视自测 以后端为例, 后端每开发一个接口后, 都应进行自测, 测试业务逻辑是否满足业务流程, 需求以及测试用例. 在前端对接好页面之后, 也尽量对前端页面进行的测试, 主要是检查页面有没有错误弹框以及数据显示问题. 我们在第一轮测试就是因为这个原因, 导致整个流程走不通. 所以说测试工作不只是测试的, 至少在项目未正常上线之前， 我们都应该保证前后端页面操作不会出现太明显的错误
2. 自测之后一定要互测 仍以后端开发为例, 项目在开发完成之后, 往往会进行自测, 但自测之后为什么还会出现很多问题呢? 经过我的思考, 大概是因为大家各写各的，未理解整体需求， 缺乏整体设计 只按照自己编写接口的逻辑进行简单的测试, 而对整个接口逻辑测试覆盖不全. 需要各成员进行互测, 从使用者的角度发现代码中的问题.
3. 自测/互测中出现的bug一定要记录. 自测/互测中发现的bug也建议找一个在线文档来记录. 用于开发对后续问题进行追溯. 否则在后续由于bug可能未改好, 导致的bug复现, 或者引起的新bug会难以追溯, 严重时会导致测试需要进行回归测试.

2.7 项目进度评审会

过程回顾: 由于X系统一期开发未通过, 加上二期开发和测试时间紧迫, 要求在月底开发完成并上线. 因此我们决定将一期二期工作合在一起. 但是从项目经理角度, 需要项目成员及时抛出当前遇到的问题, 并了解当下的项目执行情况. 于是项目经理打算召开项目进度会, 来了解当下项目执行的情况, 并让前后端能够充分对自己负责的模块进行自测.

X系统项目进度评审会
重视：跨部门联合开发全公司使用的一个系统，多个领导的关注重视，很多人自己从无到有负责的第一个项目
1、目标
（1）最终目标：12月31日正式发版面向全公司使用；
（2）上线目标：12月27日开始由部门进行试用；
（3）提测目标：本周三下班前提交测试；测试调试只有8天，时间很紧。
2、方案
（1）每个人必须自己或者找人互相配合对照原型走一遍完整的测试流程，不仅仅是自己负责的模块，大概需要2-3个小时。
     自己负责模块的问题自己协调处理，非自己负责模块的问题提交给对应的人；
（2）周三前解决禅道及产品测试buglist文档上面的问题，有问题的自己找人帮忙或者加班解决，如果导致出现项目延期或者其他问题的，
     自己提交相关的情况说明；
（3）需要前后端配合加班的，自己提前跟对方说。
3、前后端目前还在存在的问题，需要协调的地方。

通过此会议之后, 各组员之间的配合变得更加积极了. 也开始认真的进行自测和互测了. 因此觉得在项目进度出现问题时, 还是需要通过进度评审会进行沟通的.

2.8 正式发版

在测试通过之后, 对项目进行发版工作, 过程是由项目经理牵头, 提交发版申请, 相关人员负责配合进行发版 在发版后, 开发人员需要进行验证工作和发版后的支撑工作

过程回顾:

在1月13日加班加点的努力下, 项目于1月14日正式上线, 在上线之后, 大家也没有停下来, 而是补充由于进度问题而未编写的项目文档. 因此我们此时在狂补在开发过程中的本应完成的一部分项目文档

事后总结:

1. 重视项目文档 在项目正式发版前, 尽量完成项目文档. 因为项目配套的相关设计文档本应在代码编写前完成, 事后补可能会因为时间原因而使文档描述的内容不够完善. 项目文档应该项目代码具有同等地位.
2. 生产环境中遇到的问题需要被记录 发版之后, 将生产环境所遇到的问题, 在禅道或者文档中记录

2.9 后期迭代

过程回顾:

从今年年初项目v1.0.0版本发布之后, 陆续发布了近20个版本, 期间通过大家共同的努力, 为这个项目进行了充分的赋能. 随着版本的不断迭代, 我们由原来的PC端, 新增加了Pad端, 移动端. 集成了测试工单系统等等.

事后总结:

1. 在进行项目版本迭代时, 需要注意开闭原则. 即“软件实体（类、模块、函数等）应该对扩展开放，对修改关闭”. 换句话说，当需求发生变化时，应该通过增加新的代码来扩展现有功能，而不是直接修改现有代码. 目的是提高软件的可维护性、可扩展性和可重用性，同时降低软件的复杂性和风险.
2. 每次发新版本包时, 及时更新新版本中项目文档信息和代码中的版本信息. 方便日后相关人员对各版本内容的维护.

三. 思考

问题一

在这里插入图片描述

我的看法

在这里插入图片描述

问题二

在这里插入图片描述

我的看法

在这里插入图片描述

问题三

在标准化流程中, 作为开发人员应该注意哪些方面?

我的看法

• 认真对待项目中的每项会议：不同的会议有不同的作用, 例如项目启动会, 各种评审会议, 进度沟通会等. 体会每个会议的作用并认真准备和对待.
• 编码规范：在编写代码时，应该遵循公司和团队制定的编码规范，包括命名规范、缩进、注释、代码风格等. 以保持代码的一致性和可读性，同时也能减少代码错误和冲突.
• 自测/互测：单人开发时, 需要对自己编写的代码进行自测, 多人开发时, 在自测的基础上尽量相互测试, 及时测出项目中的代码缺陷, 有助于项目顺利进行.
• 代码审查：在提交代码之前，应该进行代码审查，检查代码的质量、风格和合规性. 及时发现潜在的问题和风险，提高代码的质量和可靠性.
• 项目版本信息维护：每次发新版本包时, 需要及时更新项目文档信息和代码中的版本信息. 方便日后对代码进行维护/
• 及时反馈和解决问题：遇到问题及时报告，并积极与相关人员沟通协作，确保项目按时完成.
• 文档编写：编写文档是开发过程中重要的一部分，应该记录必要的文档，包括接口文档、项目概要设计文档、项目详细设计文档、部署文档等. 同时, 要对文档进行审核, 使之规范, 简洁, 有效.

问题四

在开发的时候, 很多人都有这种想法: 这个bug这么简单, 而我有这么忙, 干脆让别人改吧! 又或者是我最近忙于其他项目, 我负责的bug就交给其他人来改吧! 那为什么我还是建议自己的代码要自己改呢?

我的看法

• 提高bug修复效率：作为代码的编写者，对代码的结构和逻辑肯定最熟悉，因此在代码出现问题的时候, 可以更准确地定位问题并找到合适的解决方案.
• 提高技能：通过自己修改代码，可以学习和掌握更多关于代码编写和调试的技巧, 发现当前自身的不足, 有助于在未来的更好地编写和维护代码.
• 减少沟通成本：如果将代码中出现的问题交给其他人来解决，可能需要花费额外的时间和精力来解释代码的功能和问题所在. 而自己修改代码则可以省去这些沟通成本，提高解决问题的效率.
• 增强责任感：当团队成员自己修改自己的代码时，他们可以更清楚地了解代码中存在的问题和改进的空间, 并增强他们对自身代码质量和项目成功的责任感.