[T.13] 团队项目：Alpha 阶段项目总结

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[T.13] 团队项目：Alpha 阶段项目总结
我在这个课程的目标是	掌握软件工程的核心技能，提升开发效率与项目质量
这个作业在哪个具体方面帮助我实现目标	总结Alpha阶段的任务

设想和目标

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

是的，我们的小程序旨在高效促进用户组队的多功能平台，主要目标是为用户在多个领域（如学习、娱乐、生活等）提供精准的伙伴匹配服务。

我们预设了小程序的典型用户和典型场景：大学生进行课程大作业组队，想要高效、精准地匹配到具有相似课程需求和学习风格的同学。

2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

α阶段计划的功能完成；

实际交付时间比计划交付时间稍有延迟；

原计划用户数量未达到。

3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

用户量未达到我们的预期，我们小程序目前的宣传环节还存在不足，后续需要优化；

用户对重要功能的接受程度和我们事先的预想一致，此外，在核心功能——组队完成的基础上，我们针对我们的典型用户（北航学生）设计了一些服务性功能，目前用户对核心功能和服务性功能的接受程度较高；

总的来说，我们离目标越来越近。

4.有什么经验教训? 如果历史重来一遍,我们会做什么改进?

在设计讨论阶段，应该将目标确定的更清晰一些，我们初期的设计其实存在一些模糊点，这在中期对开发造成了一些阻碍。

计划

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

是的，我们组作业启动时间较早，有着充足的时间做计划。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

在团队会议出现不同意见时，我们会让不同意见的持有者给出他们的持有该观点的原因，然后所有组员一起协商，得出最终结论。如果还是存在分歧，我们会让组内大佬进行拍板。

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

基本完成。

“基本”在于前端，因为前端开发细节较多，同时我们的前端开发任务安排做的不够理想，前端的功能都实现了，但是像接口检查、图像上传和显示等一些细节工作前端做的不够完善。

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

在博雅课程部分，由于一开始没有弄清楚微服务架构，博雅部分的数据库与主服务器的数据库存在一定的重复部分

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

有的，我们每周在团队会议的最后，都会明确安排下周需要完成的任务，交付件的样式和需要完成的功能都有清楚的定义。

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

项目整体的进展大体按照计划进行，在开发的中间前端由于课业等问题出现了未达成本周任务的情况，但都在下一周及时补上；

项目在发布时出现了一些意外，我们没有预想到微信审核在五一假期会放缓，导致我们在五一测试完成后的正式版本没能及时发布，影响到了课堂展示的效果。出现该意外是因为小组成员都是第一次进行微信小程序开发，对审核的具体时间没有大致的估计。

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

有的，我们开发截止时间比中期检查提前了一周。

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

首先，在后续计划中，我们会对终期目标进行更详细的讨论，对于最终成品要有更加清晰的定义，这样便于我们进行阶段化的任务安排；

其次，对于任务安排，我们应该进行详细地记录，明确哪些任务由哪位组员完成，这样在细节方面就不会遗漏；

最后，对于一些新接触的方面，例如微信审核，要进行早期的调研，避免出现时间冲突的风险。

9.我们学到了什么？如果历史重新来一遍，我们会做什么改进？

首先，小程序版本发布方面，由小组PM确定具体时间点，避免出现类似的审核未通过情况；

其次，接口设计方面，应该采用：前端先本地mock，确定需要的接口功能（返回值），再由后端开发出所需的接口。

资源

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

硬件资源例如服务器，有课程组的支持，租了一个性能适合的服务器；

软件资源的话前后端开发的工具链都适配成功，这方面也没有遇到问题；

人力资源的话我们小组有6个人：3前端+2后端+1管理端。每个组员的任务量也在合适的程度。

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

首先，前端是根据板块的页面数量进行时间估计，根据板块的页面数量以及每个页面预估要使用的接口数量和实现功能进行时间估计，精度较高；

其次，后端是将需要开发的接口数量做为主要依据，同时考虑一些服务性功能的学习成本，来进行时间估计，考虑到学习时间不好预估，所以精度一般。

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

测试的各项资源是足够的，对于不需要编程的资源，考虑到主观因素影响较大，我们在测试的时候确实遇到了一些阻碍，没有比较合适的评判标准来帮助测试。

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

因为小程序最终各个页面的可以进行跳转，在最终合并的时候，前端开发的同学要进行相同的一些处理（例如添加页面的跳转路由等），这些问题其实由一个人来处理可以大大降低其它同学的学习成本。

5.有什么经验教训? 如果历史重来一遍,我们会做什么改进?

开发人员分配不是很合理，如果重来一遍，前端分配的开发人员可以适当减少。

变更管理

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

是的，我们会通过微信群进行消息通知。

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

在这次团队开发中，如果某项任务独立性较强，那么可以判定为“可推迟”功能，如果某项功能会影响到其他组员相关功能的实现，那么就判定为“必须实现”的功能。

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

对于某项任务是否完成，我们关注点是功能是否完成，需要在真机模拟配合前端进行初步功能测试，通过了真机模拟的使用，就可以判定为“做好了”。

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

在项目开发的第一次发布阶段，前端部分功能还未完成，我们制定了相应的应急计划，调配多名组员一起开发未完成部分，最终在大家的合力下及时通过第一次发布。

此外，在最终发布阶段，我们发现了一些影响展示的ui和服务器适配bug，我们组织了紧急的线下开发，组员们通宵解决了bug，没让其影响最终发布和验收。

5. 员工是否能够有效地处理意料之外的工作请求？

大家在团队会议的时间段都预留好了足够的时间，正是因为提前的时间预留，才能有足够的时间制定应急计划，去处理这些突发的问题。

6.我们学到了什么？如果历史重新来一遍，我们会做什么改进？

需要预留处理突发情况的时间，在项目验收前至少一星期就得开始确定正式发布版本。

设计/实现

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

设计工作我们是组员给出自己的提案，由大家进行审评，最终一起得出设计的总框架，而工作的具体细节则是由负责该部分的同学自行发挥；

设计的时间是非常合适的，我们划分了很多阶段，每个阶段都要对设计工作进行讨论、修改、完善；

设计工作是大家一起参与，集思广益。

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

有的，例如在前端开发时，对于接口的返回值展示存在不清楚的地方，这种情况下我们是开发同学自行设计展示效果，并在下一次团队会议中进行展示并提出不清楚的地方，大家审评开发同学自行设计的展示效果并提出意见。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

我们前后端都采用了单元测试，并采用了一些专用的测试工具进行多种类型的测试。

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

服务性功能出现的bug较多，例如课程服务和博雅服务，因为这些服务涉及到的技术点较多，将这些技术联动起来容易遇到问题，此外还涉及到服务器部署问题，需要解决服务器容易崩溃的问题。

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

我们组在这方面的工作有待改善，代码审查工作进行的不够好，代码规范的执行靠组员自觉，不过我们在开发初期就制定了代码规范，例如组件封装等等，因此最终的发布版本代码规范较好。

6.我们学到了什么？如果历史重新来一遍，我们会做什么改进？

在开发过程中，我们最早对项目微服务的划分方案存在问题，导致最后移除了最早设计的邮件服务，新增了消息中心模块。博雅模块在接入时，由于语言不同导致花费大量时间在Django和SpringCloud的接入上。

如果重新来一次：

1. 我们会在系统设计上花更多时间，并在正式开发前写一个小demo，验证方案的可行性
2. 提前引入Sential进行接口限流和微服务保护
3. 前端和后端通过Mock提高开发效率

测试/发布

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

团队的测试计划较为简单，每个组员负责测试自己开发的部分。

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

是的，在α阶段课堂展示前的最后一次团队会议我们进行了正式的验收测试，确保展示不会出现问题。

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

很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

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

我们使用Jmeter软件对我们的产品进行了压力测试，确保服务器能够在不影响使用体验的情况下及时地进行响应。

从我们进行压力测试的结果来看，在系统并发量时，服务器的CPU利用率和内存使用量都出现了一定的升高，但此时系统的负载仍在可以承担范围内，在压力测试下表现优秀。

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

一是微信小程序需要使用https而不是http，因此在发布前我们修改了这一方面；

二是微信小程序发布审核时间较长，导致未能按照预期的时间进行发布。

6.我们学到了什么？如果重新来一遍，我们会做什么改进？

我们小组重视开发，对测试的计划不够完善，没有系统性的进行测试的安排，如果重来一遍，我们应该在开发的最后一次会议中，对测试任务进行详细地讨论与安排，配合发布和验收的时间节点进行测试任务的安排。

团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

在第一次团队会议时，我们每个人都介绍了自己擅长的技术栈，依据各自擅长的技术栈进行分工，做到人尽其才。

2. 团队成员之间有互相帮助么？

大家遇到开发上的问题时会在团队会议或者微信群中进行分享，其他组员会积极地给出解决建议或方案。

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

我们会在固定的线下团队会议之外，开展一些额外的线上讨论或者小规模的线下会议，来解决项目管理、合作方面的问题。

总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

可重复级：建立了基本的软件管理过程

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

规范

你觉得团队在这个里程碑相比前一个里程碑有什么改进?

@丁子航 ：团队协作更加熟练

@高子贺 ：团队沟通效率更加高效，代码管理更加规范

@安琦 ：微服务对接更加顺利

@饶晨烜 ：建立了完整的日志系统，提高了异常排查效率

@张珺强 ：团队分工更加明确，提升了开发效率

@袁耀武 ：团队沟通效率更流畅

你觉得目前最需要改进的一个方面是什么?

@饶晨烜 ：开发速度比较慢，前端和后端没有通过Mock，严重影响了开发进度

@高子贺 ：网页端测试不全面

@安琦 ：测试效率较低

@张珺强 ：开发速度有待提高，测试不够充分

@丁子航 ：任务分工需要更加详细具体

@袁耀武 ：测试不全面

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

@饶晨烜 ：建立CI/CD，提高开发部署效率

@丁子航 ：遇到bug及时通知与回复，有紧急情况开线上会议解决

@袁耀武 ：出现问题及时沟通

@高子贺 ：开发过程中沟通及时

@安琦 ：频繁开会，实时沟通进度

@张珺强 ：团队频繁沟通，及时传递信息

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

代码管理质量可通过制定团队统一的编码规范并考虑借助自动化工具检查，同时强化代码复审流程，要求每段代码必须经过至少一人评审才能合并，结合Checklist确保关键问题不被遗漏。

2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

持续重构，每次聚焦一个具体问题（如重复代码或耦合模块），并确保有足够的单元测试覆盖；衡量指标可包括代码复杂度、模块耦合度，考虑通过一些工具（如SonarQube）量化跟踪改进。

3. 其它软件工具的应用，应该如何提高？

@安琦 ：针对postman的使用，可以使用 Environment 管理测试环境，避免手动修改url。同时可以在Tests 标签中添加断言代码，检查字段值是否正确，提高对接口稳定性与正确性的检测。

@饶晨烜 ：熟悉github的Issue使用，方便进行项目进度管理

@丁子航 ：熟悉微信小程序开发的工具链和git的操作，避免在开发的时候被工具的使用影响进度

@袁耀武 ：熟练使用uniapp,Hbuilder,微信开发者工具一整套工具链，采用git进行团队开发，利用微信开发者平台及时配置并发布

@高子贺 ：熟悉vue构建工具

@张珺强 ：熟悉微信小程序开发的系统工具链，提高开发效率

4. 项目管理有哪些具体的提高？

首先，代码管理方面，前端的代码分支管理需要改进，dev分支和main分支要明确区分；

此外，前端commit不够规范，后面也需要规范化；

我们确实专门的同学来负责项目管理，项目管理的规范靠制定的项目规范文档和组员自觉，没有强制的检查。

5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

计划增加用户数据记录维度，我们通过收集接口调用数以及对应用户信息来计算每日/周活跃用户等数据。

6. 项目文档的质量如何提高？

我们目前项目文档时采用统一模板，文档格式统一，但是文档内容没有确定规范，后续我们应该对文档的内容部分也制定规范文档，进一步提高项目文档质量。

7. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

我们要明确领导者和成员的身份，并对团队会议的流程要进一步优化，提高团队会议的效率。

8. 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)

经典软件工程理论在现代实践中仍具重要指导意义：《人月神话》提出的Brooks定律指出，项目后期盲目增加人力反而会因新人适应期和沟通成本指数增长而降低效率，这一规律在复杂系统开发中持续得到验证；同时其"概念完整性"原则强调系统设计应由少数核心人员主导，这一理念在现代开源社区（如Linux采用的BDFL模式）中仍被成功实践。《构建之法》倡导的敏捷开发方法中，持续集成通过高频构建显著降低后期调试成本，但需要结合现代DevOps工具链实现自动化；而"欲速则不达"的工程智慧体现在：前期在需求分析和架构设计上多投入一周时间，往往能避免后期一个月的返工，特斯拉Autopilot团队就曾因跳过需求评审而付出沉重代价。此外，工具选择应当务实而非盲目追新，正如"没有银弹"理论所示，微服务等"先进"架构可能增加不必要的复杂性，初创公司采用单体架构（Monolith）反而可能获得更高效率，这提醒我们技术选型必须与团队实际能力相匹配。

照片