事后诸葛亮分析

壹、会议分析

一、设想和目标

  1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们的软件核心解决计算机视觉领域姿态估计的实际应用痛点，初期聚焦人体姿态检测与动作评估，后续拓展至人机交互场景。问题定义经历了从宽泛到具体的优化，最终明确聚焦工厂安全检测场景，解决人工监控易遗漏的痛点。典型用户分为初期的计算机视觉研究者、高校师生，后期的工厂安全管理员、智能家居企业等，对不同用户的需求和使用场景有清晰描述，且通过用户故事具象化了应用场景。

  1. 是否有充足的时间来做计划?

有充足的计划时间，项目初期专门预留第9周用于组建团队、明确分工和制定计划，且在需求梳理过程中持续优化计划，确保计划与实际开发匹配。

  1. 团队在计划阶段是如何解决成员对于计划的不同意见的？

通过集体讨论对齐目标，结合任务负载均衡、任务关联度等量化逻辑调整计划，例如调整《构建之法》的阅读章节，拆分过长的冲刺周期，确保计划的可行性和成员认可度。

经验教训与改进：初期计划对任务颗粒度拆分不够细致，后期通过WBS分解和人天分配优化了这一问题。如果重来，会在计划初期就进行更精细的任务拆解，明确每个任务的输出标准和时间节点，同时提前收集成员对技术实现的意见，避免后期大幅调整。

二、计划

  1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

大部分原计划工作已完成，核心的模型推理、任务调度、告警推送等功能均实现。未完成的工作包括Linux版本开发、用户注册功能，原因是Alpha阶段优先保障Windows环境核心功能落地，用户注册功能因时间紧张延迟至下一版本，且部分性能优化任务（如模型首次加载时间优化）需更复杂的技术方案。

  1. 有没有发现你做了一些事后看来没必要或没多大价值的事?

基本没有。但初期对《构建之法》11-15章的阅读安排与当时的计划冻结目标关联度较低，后续调整至第10周与技术实践任务同步进行，提升了学习效率。

  1. 是否每一项任务都有清楚定义和衡量的交付件?

大部分任务有明确的交付件，如需求规格说明书、架构图、可运行的模块代码等。但初期部分学习类任务未设定明确的交付标准，后期通过补充“读书心得摘要”“技术笔记”等交付件，规范了学习任务的衡量标准。

  1. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

未完全按原计划进行，计划根据需求优化和实际开发情况进行了校正。意外情况包括：GPU环境版本兼容性问题（CUDA与TensorRT版本不匹配）、跨语言调用时的环境隔离问题、RTSP流连接超时等。未预估到的风险主要是技术栈集成的细节难点，如Java调用Python脚本的环境依赖冲突、TensorRT转换时的算子适配问题，原因是初期对多技术栈协同的细节复杂度评估不足，缺乏实际集成经验。

  1. 在计划中有没有留下缓冲区，缓冲区有作用么?

有留下缓冲区，通过“单周核心任务数=必须交付成果数×1.2”的公式预留缓冲空间，且将14天的Alpha冲刺拆分为两段≤7天的冲刺周期。缓冲区有效应对了技术难点导致的进度延误，如模型转换、环境配置等问题均在缓冲时间内解决。

  1. 将来的计划会做什么修改？

会进一步细化技术预研阶段的计划，增加对多技术栈集成难点的预研任务；预留更多针对环境配置、跨模块联调的缓冲时间；将性能优化任务提前至核心功能开发阶段，避免后期集中优化的压力。

我们学到了什么? 改进方向：计划制定需充分结合技术栈的实际复杂度，对跨语言、跨平台的集成任务进行专项预研和风险评估。应明确所有任务（包括学习任务）的交付标准，通过量化指标确保任务执行效果，同时采用更灵活的冲刺拆分方式，提升对进度的把控力。

三、资源

  1. 我们有足够的资源来完成各项任务么?

有基本的资源保障，但部分专项资源存在不足。充足资源包括：7名成员覆盖开发、测试、前端、后端等角色，具备Java、Python等核心技术能力；GitHub仓库、Docker、GPU服务器等开发部署资源。不足的资源包括：工业级工厂监控数据集、部分成员对TensorRT、ZLMediaKit等技术的实战经验，需通过开源数据集、技术文档学习和测试环境验证弥补。

  1. 各项任务所需的时间和其他资源是如何估计的，精度如何?

通过任务拆分（WBS）和人天分配估计时间，结合技术难度和成员技能水平分配资源，精度逐步提升。初期精度较低，仅估算到周级任务；后期通过细化至“模块-子任务-人天”的拆分，精度提升至4-8小时/子任务，核心任务的时间估计误差控制在20%以内。

  1. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试资源基本充足：分配了专门的测试角色成员，制定了详细的测试计划，具备GPU服务器、多浏览器、多操作系统等测试环境。但测试工具的使用不够充分，主要依赖人工测试和Postman等基础工具，缺乏自动化测试工具的应用。未低估非编程资源的难度，提前规划了文档编写、UI设计等任务，安排专人负责，确保需求规格说明书、接口文档等文案的完整性。

  1. 你有没有感到你做的事情可以让别人来做（更有效率）?

有。例如初期部分文档整理任务由开发成员兼职，后期发现专职测试成员的文字整理能力更强，将文档优化、测试报告编写等任务移交测试成员，提升了文档质量和开发效率；跨模块联调任务通过“专人统筹+分工协作”的方式，避免了重复沟通成本。

经验教训与改进：资源分配需充分结合成员的技能特长和任务特性，通过明确角色分工提升效率。如果重来，会在项目初期进行更细致的技能盘点，针对性分配任务；同时提前引入自动化测试工具，补充测试资源，提升测试效率和覆盖度。

四、变更管理

  1. 每个相关的成员都及时知道了变更的消息?

是的。通过GitHub Issues、每日Scrum站会、博客更新等方式同步变更消息，确保所有成员及时了解需求调整、计划变更、接口规范更新等信息。

  1. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

通过功能优先级四象限分析决定功能取舍：P0级核心功能（如YOLOv8 ONNX推理、基础告警功能）必须实现；P1级增强功能（如TensorRT加速、多环境兼容）优先实现；P3级锦上添花功能（如移动端适配、C++推理集成）推迟至后续版本。同时结合用户需求的紧急程度和技术实现难度，确定功能的优先级。

  1. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

有清晰的定义。核心出口条件包括：核心功能无致命缺陷；性能指标达标（单任务TensorRT推理延迟≤50ms、100并发用户下系统稳定）；跨平台兼容性满足（Windows系统+主流浏览器适配）；测试覆盖率≥80%；所有致命和严重缺陷已修复。

  1. 对于可能的变更是否能制定应急计划?

能。针对需求变更制定了“变更评估-影响分析-方案调整-同步执行”的流程，例如需求从通用姿态估计调整为工厂安全检测时，快速评估了模型适配、数据集替换、功能调整的影响，在1周内完成了需求规格说明书和计划的更新。

  1. 成员是否能够有效地处理意料之外的任务请求？

能。成员能够快速响应临时任务，如环境配置问题的排查、跨模块联调的配合、紧急Bug的修复等。例如针对MinIO权限配置错误、推流参数不匹配等临时问题，相关成员通过查阅文档、团队讨论快速找到解决方案。

我们学到了什么? 改进方向：变更管理需建立更规范的评估流程，对变更的影响范围、工作量进行量化评估后再执行。如果重来，会提前制定变更申请模板，明确变更的触发条件、评估标准和执行流程，同时加强成员对需求核心目标的理解，减少非必要的变更。

五、设计/实现

  1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作贯穿第10-11周，由团队集体讨论、核心成员主导完成。架构设计由具备Python后端和模型开发经验的成员主导，数据库设计由熟悉SpringBoot和MyBatis的成员负责，前端设计由负责Vue开发的成员完成。设计时间与需求规格说明书编写、核心功能开发衔接顺畅，负责人的技能与设计任务匹配度高，是合适的时间和人选。

  1. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

碰到过模棱两可的情况，例如推理结果的JSON结构定义、跨语言调用的技术选型（ProcessBuilder vs gRPC）、前端拉流组件的集成方案等。解决方式包括：参考同类开源项目的设计方案；进行小范围技术验证（编写Demo测试不同方案的可行性）；通过集体讨论对齐需求，明确设计边界。

  1. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

运用了UML工具绘制架构图、类图和流程图，帮助团队明确模块间的关系和数据流向，效果显著；使用Postman进行接口测试，确保API的正确性；部分核心模块（如推理管道）编写了简单的单元测试，验证关键逻辑的准确性。但未采用TDD开发模式，单元测试的覆盖度较低（主要覆盖核心推理逻辑），工具的应用集中在设计和接口测试阶段。

  1. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

产生Bug最多的功能是跨模块集成相关功能，如Java调用Python脚本、FFmpeg推流与ZLMediaKit对接、MinIO文件上传与RocketMQ消息推送的联动。原因是多技术栈集成的细节复杂，不同模块间的接口格式、环境依赖、数据流转容易出现不兼容问题。发布后发现的重要Bug包括：多任务并发时GPU内存占用过高、高分辨率视频推理延迟超标、低版本Chrome浏览器按钮无响应。未想到这些情况的原因是：初期性能测试仅针对单任务场景，未充分模拟高并发场景；对不同浏览器的兼容性测试覆盖不够全面；对高分辨率视频的推理性能评估不足。

  1. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

通过GitHub Pull Request进行代码复审，核心成员负责审核功能分支的代码，重点检查代码规范、逻辑正确性、接口兼容性。制定了统一的编码规范（如变量命名、注释格式、文件组织结构），并在团队内部同步。但代码复审的严格程度存在差异，部分非核心模块的代码规范执行不够严格，后期通过集中整改优化了这一问题。

我们学到了什么? 改进方向：设计阶段应加强对多技术栈集成细节的考量，提前进行技术验证，减少后期集成的Bug。应扩大单元测试的覆盖范围，针对核心模块和易错逻辑编写更全面的测试用例；严格执行代码复审流程，通过自动化工具（如代码规范检查工具）辅助规范代码格式，同时建立Bug复盘机制，总结高频Bug的产生原因并优化设计和开发流程。

六、测试/发布

  1. 团队是否有一个测试计划？为什么没有？

有完整的测试计划，明确了测试范围、目标、策略、人员分工和阶段安排。测试计划覆盖功能测试、性能测试、兼容性测试、稳定性测试、接口测试等维度，为测试工作提供了清晰的指导。

  1. 是否进行了正式的验收测试？

是的。按照测试计划的要求，在Alpha版本完成后进行了正式的验收测试，针对核心功能（模型管理、任务调度、告警推送等）、性能指标、兼容性、稳定性等进行了全面验证，通过测试用例覆盖核心场景，确保系统满足出口条件。

  1. 团队是否有测试工具来帮助测试？

有使用基础的测试工具，如Postman用于接口测试、Jmeter用于性能测试、GPU-Z用于GPU资源监控、ELK用于日志分析。但未使用自动化测试框架（如Selenium、PyTest），功能测试主要依赖人工执行测试用例，效率有待提升。

  1. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

通过收集系统运行日志中的FPS、推理延迟、CPU/GPU占用率等指标，结合Jmeter的性能测试结果，测量软件效能；通过Bug管理工具跟踪缺陷的发现、修复和回归情况。测试工作非常有用，共发现13个Bug，其中8个已修复，有效提升了系统的稳定性和可用性。改进方向：引入自动化测试工具，编写自动化测试脚本覆盖核心流程，提升测试效率；增加长期稳定性测试（如72小时高负载运行）的频次，提前发现内存泄漏、性能衰减等问题；优化性能测试场景，模拟更接近实际使用的高并发、高分辨率视频输入场景。

  1. 在发布的过程中发现了哪些意外问题？

发布过程中发现的意外问题包括：部分特殊格式（hls）视频流接入后推理卡顿；Edge浏览器中视频实时播放画面偶尔闪烁；Web页面在高分辨率屏幕下布局错乱。这些问题均在发布前的兼容性测试和性能测试中发现，并通过优化视频解码逻辑、调整前端样式适配方案等方式修复。

我们学到了什么? 改进方向：测试工作应更注重场景的全面性，覆盖不同视频格式、浏览器、屏幕分辨率等场景；结合自动化测试工具和人工测试，提升测试效率和覆盖度；将性能测试和兼容性测试贯穿整个开发过程，避免后期集中暴露问题。

总结

1. 团队目前的CMM/CMMI档次：二级

团队已建立基本的项目管理流程，包括计划制定、需求管理、变更控制、测试计划等，能够跟踪项目进度和产品质量，但过程规范的执行一致性有待提升，部分流程（如代码复审、自动化测试）尚未完全固化。

2. 团队所处阶段：规范阶段

团队已完成成员分工、角色定位和流程制定，核心工作流程（如Git协作、冲刺管理、测试流程）已趋于规范，成员间协作顺畅，能够有效应对开发过程中的技术难点和变更需求，具备持续优化的基础。

3. 目前最需要改进的一个方面：技术栈集成的深度预研与自动化测试落地

团队在多技术栈协同（Java+Python+TensorRT+ZLMediaKit）的细节处理上仍存在不足，导致部分技术难点延误进度；同时自动化测试覆盖度低，依赖人工测试影响效率和测试质量。后续需加强技术预研阶段的深度，针对集成难点提前验证；引入自动化测试框架，编写核心流程的自动化测试脚本，提升测试效率和系统稳定性。

贰、照片

image

叁、Alpha阶段的角色和具体贡献

姓名 角色定位 Alpha阶段具体贡献 团队贡献分
梁子恒 模型转换负责人 1. 完成PyTorch→ONNX→TensorRT全流程转换；
2. 实现FP32/FP16/INT8多引擎适配，验证模型精度；
3. 整理模型转换脚本与版本管理文档		 98
程炜东 模型管理&推理接口开发负责人 1. 设计推理接口REST API，解决Java调用Python环境问题；
2. 统一推理入参/结果格式，开发错误处理与超时机制；
3. 主导全流程联调，验证接口-推理-结果封装连通性		 95
曾子轩 视频流处理&推流负责人 1. 实现RTSP/本地流读取与帧预处理；
2. 解决推理结果渲染对齐问题，完成FFmpeg推流与ZLMediaKit对接；
3. 开发流断线重连逻辑		 84
黄昌龙 环境部署&Docker化负责人 1. 配置CUDA/TensorRT环境，解决版本兼容问题；
2. 搭建Python虚拟环境与Spring Boot项目；
3. 编写Dockerfile，实现多环境镜像构建与GPU资源映射		 86
刘江浩 Vue控制台界面负责人 1. 集成ZLMediaKit拉流组件，实现视频播放；
2. 开发推理结果动态渲染与任务控制交互；
3. 搭建页面布局，完成基础UI与状态提示
4. PM		 96
罗锐楚 结果存储&异步上报负责人 1. 规范推理结果JSON格式，完成MinIO存储与RocketMQ上报；
2. 开发历史记录查询接口，优化异步流程一致性		 83
阮洪建 ONNX/TensorRT推理管道负责人 1. 开发推理前/后处理pipeline；
2. 适配多TensorRT引擎，开发性能统计工具；
3. 输出推理管道性能优化报告		 85
posted @ 2025-12-24 20:59  刘江浩  阅读(6)  评论(0)    收藏  举报