前端项目管理总结
# 前端项目管理总结
# 整体流程
- 项目立项（大部分直接进入项目）
- 项目宣讲、评审（产品、设计师），（交互稿评审、视觉稿评审）。有问题需要提出问题，比如交互上面、实现上面、兼容性、服务端实现、边界问题。尽量把问题讨论完全。产出：整理问题、待确认问题、需要调研、需要合作。
- 整理问题、待确认问题、需要调研、需要合作。确认问题 review，会议形式。
- 前端、客户端、后端，负责各个功能的同学，做项目系分。系分包括：流程图、交互逻辑、兼容性（小程序、H5、APP）问题、技术方案、表设计、sql语句、依赖第三方包、接口定义、字段约定、入参出参、潜在风险、埋点等等。
- 前端、客户端、后端小组内，过项目系分。聚焦问题，再进行确认。
- 系分评审
- 确定排期（是否砍需求），项目经理邮件发出
- 投入开发，bug日清，每天上午或下班前，review 进度，上报风险、问题。
- 开发完成，开始联调
- 联调完成，部署到开发环境，进行自测，过完所有的冒烟用例。
- 正式提测，发提测邮件。
- 测试、改bug
- 完成测试，UI、产品进行验收。
- 部署到预发，预发验收。
- 部署到线上，线上验收。
- 埋点数据采集。
- 项目复盘。
# 项目、需求评审
- 了解需求背景：解决什么痛点、做什么功能改进、优化？
- 评估功能可行性、需求是否存在问题、漏洞，能否自圆其说，跟现有的业务逻辑是否冲突
- 了解上下游的依赖，业务关系依赖。比如是否依赖社区功能、基础架构、数疗是否改动。
- 如果是基础功能改动，评估其影响面
- 明确功能涉及修改到的端：小程序、H5、APP H5、运营后台、ipad
- 明确是否个性化需求：比如药明小程序的需求，功能是否要同步到各个小程序。
- 有的功能依赖第三方的组件或服务，需要做调研：比如加密服务、tab组件、手势、拖拽等
- 小程序版本号，跟产品定下版本号，先定好规则。
# Good
及时与会提前熟悉PRD，预习需求记录问题认真聆听，积极思考，提出问题，给出建议或反馈
# Bad
做与评审无关的事情注意力不集中迟到
# 评审后续action
- 依赖服务梳理
- 依赖业务问题处理
- 依赖第三方的组件或库，写demo
- 如果PRD、UI有修改，需要督促相同同学进行修改
# Bad
H5 tab组件，技术方案是使用第三方组件。但没有写demo去验证，实际开发过程中不可用。
# Good
弹窗快捷回复组件，提前写好demo，让产品、设计师体验，减少后续开发成本。
# 功能系分
- 理解业务功能、背景、目标。
- 熟悉业务代码
- 对照PRD和UI稿过一遍功能
- 梳理所需的接口、字段（新增接口、新增字段）
- 梳理上下游依赖
- 梳理第三方依赖
- 暴露问题和风险
- 是否有遗留的问题需要修复：主要是遗留问题，交互体验优化
- 是否有技改需求：迁移网关、前后端分离、代码重构、组件升级、基础库升级、性能优化等等
- 团队分工达成一致
- 内部过系分
- 编写系分文档
- 工时评估：开发时间、联调时间、自测时间、冒烟用例、预留buffer。明确每个阶段的产物。一般来讲，自测时间不大于联调时间。比如联调需要1天时间，那么自测时间一般为0.5天。考虑到每周还有各种会议要参加，可以再预留 0.5天的buffer。
- 如果PRD、UI有修改，需要督促相同同学进行修改
# Bad Case
弹窗处理，不同的场景，区分不同的文案，展示不同的tab。没有理清楚。 H5 tab组件，技术方案是使用第三方组件。但没有写demo去验证，实际开发过程中不可用。 UI上画的页面跟现有的页面一样，但是逻辑不同，前端同学以为是同一个页面。未进行确认。 PRD上出现跟XX页面保持一致，未提出质疑，导致后面返工或延期。
# Good Case
患者APP 的问卷详情修改，深入代码和业务场景，挖掘PRD中未标明的问题。 UI上未标注什么端，各端展示可能不一致，需要找UI同学确认。
# 系分评审
由PM发起，后端、前端、客户端等等。 包括常规的：技术方案设计、流程图、交互功能、边界处理。 内部做好UI评审。 特殊的：在PRD评审时的遗留问题、系分时候发现的问题、处理做同步、特殊场景的处理。 如果PRD、UI有修改，需要督促相同同学进行修改。
git应该默认为大小写敏感：
git config core.ignorecase false
# 测试用例评审
测试用例评审可能是在开发过程中发起的，测试同学会将所有的case进行枚举，相关的前后端同学需要一起参加。 针对测试同学提出的case进行评估、讨论，避免错误和遗漏，尤其是需要结合自己的系分来进行比较，查漏补缺。 如果在测试用例评审中，还有问题需要确认，由项目经历进行记录，并在会后找相关同学进行确认。确认后，需要及时更新视觉稿、PRD，并在群里同步。
# Bad
产品或设计师私下修改稿子，不同步，如有发现，请全员喝奶茶。
# Good
如果有遗漏需求，需要通知到负责模块的开发同学、业务负责人、测试，并进行评估。
# 开发、联调、自测阶段
由业务负责人在部署平台创建项目，创建新的业务分支： SFxxxxxxxx
开发同学基于业务分支创建自己的个人开发分支，比如 feature/heizi_doctor_list前期开发，应该有个 mock 平台（本地mock方式）。
本地开发的时候，务必保持编码风格和代码格式的统一（eslint，prettier）。
每天自己对进度进行把控，有问题向业务负责人、项目PM反馈。
前后端开发、联调完成后，基于 gitee 提交 mr 业务组长或负责人对代码进行review，然后合并。
对于UI稿，务必要保证还原度，常见的比如圆角、字体颜色、大小、透明度等等。
部署平台上部署到开发环境，跟后端一起过冒烟用例。
小程序、H5、个案管理对应不同端的应用需要在端上进行自测。
联调阶段，冒烟阶段，大家需要控制下发布节奏，部署的时候需要通知下项目同学，避免联调和测试终端。一般每半小时部署一次。
# Good
有问题，及时反馈，暴露风险。
# Bad
合并时候有冲突，自行解决，默默推送。 代码实现、方案实现有问题或风险，自己觉得能搞定。
# 测试、改bug阶段
冒烟结束后，经测试同学确认通过，则进行提测。一般由后端同学发起，写提测邮件，抄送项目组全体同学。
协助测试进行相关的测试流程。开发环境的账号，可以找测试同学索取。
熟悉自己模块的测试流程和测试数据的建造过程。
测试期间，不断的结合测试同学给到的测试用例（非冒烟用例）进行自测。测试期间，可能会收到测试同学提的bug，如果确定是自己的bug则修改状态【接受】，如果是其他同学的bug，则进行流转转交，尽量补充下信息，比如是后端的什么问题，或者不是自己负责的功能等等。
如果是已有的问题，或者暂时不需要解决的，找业务负责人、测试、产品进行确认，可选择延期解决或暂时不需要解决。如果自己不能判断bug的处理方式，找业务负责人确认。
改完bug后，需要部署到开发环境，部署前务必跟测试、后端同学在群里进行通知，尽量不要中断其他人的调试或测试。一般的，也是半小时或者一小时，集中部署一次。
部署完后，自己先验证有无问题。没有问题后，再去修改bug状态。
测试同学主要是在测试环境进行测试，会定期的同步下开发环境的静态资源。
reopen的次数，会作为一个考核指标，尽量不要出现reopen的bug。测试同学会比较心累。
测试阶段，合代码也需要走 git mr流程。测试每天会发测试进度和日报，
基本的要求是bug日清，如果有特殊原因需要说明，尤其是阻碍测试主流程的bug
在时间充裕的情况下，组织一次code review。
当测试进行到100%的时候，会让产品、设计师在测试环境进行功能验收和视觉验收，如果有问题，还需要进行相应的修改。
前端最多的就是样式的问题。所以测试时候，务必在ipad或APP（真机环境）中进行测试。
前后端一起整理发布预案，回归方案，重点关注接口部分的修改，紧急情况下，是否能直接回滚，保证功能正常，需要提前做好评估。拿对方的测试用例，测对方的bug。
# Bad
测试过程中，如果没有bug提过来，就去做其他事情，这样是不够严谨的。
# Good
自己结合测试用例进行测试，首先保证自己负责的模块没有问题，包括：实现需求、视觉还原、兼容性等等。 修改bug后，务必确保自测通过。了解自己功能的测试流程。定期的查询自己的bug。 业务负责人需要定期查看团队的bug，关注bug解决情况。
# 预发测试
测试环境功能验证完后，需要部署到预发环境进行测试。
如果是小程序的功能，一般会对线上功能进行回归，保证用户在小程序版本未更新的时候，功能是正常的。
服务端的接口都是向后兼容的，应该要兼容之前的小程序版本。
比如修改接口的时候，不能导致上个版本的功能不可用。预发部署的时候，走部署流程，这时候会将SF分支代码合并到master。可能有冲突，需要先解决冲突。
如果有预发测出来问题，基于SFxxx分支，走git mr 流程。
正常来讲，预发是最后一道防线。预发环境的部署节奏需要严格把控，不能随意发布，发布前必须通知整个项目组。
# Good
预发环境，保证接口调用和对应环境一致。
# Bad
预发环境，调用了开发环境的接口，去掉 vconsole 调试工具，关闭调试模式。
预发验收不够仔细，比如临时增加的需求，前后端同学没有测试到位，测试也忘记了，就直接发布线上了。
调试模式下，可能会导致未配置的业务域名能正常访问，而线上会报错。P0故障。
# 部署线上
部署线上的时候，需要提前由项目经理创建发布窗口。
当前窗口下所有的项目相关同学都务必在场。通过部署流程，部署线上。后端先发，前端后发。发布完成后，线上验证。
如果验证过程中，有问题，需要及时反馈出来，由测试、开发Leader一起决定是否需要回滚或者走紧急发布。
如果是回滚，按照之前的发布预案进行回滚。如果是需要紧急发布，则走紧急发布流程。走部署流程，基于master创建EM分支，合并走 git mr 流程。
但是web端是直接生效的，尤其需要优先处理。
小程序的部署紧急流程，走过一次，时间很漫长。发布没有问题后，在小程序发布群中，同步发布内容，维护小程序发布迭代表格。
在大前端群里，同步本次发布内容，提醒大家pull远程的master代码，删除本地的无用分支。
小程序的版本，把版本号带上。
# Bad
有发布，但人不在，且未指定交接人。
# Good
自己需求需要搭车发布，尽量保证项目上线，如果不是紧急的功能，指定好交接人，并保持电话oncall
# 项目复盘
针对本次项目过程中出现的问题进行复盘总结，尤其是reopen的bug、紧急发布的原因等等。
有数据的，收集好数据后，让产品进行功能复盘，是否有达到产品设计的目标和预期。
使用了新的技术，或者好的优化方案，进行项目总结。如果产生了线上故障，需要进行故障复盘，确定可执行的措施和落地时间。
# Good
产品主动组织复盘项目经理组织复盘，主要针对的是项目过程中出现的问题。代码合并出现问题，找到原因，并进行文档记录。
# Bad
出现了问题，不进行总结。