[T.13] 团队项目:Alpha 阶段项目总结
[T.13] 团队项目:Alpha 阶段项目总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 首页 - 2025年春季软件工程(罗杰、任健) - 北京航空航天大学 - 班级博客 - 博客园 |
| 这个作业的要求在哪里 | [T.11] 团队项目:Alpha 阶段发布说明 - 作业 - 2025年春季软件工程(罗杰、任健) - 班级博客 - 博客园 |
| 我在这个课程的目标是 | 作为团队完成一个完整的软件开发流程,学习软件工程与软件开发相关流程和技术 |
| 这个作业在哪个具体方面帮助我实现目标 | 总结 Alpha 阶段项目工作和成果 |
设想和目标
我们的软件旨在解决新主楼室内的室内导航问题,在选题和需求分析中,我们对于问题的定义和认识较为清晰,对于我们要实现的软件的主要功能也有较为统一和成熟的认识,对于典型用户和典型场景也有了清晰的界定和描述。
对于我们在功能规格说明书中所设定的三个目标功能,我们都基本按原计划完成,只是由于部分技术问题将预设功能进行了小的调整,整体在功能上完成度比较高,在导航地图等功能的用户体验上还可以更进一步。对于原计划达到的用户数并没有达到预期,主要原因在于发布时期遇到了域名申请迟迟不成功的问题,影响了准时的发布,相应的推广和用户量也收到了影响。但用户对于我们产品的导航功能的接受程度与我们的预想一致,获得了绝大部分用户的认可和支持,确实为用户在新主楼内的学习生活提供了些许的便利,这也是我们的最初目标之一。
在设想和目标部分我们完成的较好,只是在用户体验和美工的设计上有所欠缺,如果历史重来一遍, 我们会在地图的展示形式和界面的设计上花更多的时间,优化地图和导航的展示形式设计,提升用户的使用和操作体验。
计划
我们在 Alpha 阶段的早期有相对充足的时间做计划,团队通过线下会议和线上文档协同方式确定开发进度安排。对于意见不一致的问题,我们采取讨论投票制,并尊重核心负责人的技术判断,避免无谓拉扯。
我们的任务交付件定义较清晰,每项开发任务都绑定了具体功能页面、接口、地图文件或文档等输出。但项目过程中最大的意外是域名备案和部署问题影响了上线计划,这是我们早期未充分估计的外部依赖风险。对此,将来我们会更明确设置缓冲区,并对外部因素如网络服务申请设定更早的启动时间,以避免上线延误。
资源
总体上我们具备完成任务的资源,前后端开发力量比较充足。但在地图数据采集和标注部分力量较为薄弱,时间预估方面存在偏差。最后的测试阶段没有得到足够的重视,时间和人力同样略显不足。各项任务所需的时间和其他资源的估计主要通过经验进行判断,没有经验的地图数据标注等任务则通过小规模尝试来估计任务时长,整体估计与实际耗时基本一致,精度满足了估计的需要。
如果历史重来一遍,我们的资源评估可以更精确,在诸如UI设计、地图数据采集和标注、测试等非编程任务上足够重视,合理分配时间与人力。
变更管理
我们通过微信群和飞书文档进行变更同步,保证每位成员都及时知情。对于推迟和必须实现的功能,我们会在每日例会中讨论并评估对核心流程的影响,依据优先级做出调整。
我们为每次迭代设置明确的“完成”标准,如功能稳定、接口通顺、无关键性 bug。对于大的变更,我们没有事先准备应急计划,在出现成员时间问题无法完成任务时,其他成员虽有相互推诿,但最终确定任务分配后都完成了相应的工作,减少了时间上的浪费。如果历史重来一遍,可以在应急计划和变更响应机制上进行改进,形成标准流程。
设计/实现
设计阶段在项目早期由核心开发成员主导完成,时间上略早于编码,确保了基础架构的清晰。设计中难免存在模棱两可的情况,尤其是UI的设计有着很多不确定性,在面对设计不确定性时,我们尽量将设计做的足够清晰,同时在开发过程中根据开发情况进行补充,保证最终的完成效果。
实现过程中前端界面和微信登录的功能相关模块产生 Bug 最多,主要原因来自对微信小程序前端代码和框架的不熟悉。如果历史重来一遍,可以更加重视初期架构设计的合理性,同时及时跟进代码的检查和单元测试。
测试/发布
我们在开发过程中制定了基本的测试计划来进行前后端任务的单元测试,并设置了功能验收标准,虽然未形成正式文档。验收测试由团队成员轮流执行,覆盖主流程,但缺乏压力测试和性能指标测试。
测试工具以手工测试为主,效率低。计划在 Beta 阶段引入自动化工具进行 CI/CD 相关测试和性能测试并生成测试报告。性能测试环节基本缺失,需要在后续加入定量指标分析。
发布过程中域名申请受阻是主要问题,影响上线时间。如果重来一遍,我们会更早做部署准备,提前排除发布过程中的困难。
团队的角色,管理,合作
团队角色由技术能力与个人兴趣分配,基本实现人尽其才,成员间互帮互助,协作氛围良好。当出现协作冲突如任务延期、代码合并冲突等,大家都能通过例会等线下线上方式快速讨论、明确责任人并迅速调整计划。
总结
在回顾 Alpha 阶段的工作时,我们发现团队已在室内地图展示、路径规划与实时定位三大核心功能上取得了令人满意的进展:系统整体流程走向规范,基本达到了 CMMI Level 2 的管理水平;敏捷迭代机制初见成效,每次发布都能交付可用软件,并迅速响应用户反馈。然而,我们也意识到手工测试占比过高,部分边界用例未能覆盖,导致在极端场景下出现偶发的路径偏差;用户体验方面,地图界面与操作流程的精细度尚有不足;同时,因为低估了域名备案和部署配置的外部依赖风险,上线节奏被动放缓,影响了预期用户增长。
进入 Beta 阶段,我们不再满足于仅靠人工验证系统的稳定性,而是计划在后端和前端同时引入自动化测试框架;在性能方面,我们将引入压力测试工具,对路径规划接口进行响应时延与并发吞吐量的量化评估。与此同时,团队将完善 CI/CD 流水线,利用 GitHub Actions 实现代码提交即构建、测试与灰度部署,确保每一次改动都有清晰、可溯的发布记录并能快速回滚。
为了更好地理解和服务用户,我们将在客户端埋点用户行为数据,搭建简易的数据仪表盘,用以监测日活、导航启动次数及路径偏差率等核心指标,并结合定期的可用性测试,不断优化地图界面与交互流程。此外,项目管理方式也将进一步精细化——通过看板工具对任务进行燃尽图监控,结合阶段性回顾会议及时总结经验,确保风险早揭示、进度早预警;文档方面,团队已经约定在每次迭代结束前更新需求说明、接口文档与部署手册,并通过内部分享将各自积累的技术细节与教训传递给所有成员。
总而言之,Beta 阶段的目标不仅是提升程序本身的健壮性和易用性,更要完善软件工程的各个环节,让自动化测试、持续集成与数据驱动决策成为我们常态化的工作方式,为下一阶段乃至未来的迭代打下坚实基础。
总结会集体照

浙公网安备 33010602011771号