事后诸葛亮报告

设想和目标

  1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
    FeatherChat 旨在解决低配置设备用户在使用主流聊天工具时因性能不足导致的卡顿问题，提供轻量化的文字和图片交流功能。目标定义清晰，典型用户是使用老旧手机或低配设备的学生、预算有限的用户，典型场景是用户在多任务或设备资源不足时仍能流畅聊天。
  2. 我们达到目标了吗？
    • 功能完成度：核心功能（文字聊天、图片分享）已实现，但部分优化功能（如消息加密、离线消息同步）未完成。
    • 交付时间：按原计划提交了作业，但未进行实际部署。
    • 用户数量：未正式发布，仅在小范围测试，用户量为同学和测试人员（约10人）。
  3. 用户对重要功能的接受程度和预期一致吗？
    测试用户反馈文字聊天流畅，但图片加载速度受设备性能影响较大，与预期“低配设备流畅使用”存在差距。目前离核心目标更近一步，但需进一步优化性能。

计划

  1. 是否有充足的时间做计划？
    初期计划时间充足，但开发中因技术问题（如跨设备兼容性）频繁调整任务优先级，后期计划较为仓促。
  2. 如何解决团队成员对计划的分歧？
    通过讨论优先级和可行性，例如：投票决定优先完成核心功能（文字聊天），再处理附加功能（图片压缩算法）。
  3. 原计划工作是否全部完成？未完成的原因？
    • 未完成功能：消息加密、多设备同步、离线消息存储。
    • 原因：技术实现复杂度高（如加密算法学习成本）、时间不足。
  4. 是否做了不必要的事？
    花费大量时间尝试实现“聊天背景主题切换”，后发现此功能对低配设备用户意义不大，最终放弃。
  5. 任务是否有明确的交付标准？
    文字聊天功能需支持实时收发和消息记录存储，标准清晰。
  6. 项目是否按计划进行？遇到的意外风险？
    • 意外：低配设备测试时发现图片传输导致内存溢出，需紧急优化压缩算法。
    • 未预估风险：不同设备的屏幕分辨率适配问题，因测试覆盖不足未提前发现。
  7. 是否设置缓冲区？
    未明确设置缓冲区，后期因功能调整导致部分成员加班。
  8. 未来计划改进
    增加10%-20%的时间缓冲区，拆分任务优先级（核心功能强制预留时间）。

资源

  1. 资源是否充足？
    团队共8人，人力完全充足，但缺乏硬件测试设备（依赖模拟器和同学旧手机）。
  2. 任务时间估算是否合理？
    简单功能（如UI布局）估算较准，复杂功能低估了50%时间。
  3. 测试资源是否足够？是否低估非编程资源难度？
    测试设备不足，文案和UI设计未分配专人，导致界面风格不统一，后期返工。
  4. 任务分配效率？
    程序开发经验不是特别足，学习成本高；若有经验可节省30%时间。

变更管理

  1. 变更信息是否及时同步？
    通过群聊和例会同步变更，但因部分成员未及时查看消息，导致开发分支冲突。
  2. 如何决定功能优先级？
    根据用户核心需求（流畅性＞附加功能），推迟消息加密，优先修复内存溢出问题。
  3. 项目出口条件是否明确？
    定义为“完成文字聊天和图片分享功能，并通过低配设备测试”。
  4. 是否有应急计划？
    未制定，遇到问题时临时调整任务（如压缩算法改为调用开源库）。
  5. 成员能否处理突发任务？
    简单任务（如UI调整）可快速响应，复杂问题（如内存优化）需团队协作解决。

设计/实现

  1. 设计工作由谁完成？是否合理？
    架构设计由后端成员主导，界面设计由前端成员协作完成，时间分配合理。
  2. 如何解决设计歧义？
    例如图片传输协议选择时，通过对比HTTP和WebSocket的优缺点，最终采用WebSocket保证实时性。
  3. Bug最多的功能及原因？
    • 图片分享：因未统一压缩参数，部分设备显示异常。
    • 未发现的Bug：消息记录在断网时偶发丢失，因测试环境网络稳定未覆盖此场景。
  4. 代码复审是否规范？
    代码复审执行较为严格，但代码规范执行有待加强。

测试/发布

  1. 是否有测试计划？
    有，覆盖功能测试（收发消息）和性能测试（内存占用≤50MB）。
  2. 是否进行正式验收测试？
    是，模拟低配设备（1GB RAM）运行，发现3个关键Bug并修复。
  3. 测试工具使用情况？
    使用JUnit进行单元测试，Postman模拟API请求，但未引入自动化测试工具。
  4. 发布时的意外问题？
    未正式发布，但演示时因依赖库版本冲突导致程序崩溃，需重新打包。

团队角色与管理

  1. 角色分配是否合理？
    按技术专长分配（如擅长Java的负责后端），但测试角色由前端兼任，经验不足。
  2. 成员间协作情况？
    后端协助前端优化数据请求逻辑，测试成员提供设备调试支持。
  3. 如何解决合作问题？
    通过每日站会同步进度，明确“当天问题当天解决”原则，减少拖延。

总结

  1. 团队当前阶段：规范阶段，流程清晰但灵活度不足。
  2. 当前最需改进：风险预估与时间管理，如提前规划技术预研。
  3. 相比前一里程碑的改进：沟通效率提高，代码冲突减少50%。
  4. 符合敏捷原则的最佳实践：
    • 业务与开发人员协作。产品设计阶段多次与测试用户（同学）沟通需求。
    • 可用的软件是首要目标。优先保证核心功能完整，而非过度追求代码完美。

团队成员在Alpha阶段的角色和具体贡献

姓名 角色 团队贡献分 可验证的贡献
黄峻声 PM（项目经理） 20.8 负责项目的整体规划和进度跟踪，组织每日会议，编写接口文档。
魏杰宗 后端开发 21.6 负责后端核心功能开发，实现了部分业务逻辑，设计了部分接口。
郑邦洲 后端开发 21.6 开发了核心业务逻辑，负责了接口的实现，完成了许多模块的开发。
林佳俊 测试 18.0 实现了集成测试，发现了不少bug，提高了系统的稳定性。
蔡宜桓 测试 18.0 设计了测试计划，编写了单元测试，确保了服务器的稳定性以及可靠性。
庄楷彬 前端开发 21.0 负责前端开发，实现了消息实时推送功能，优化界面效果。
覃锴锋 前端开发 21.0 设计了用户界面，优化了用户的使用体验，提高了兼容性。
廖唯宇 文档管理 18.0 负责汇总每天团队的成果，编写相关博客，同时负责用户体验测试。
posted @ 2025-05-18 21:41  peter456963  阅读(25)  评论(0)    收藏  举报