项目复盘都应当怎样做?

待我称王封你为后i 2023-07-20 10:51 58阅读 0赞

项目复盘的目的不是为了匹配谁，而是为了大家从复盘中找到问题，避免下一次犯同样的问题。那作为软件项目应当怎样来进行复盘呢？接下来我就介绍一下复盘的经验：

<table> 
 <tbody> 
 <tr> 
 <td colspan="2">会议名称：门店列表&amp;详情统一改版项目复盘</td> 
 </tr> 
 <tr> 
 <td style="width:430px;">会议时间：2019/08/06</td> 
 <td style="width:362px;">会议地点：B7肯尼亚</td> 
 </tr> 
 <tr> 
 <td style="width:430px;"> 参会人员(包括所有角色)： leader:&nbsp;XXX、XX 后台：XXX、XXX 前台：XXX、XXX 产品：XXX、XXX 测试：XXX、XXX </td> 
 <td style="vertical-align:top;width:362px;"> （必须要有人记录和主持） 记录人员：XXX 主持：XXX </td> 
 </tr> 
 <tr> 
 <td colspan="2">会议内容</td> 
 </tr> 
 <tr> 
 <td colspan="2"> 一、&nbsp;项目情况（主持人：先介绍一下项目情况，总体上对大家做出的成果进行肯定） 开发周期：2019.06.18 ~ 2019.07.29 主要上线内容包括： 1、门店列表&amp;详情统一改版上线 &nbsp; 二、开场论述（项目PM：总体上对大家做出的成果进行肯定） &nbsp;开发过程涉及内容多，途中有紧急需求穿插，测试过程遇到环境问题、数据问题，上线过程历时15个小时。项目过程辛苦、曲折，但准时按照业务方要求上线，结果比较完美。 &nbsp; 三、调研阶段（项目各个角色（leader、后台、前台、产品、测试、UI等）对调研阶段的优点和缺点发表自己的意见，首先说优点、再说缺点、大家一起讨论缺点的解决方案） 本次改版具有众多意义： 1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;多端进行同步（PC、APP、H5） 2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;彻底解决门店列表排序不一致问题 四、需求评审阶段（项目各个角色（leader、后台、前台、产品、测试、UI等）对需求评审阶段的优点和缺点发表自己的意见，首先说优点、再说缺点、大家一起讨论缺点的解决方案） 1、评审不细致，未精确到某些小的细节，如某些特殊逻辑等 2、评审过程中，PRD反复修改。 3、PRD内容多、乱，研发人员理不清关系 解决：新组团队第一次接手大项目，对系统熟悉程度不够，多熟悉系统，多做调研分析，规范PRD发布流程，有更新及时通知。 总结：&nbsp;PRD更新及时通知。 需求改动多的时候加一轮需求评审。评审做会议纪要，提的问题要记录下来。 &nbsp;&nbsp; 五、开发过程（项目各个角色（leader、后台、前台、产品、测试、UI等）对开发过程阶段的优点和缺点发表自己的意见，首先说优点、再说缺点、大家一起讨论缺点的解决方案） 1、研发人员对产品PRD研读不仔细，精确 解决：研发人员在开发之前，应仔细研读PRD，避免低级错误。 2、开发中产品需求有变动 解决： 产品需及时更新相关信息，并且将变更需求写在白板上起提示作用。 3、开发中无原型交互稿，影响开发进度。 解决：leader寻找交互人才。 4、UED设计稿任务不明确，图标等UED小细节外加。 解决：前端评估工作量，大于一天对UED评审，少于一天自行对接 5、上游依赖复杂，测试过程中无真实数据。 解决：考虑对技术架构进行调整与解耦，并向下兼容。 6、与前端定义接口数据不准确，文档不清晰，与前端调试不顺利 解决：文档备注需清晰，对老系统需进行梳理。 7、产品与业务侧沟通困难 解决：产品找外部协助进行生产上线，需要提前沟通好，上线时，业务侧需提供一人支持，至少保持电话联系 &nbsp; 总结：开发之前要仔细研读PRD，明确开发任务，尽量提前熟悉系统，产品需找业务侧进行协助 &nbsp; 六、测试用例&nbsp;&amp;&nbsp;测试过程（项目各个角色（leader、后台、前台、产品、测试、UI等）对测试用例&amp;测试过程阶段的优点和缺点发表自己的意见，首先说优点、再说缺点、大家一起讨论缺点的解决方案） 1、细节问题较多，如前端样式大小 解决：产品研发明确需求边界。 2、产品和研发不知道影响点 解决：主要在于研发人员对代码不熟悉，需要仔细熟悉代码 3、修改bug随意，出现修改bug不对，引入新的问题、修改问题不完整等问题 解决：研发人员需仔细修复BUG，修复后自测并且要与测试人员沟通 4、小程序和车管家 数据经常不同步，研发人员信息传递不及时 解决：增强研发人员之间的交流，横向互相分享信息 5、接口定义前后端传参没有考虑到特殊异常（如null）实例：如广告问题 解决：需要关注边界值，多做空判断，前后端需要沟通进行约定异常处理规定 6、测试阶段过进度会 参加人员不齐，明确不了问题 解决：测试、研发、产品问题分类在白板记录便于提醒。测试如发现无法明确的问题需挂在禅道上面。 7、测试过程中出现问题，产品找不到解决方案 线上有风险，需找业务侧，采销侧推动困难 解决：测试用例评审需叫业务侧 8、测试过后线上数据被投诉，测试商品未及时下架 解决：明确规范，勿钻空子 &nbsp; 总结：通过仔细阅读PRD避免细节问题，研发人员修改bug需要谨慎，前端和后端需要多横向沟通。 七、上线过程（项目各个角色（leader、后台、前台、产品、测试等）对上线过程阶段的优点和缺点发表自己的意见，首先说优点、再说缺点、大家一起讨论缺点的解决方案） 1、预发环境没提前上。 2、代码合并较晚，要提前准备，10点才开始打包。 3、开发分支没有定时合并master，合并代码有冲突。 4、发布流程基本没按发布计划来。 5、不能选择12点以后发布，因为人没有精神。 6、PM推进不够，不要在原地打转。 7、临上线修改阈值信息，且信息不对等（小程序和APP不对等，10KM问题）。 8、脚本要按照不同的环境进行编写，不能想当然的处理。 9、持续性的发布人员休息安排。 10、私接需求，比如门店详情页的广告页。 11、项目脚本和新增配置要统一沉淀到CF文档上。 八、上线后（项目各个角色（leader、后台、前台、产品、测试等）对上线过程阶段的优点和缺点发表自己的意见，首先说优点、再说缺点、大家一起讨论缺点的解决方案） 1、上线后没有出现大bug，只有一些小优化需要进行跟进。 </td> 
 </tr> 
 <tr> 
 <td colspan="2">会议结论</td> 
 </tr> 
 <tr> 
 <td colspan="2"> 1、开发过程曲折，结果从业务和技术层面上看都比较满意； 2、相关评审要仔细，需要把控更多相关细节； 3、研发人员需要仔细阅读相关PRD； 4、信息沟通要及时，建议写在白板上，每天过进度会； 5、cf文档应该合理利用； 6、本次项目上线对安装服务的渗透意义重大。 </td> 
 </tr> 
 </tbody> 
</table>