| 这个作业属于哪个课程 | 计科23级34班 |
|---|---|
| 这个作业要求在哪里 | 团队作业6——复审与事后分析 |
| 这个作业的目标 | 完成事后诸葛亮会议报告 |
| Alpha阶段项目复审报告 | https://www.cnblogs.com/Nyanya--/p/19394808 |
| github仓库链接 | https://github.com/Bookmatescope/ReuseBook |
Alpha阶段事后诸葛亮会议报告
书海拾贝队
- 杨浩 - 3123004462
- 刘霆浩 - 3123004451
- 戴宏翔 - 3123004435
- 莫圣韬 - 3123004456
- 赖顺炜 - 3123004441
- 陈东楷 - 3123004433
📷 全组照片
一、设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件要解决校园二手书交易中存在的三个核心问题：信息不对称（买卖双方难以找到对方）、交易不便捷（传统贴吧、QQ群方式效率低）、安全无保障（缺乏规范交易流程）。问题定义比较清楚，我们明确了典型用户（大学生买家和卖家）和典型场景（毕业生清理书籍、新生购买教材），并在需求规格说明书中有详细描述。通过面交模式解决安全问题，通过ISBN智能查询解决信息录入问题。
-
我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？）
基本达到目标。原计划的核心功能全部完成，包括用户注册登录、书籍发布、购物车、订单管理、评价系统等6大模块。
-
用户量、用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？
Alpha版本主要进行内部测试，尚未对外发布。从测试反馈来看：ISBN智能查询功能超出预期，大大减少了用户录入工作量。
经验教训： 如果历史重来一遍，我们会在项目开始前进行更多的用户调研，与潜在用户充分沟通，并将典型使用场景转化为具体的验收测试用例，避免开发过程中需求理解偏差。
二、计划
-
是否有充足的时间来做计划？
有时间做计划，但由于团队成员对前后端分离开发不够熟悉，很多计划是在开发过程中边做边摸索调整的，不够完善。
-
原计划的工作是否都做完了？如果有没做完的，为什么？
大部分工作完成了。即时通讯功能没有完成，原因是Alpha阶段时间紧张，且即时通讯需要WebSocket技术支持，复杂度较高。我们决定用邮箱联系作为临时替代方案，将此功能推迟到Beta阶段。
-
有没有发现你做了一些事后看来没必要或没多大价值的事？
有。购物车的数量加减按钮对二手书（每本书是唯一的）意义不大，后期移除了；过早进行前端性能优化（如虚拟滚动），实际上Alpha阶段书籍数量不多，没有必要。
-
是否每一项任务都有清楚定义和衡量的交付件？
大部分任务有清楚定义。代码提交到GitHub是明显的可衡量交付件，我们通过Issues追踪任务进度。但成员在学习新技术时没有设定明确的交付件，导致学习效率参差不齐。
-
是否项目的整个过程都按照计划进行？项目出了什么意外？有什么风险是当时没有估计到的？
没有完全按计划进行。主要意外包括：订单模块的状态流转逻辑比预想复杂，工时超出预期31%；前后端接口联调耗时较多，接口定义不够严谨导致多处不一致；后端部署后才发现CORS跨域配置缺失。这些风险没有估计到。
-
在计划中有没有留下缓冲区，缓冲区有作用么？
有。我们将Day7作为收尾和缓冲日。缓冲区确实发挥了作用，用于修复最后发现的Bug、完善文档和进行最终测试。但事后看来缓冲区时间不够充分，需要增加。
-
将来的计划会做什么修改？
留下更多的缓冲区时间，预估工时增加20%的余量；在API设计阶段进行更严格的前后端评审。
经验教训： 应该在开发前明确定义每个任务的交付件和验收标准。API文档要先行设计并评审，大家坐在一起联调效率更高。下次要留更多缓冲区应对意外情况。
三、资源
-
我们有足够的资源来完成各项任务么？
基本足够。6人团队分工明确，有经验的成员负责核心架构设计。但测试人力略显不足，专职测试只有1人，导致测试覆盖不够全面。
-
各项任务所需的时间和其他资源是如何估计的，精度如何？
按小时级别进行估计，精度一般。总预估工时138小时，实际投入约160小时，超出预期16%。其中订单模块超出最多（+31%），说明对复杂功能的工时估计偏乐观。
-
测试的时间、人力和软件/硬件资源是否足够？
不太足够。服务器配置不高，并且有流量费用限制，未能进行完整的压力测试。测试时间较短，主要依赖人工测试和单元测试，缺少端到端的自动化测试。
-
你有没有感到你做的事情可以让别人来做（更有效率）？
有。让熟悉相关部分代码的人做相关工作，省去了学习时间，效率明显提高。专业的事应该让专业的人来做。
经验教训： 让擅长的人做擅长的事，合理分配任务可以大幅提高效率。下次应该预留更充足的测试资源。
四、变更管理
-
每个相关的员工都及时知道了变更的消息？
是的。我们通过微信群即时通知变更消息，同时GitHub的提交记录也让大家能够追踪代码变化。重要变更会在站会上专门讨论确认。
-
我们采用了什么办法决定"推迟"和"必须实现"的功能？
按照需求优先级和实现难度来决定。核心交易流程（注册→发布→下单→面交→评价）是必须实现的功能；即时通讯因技术复杂度高且有邮箱替代方案，决定推迟到Beta；支付功能因面交现金模式可替代，暂不计划实现。
-
项目的出口条件（Exit Criteria）有清晰的定义么？
有明确定义。出口条件包括：核心功能完成度100%、严重Bug数量为0、单元测试通过率100%、代码编译无错误、主流浏览器（Chrome/Firefox/Edge）全部支持。
-
对于可能的变更是否能制定应急计划？
能。例如发现无法解决的Bug时，可以通过Git回退到上一个正确版本；功能实现遇阻时，寻找替代方案（如用邮箱替代即时通讯）。
-
员工是否能够有效地处理意料之外的工作请求？
能够有效处理。例如Day4发现遗漏了面交地址字段，当天紧急添加完成；Day6发现购物车数量按钮冗余，及时进行了优化移除。
经验教训： 开发前应该充分讨论设计细节，对项目认识越清楚，后期变更就越少。变更管理需要更规范的流程。
五、设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作主要在Day1完成。后端架构由戴宏翔设计，他有Spring Boot开发经验，设计了清晰的模块化结构；前端架构由杨浩和刘霆浩负责；API接口由前后端成员共同讨论确定。时间和人员安排是合适的。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有遇到。例如订单状态如何流转、是否需要支付功能、图片存储方式等问题。我们通过微信群讨论解决，大家发表意见，采纳合理建议，最终达成一致。
-
团队是否运用单元测试（unit test）、测试驱动的开发（TDD）、UML或者其他工具来帮助设计和实现？
运用了单元测试，编写了50+测试用例，覆盖核心Service层，有效发现了多个Bug。TDD没有严格执行，时间紧张导致先实现后补测试。
-
什么功能产生的Bug最多，为什么？
订单状态流转功能Bug最多。原因是该功能涉及多个角色（买家、卖家）的不同操作，需要判断当前状态是否允许转换，边界条件（如已取消订单不能再操作）考虑不够周全。
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
有进行Code Review，但执行不够严格。由于时间紧张，部分代码在Review前就直接合并了。代码规范有约定（模块化包结构、统一异常处理等），但执行一致性有待提高。
经验教训： 开始设计时就要明白应该做什么、以及怎么做，避免开发过程中反复修改。要从一开始就重视测试工作，严格执行Code Review流程。
六、测试/发布
-
团队是否有一个测试计划？为什么没有？
有测试计划。包括：单元测试（覆盖Service层核心逻辑）、场景测试（3个典型用户场景）、兼容性测试（4种主流浏览器）。测试计划让测试工作更有条理。
-
是否进行了正式的验收测试？
是的。我们按照出口条件逐项进行验收测试，确保所有条件满足后才发布Alpha版本。验收测试覆盖了所有核心功能流程。
-
团队是否有测试工具来帮助测试？
有。后端使用JUnit5进行单元测试。但没有使用自动化UI测试工具，主要依赖人工测试前端功能，这是需要改进的地方。
-
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？
由于服务器资源和时间限制，未进行正式的性能测试和压力测试。测试工作整体是有用的，发现并修复了14个Bug。改进建议：Beta阶段增加性能测试和自动化测试。
-
在发布的过程中发现了哪些意外问题？
发现了CORS跨域配置缺失的问题，因为开发时前后端同域运行，没有考虑到部署后的跨域场景。还发现了静态资源路径配置问题。这说明测试环境与生产环境的差异考虑不足。
经验教训： 应该增加自动化测试覆盖，测试环境要尽量模拟生产环境。发布前要进行完整的部署测试。
七、团队角色与合作
-
团队的每个角色是如何确定的，是不是人尽其才？
角色确定主要根据自身的技能和意愿。优先让成员做自己擅长的事情，其次根据个人学习意愿分配任务。整体来说基本做到了人尽其才，每个成员都在自己负责的领域有所贡献和成长。
-
团队成员之间有互相帮助么？
有。遇到技术问题时会互相支援，例如前端遇到接口问题会找后端帮忙排查，测试发现Bug会详细描述复现步骤帮助开发定位。代码Review过程中也互相学习了不少。
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
主要通过站会沟通和微信群讨论解决。当出现分歧时，组长会协调资源、做出决策。大家态度都比较好，能够接纳合理的意见，没有出现严重的合作冲突。
八、总结
-
你觉得团队目前的状态属于CMM/CMMI中的哪个档次？
达到了CMMI二级（已管理级）。团队遵守了既定的计划和流程，有资源准备，权责到人。但还没有形成一套完整的制度化管理措施，过程改进还需加强。
-
你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段？
处于规范阶段。经过Alpha冲刺，团队成员已经相互了解，角色和职责定义清楚。我们有固定的会议机制（每日站会），有代码规范约定，有任务追踪系统（GitHub Issues）。
-
你觉得团队在这个里程碑相比前一个里程碑有什么改进？
相比项目启动阶段，改进明显：建立了每日站会机制，进度透明可控；形成了代码提交规范；建立了Issue追踪流程；团队对技术栈（React + Spring Boot）更加熟悉。
-
你觉得目前最需要改进的一个方面是什么？
测试覆盖不足是最需要改进的方面。Alpha阶段主要依赖人工测试和单元测试，缺少端到端自动化测试和性能测试。Beta阶段将重点加强测试工作，引入自动化测试工具。
-
对照敏捷开发的原则，你觉得你们小组做得最好的是哪几个原则？
- 可工作的软件是进度的主要衡量标准：每天都有可运行的版本
- 面对面交流是最有效的沟通方式：每日站会同步进度和问题
- 简洁——尽最大可能减少不必要的工作：专注核心功能，不过度设计
九、团队成员在Alpha阶段的角色和具体贡献
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
|---|---|---|---|
| 杨浩 | 前端开发 | 16 | 13个前端页面开发（登录、注册、书籍列表、详情、购物车、订单等）、UI设计、项目进度管理、每日站会组织 |
| 戴宏翔 | 后端架构 | 18 | 后端整体架构设计、Auth模块（注册登录Token）、Book模块、Order模块核心API开发、技术选型决策 |
| 赖顺炜 | 后端 | 14 | 数据层设计、Repository模式设计、User模块开发、内存存储抽象设计 |
| 刘霆浩 | 全栈/运维 | 20 | 服务器部署方案设计、Bug修复、前后端功能完善支持、项目整体质量把控 |
| 莫圣韬 | 测试 | 17 | 测试用例编写、JUnit单元测试覆盖、Bug追踪与回归测试、测试报告撰写 |
| 陈东楷 | 文档 | 15 | API接口文档(api.md)编写、用户使用手册(user-guide.md)、项目文档 |