【HelloKitty团队项目】Beta阶段反思_hellokitty合作终止-CSDN博客

本文链接：https://blog.csdn.net/HelloKittyTeam/article/details/131259936

项目	内容
这个作业属于哪个课程	2023北航软件工程
这个作业的要求在哪里	团队项目-Beta阶段反思
我在这个课程的目标是	学习软件工程技术，完成团队开发流程
这个作业在哪个具体方面帮助我实现目标	Beta阶段反思总结

一、设想和目标

我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件目标是实现一个智能化、定制化的英语学习软件，为用户提供多层面定制化的英语学习内容，多维度可维护的共享数据仓库，并通过引入ChatGPT，给用户带来多模态沉浸式的人机交互体验。
在我们的功能规格说明书中，描绘了六个典型用户以及对应的典型应用场景。这些应用场景主要突出了当前现有的英语学习软件所缺失或难以满足用户需要的地方。
我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)
在beta阶段我们的目标是完善alpha阶段中用户反馈的功能上的不足，新增更多人性化设置，旨在为用户带来更便利、沉浸的英文学习环境。我们计划实现以下功能和目标：
- 为用户提供多样化词单创建方式
- 支持用户上传个人词单至平台供其他用户学习，营造良好的社区氛围
- 单词背诵页面增加单词读音及单词搜索功能
- 为用户打造多模态的学习环境，如视听结合(发音、图片生成)、口语对话等
- 增加单词学习数据展示页面
- 解决用户希望多次使用“小助手”相关功能的需求
- 解决用户希望查看“复习模式”历史记录的需求
- 界面美化
  以上绝大多数目标我们在beta阶段按时实现，达到了预期目标，仅图片生成功能和艾宾浩斯曲线分析功能由于时间关系没有接入到网页中。
和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
与上一阶段相比，质量有所提高，理由如下：
- 组件/代码复用率提高，避免大量重复性工作
- git提交记录中，bug修复(fix)提交相较于上一阶段数量减少
- 前后端对接过程相较上一阶段更加顺利，这得益于团队成员熟练使用apifox
- 尽管beta阶段有很多新增功能，但数据库并没有进行大规模修改，设计一定程度上具有可扩展性
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
beta测试阶段，软件共80+人参与体验，生成了210+个用户词单，背单词功能共计1500+次、复习单词功能共计200+人次、智能对话功能共计500+人次，语音对话功能共计50次。同时，团队在Bilibili发布的宣传视频观看次数1.2万，远远高于alpha阶段。可见从用户量的角度，我们确实距离目标更近了。
另外，从用户反馈来看，用户相比于alpha阶段对我们的设计和功能更加感到惊艳，并表示愿意长期使用。大部分负面反馈主要针对于实际使用上的一些瑕疵，如卡顿、响应时间长、使用次数少，而非针对功能本身。从这个角度来看，我们的设计有所进步，更加符合用户的预期。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 时间规划上充分考虑各种因素：由于本学期烤漆持续时间较长，前前后后有近一个月在进行各种考试。这导致实际开发时间与预期相对紧张，最终有少量非核心功能没有实现。
- UI风格统一：由于最初进行UI设计并没有严格规定一些细节（颜色、尺寸等），后续会花更多时间进行调整，出现一些重复性的工作。

二、计划

是否有充足的时间来做计划?
Beta阶段正好与我们的期末复习周重合，所以和Alpha阶段相比，大家时间都比较紧张。但是我们仍然坚持了每两天的例会与Scrum Meeting，以同步当期的进度，并规划下一阶段的任务，最终保证有充足时间完成Beta阶段的开发。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
如果遇到不同意见，我们会直接尽心沟通交流，如果是比较重要的意见，我们会在每两天的例会上与所有组员一起讨论，大家各自表达观点，最终综合所有人的意见得到结论。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- lzh：未对用户输入进行敏感词过滤。alpha阶段的测试中发现gpt本身会对敏感词进行一定过滤，并且beta阶段时间较为紧张未进行全局过滤。
- lyq：未增加通过单词生成图片的接口。布局写好，但是由于组件不熟练、图片显示方式有问题，没写好。
- xzh：数据统计部分未实现遗忘曲线功能，在这部分没有进行充足的调研和学习数据设计，最终时间有限没有完成
- wyy：未实现语法练习功能。alpha测试中发现用户对此需求并不大，加上beta阶段时间紧张，没有实现。
- ljh：原计划选做向单词本中添加单词的功能，但考虑到实现对前后端都有较多改动，且需求不大，最终没有实现。
- zya：对chatgpt相关接口仅做了普通测试，没有充分测试成功率与异常情况等等。
- zl：图片生成功能未实现。因为虽然在后端实现了文生图，但是和前段对接部分代码没有写好。
有没有发现你做了一些事后看来没必要或没多大价值的事?

大家都认为自己在Beta期间的工作是有价值的工作，没有不必要的劳动。
是否每一项任务都有清楚定义和衡量的交付件?
和Alpha阶段类似，我们是依据软件功能模块来划分绝大部分的任务，且采用前端驱动后端的开发方式，通过定义API需求来进行沟通，所以前后端的任务可以通过某一页面或者功能是否实现来进行衡量。但是也有极少数任务难以进行量化。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
是的。由于已经经历过Alpha阶段的开发，大家对于整个开发流程以及各种工具的使用已经相当熟练，因此几乎不会出现低级错误的意外发生。开发时的一个风险在于对多模态数据（如语音、图片）的传递与处理方式了解不够，导致前后端在对接相关功能时花费了大量时间去摸索试错。原因主要是当时理所当然认为加入多模态信息的难度不大，并没有充分考虑到前后端对接时的具体实现细节。
在计划中有没有留下缓冲区，缓冲区有作用么?
借鉴Alpha阶段的经验，我们有留出缓存区，为了测试上线后的各种功能，尤其是安全相关内容。此外因为Beta阶段恰好和期末考试有部分重合，所以设置了缓冲区让大家去复习考试。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
我们认为应当为计划流出充足的缓冲区，以应对各种可能发生的意外情况。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了团队合作中计划与沟通的重要性。如果重来一遍，我们在计划时不应该仅仅考虑某一个功能在前端/后端独立实现的复杂度，而应该综合分析整体实现该功能的难度，并调研具体的技术路线。此外，还应该在前端进行设计时尽早考虑跨平台开发的内容，以便在项目开始时就将不同平台的前端开发任务加入计划中。

三、资源

我们有足够的资源来完成各项任务么?
人手上，我们的人力资源足够完成我们的工作。财务上，我们因为对用户调用GPT接口做了一些限制，因此课程组给予的资金也够用。
各项任务所需的时间和其他资源是如何估计的，精度如何?
我们会在每两天一次的例会上讨论后面两天的开发任务，根据任务量和实现难度的大小对开发时间进行估计。从结果来看，精度较为准确，团队成员基本都能准时完成任务。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
开发阶段结束后，我们有一周的时间来充分进行测试，整体来看资源充足。因为团队中有一位擅长美工和文案的队员，我们在这些非编程工作上并未消耗过多的精力。
你有没有感到你做的事情可以让别人来做（更有效率）?
- lzh：感谢大家一起写团队博客，让我们每次团队博客内容都很充实丰富
- lyq：大家分工挺合理的
- xzh：分工比较合理
- wyy：没有
- ljh：分工很合理，每个人能都发挥了最大作用
- zya：分工很合理
- zl：感觉分工都蛮合理，发挥每个人特长了
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
由于前一阶段对密码的安全强度考虑不周全，因此这一阶段在发布时需要暂时关停服务器并手动修改生产环境的数据库。如果重来一遍，我们会在一开始就考虑好这方面的设计，避免出现这类问题。

四、变更管理

每个相关的员工都及时知道了变更的消息?
是的，我们采用coding文档、微信群通知与例会讨论的形式通知变更的消息，根据变更的涉及范围和具体情况选用不同的通知方式，能够使每个相关的员工及时收到变更的消息。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们会根据beta阶段的功能设计、功能的重要性与其他功能的关联性、具体实现的技术难度来决定“推迟”和“必须实现”的功能。我们会优先实现beta计划中必须添加的功能。如果这个功能实现较为复杂，但又不属于必须添加的功能，我们会根据开发进度酌情选择“推迟”该功能的开发。如果该功能是我们的核心功能与创新功能或者与其他功能的联动性较强，我们就会决定其为“必须实现”的功能。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有，我们进行了回归测试、正确性测试、兼容性测试与安全性测试，要求项目的功能性、兼容性与安全性达到我们的测试标准才算达到项目的出口条件。详情请见【HelloKitty团队项目】Beta阶段测试报告
对于可能的变更是否能制定应急计划?
是的，因为在具体开发中我们对开发工作采用了解耦的方式，每个人负责的功能部分相对独立，在面对变更时我们会让对应的成员进行负责，如果涉及较为复杂的前后端对接，则会让对接的同学面对面进行沟通调整，能较好的制定应急计划。
员工是否能够有效地处理意料之外的工作请求？

可以，员工们根据自己的时间安排动态的分配任务情况，当有意料之外的工作请求的时候，我们会根据当前有空的同学与负责该工作的同学进行协商动态进行任务调配。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
团队成员保持沟通很重要，能及时沟通能够加快整体的开发。如果重来一遍，在涉及复杂功能开发与变更时我们会让负责的同学直接面对面进行交流与调整，这样能进一步提高开发效率，及时解决问题。

五、设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 在团队组成后，我们组就讨论选题，并最终确定了完成一个智能背单词软件。
- 功能设计主要由卓乐、李京昊、王永瑶同学完成各个功能的规划，重点在于“智能”功能以及“基本”功能两方面，在保证背单词基本功能的前提下，实现智能化、便利化的背单词是我们自始至终坚持的宗旨。这些同学比较了解GPT接口的诸多功能。
- UI设计主要由吕元秋和徐子航使用即时设计这一平台共同合作完成。是在功能规划后，设计完成了UI，旨在更好的便利用户使用，提供更佳的使用体验感。这些同学具有比较好的审美。
所有的设计都是逐步按时完成，是在合适的时间同时安排擅长的人来完成的。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？

在UI设计中规划功能布局时，部分功能可能都比较适合归类的一类，划分到一个界面，就需要做出抉择。

团队一般对于设计工作都是由一人提出计划，再大家一起讨论是否通过，对于模棱两可的问题亦然。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

团队对于设计方面主要是运用即时设计，这是可共享的UI设计平台，此外，可以通过连接、注释来标注各个页面的互相调用关系以及点击绑定的活动。工具非常适合团队开发设计。

主要区别在于功能的最终实现。最初设计只是理想化设计，但是在具体开发中需要结合组件以及后端实现等诸多限制，故，会出现诸多功能规划的不同。同时，在开发过程中，组内同学可能会出现更好的idea，在经过讨论后会增加这些功能。UML文档需要经常更新QAQ。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

与ChatGPT相关的功能Bug较多，因为ChatGPT由于跨域等问题会有很多不可测情况，表现不是很稳定，比较容易出现Bug，但是，我们在开发过程中也是重点测试这一方面，在发布后并没有出现很严重的关于ChatGPT相关的Bug。主要是语音播放，由于缺少调研，完成语音播放后，发现在具体使用时如果多次点击，会叠加播放。在开发时只是测试了可行性，没有尝试连续多次播放，并且选择了比较固定的组件。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

我们组并没有指定一个固定的同学负责代码审核功能，而是同学之间互相审核，前端同学互相审核，后端同学亦然，严格执行代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 技术方面我们学到了系统的、工程化的团队软件开发流程，掌握了git、vue、django等技术
- 精神方面我们学到了团队合作与团队沟通，有效沟通和合理分工、充分发挥各自的长处才能使得一个团队的开发更高效。
- 改进可以分为两方面：
  - 前端可以更加充分的调研组件库，可以采用风格差异不大的不止一种组件库来共同完成项目，能够更好的利用不同组件库的长处
  - 后端对于ChatGPT功能和接口的规划可以更安全、并行性更高一点，提高产品性能。

六、测试/发布

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

在Beta阶段，我们延续Alpha阶段的测试计划，设计了场景测试、兼容性测试、单元测试、压力测试与安全性测试。此外，在Beta阶段，我们还设计了针对Alpha阶段的回归测试。
是否进行了正式的验收测试？

在测试周，由前端同学完成了场景测试、兼容性测试，后端同学完成了单元测试、压力测试与安全性测试。具体测试工作见【HelloKitty团队项目】Beta阶段测试报告。
团队是否有测试工具来帮助测试？

在开发阶段，我们使用apifox进行前后端对接前的测试，前端使用apifox提供的mock测试url，后端使用apifox向后端发送请求测试接口的正确性。在单元测试阶段，我们使用了django的单元测试框架进行单元测试，对所有输出稳定的api的正常功能与异常情况编写了对应的单元测试。在Alpha阶段单元测试的基础上，对Alpha阶段修复与beta阶段新增的api的正常运行状态与异常情况编写单元测试，共68个测试点，后端覆盖率为64%（未覆盖的接口包括较多使用gpt输出不稳定无法单元测试的接口，以及每日学习单词的输出随机无法测试）。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

配置好 nginx+uwsgi 服务器后，我们运用 JMeter 对其进行压力测试，整个测试过程都采用高并发，充分利用服务器资源。Beta阶段的压力测试包含了Alpha阶段测试的API，还针对Beta阶段新开发的内容与功能进行测试。我们发现较慢的接口大多是由于单词软件的固有限制，例如在数据库查询单词时数据库单词量较大查询较慢、调用gpt接口的服务较慢等，因此我们对部分接口设置了日使用次数限制避免过载，其他服务响应速度均较快。
在发布的过程中发现了哪些意外问题？
- 验证码只在网页端进行了完备的正确性测试，但是使用后端接口测试工具时存在一定的漏洞
- 登陆时的验证码修复为大小写不敏感，但是忘记修复注册的验证码逻辑，导致注册的验证码必须大写。
- 新用户注册后没有新消息，导致通知栏无法正常打开
- 新增多种主题色后，部分页面的颜色搭配不协调
我们学到了什么? 如果重来一遍, 我们会做什么改进?
- 由于Beta阶段的测试时使用了Alpha阶段创建的测试账号，部分注册后的业务逻辑未得到充分测试。重来一遍我们会在使用Alpha阶段的测试账号的同时，也创建新的测试账号保证测试充分覆盖所有业务逻辑
- 前后端分离的项目中，除了在网页端进行正确性测试，也应当从直接调用后端接口的角度充分考虑安全性，例如鉴权、权限控制等
- 除了功能的正确性测试，也应当注意所有前端样式显示的正确性被充分测试到

七、团队的角色，管理，合作

团队的每个角色是如何确定的，是不是人尽其才？
我们延续了前一阶段的角色分工，四位同学负责前端，三位同学负责后端。其中，前端小组都有前端的相关开发经验，且有一位擅长ui设计的同学。后端小组中两位同学有后端开发经验，另一位同学熟悉ChatGPT，负责相关接口设计。因此我们可以说是做到了人尽其才。
团队成员之间有互相帮助么？
- lzh：谢谢大家帮我写博客谢谢lyq帮我进行宣发和视频发布
- lyq：对于项目结构的搭建，队友们搭好框架后再填充以及store的设置。
- xzh：项目在最初仓库构建时队友制定好了规范，为后续开发带来了便捷；前后端对接时团队积极沟通互帮互助。
- wyy：部分实现模仿了队友的设计，谢谢队友提供的帮助
- ljh：在对接前后端的过程中队友能及时给予反馈并提出可能的错误原因。
- zya：对不同部分代码的讲解，功能的具体设计的讲解。
- zl：太有了，尤其在前后端对接的部分。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
当有团队成员因为错误的代码合并导致项目代码管理出现问题时，会由PM回退到指定的版本，负责相关部分的成员修改正确后再重新提交。
每个成员明确公开地表示对成员帮助的感谢（并且写在各自的博客里）：

我感谢 _______<姓名>______对我的帮助，因为某个具体的事情: _____________________。

大家的感谢均与第二问中一致~

八、总结:

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

我们处于可管理级。团队拥有着完整的项目管理体系，已实现项目产品和过程的控制。可预测过程和产品质量趋势但在过程的改进上还有待提高。

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

我们处于创造阶段。团队有着合适的分工和合作，有着完整的开发流程，不仅在技术上过关，同时都非常具有责任感和积极性。

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

运维工作更加稳定并提高了团队开发的效率：将生产环境和开发环境隔离开，应用了成熟的CI/CD保证团队能够及时看到代码变更在软件的展现。各位成员在交付到前后端对接前的本地测试能够熟悉地使用各类测试工具保障提交代码的质量。

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

团队在测试方面还有提升空间，在产品交付前应做更充足的测试，如Gpt相关的接口的各类限制等。此外还可以继承更多语言模型的算法，降低对于gpt的依赖性。

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

最优先要做的是尽早、持续地交付有价值的软件，让客户满意。我们在Beta阶段尽早地交付了软件并发布给用户进行使用，收获了很多新用户和alpha阶段用户的好评。
在整个项目过程中，业务人员和开发人员必须每天都在一起工作。尽管在Beta期间组员们因为考试等原因都比较忙，但是我们依然进行了每日例会和线下集中开发，良好的沟通交流是我们敏捷开发成功交付非常重要的基础。
简单是尽最大可能减少不必要工作的艺术，是敏捷的根本。在Alpha阶段后我们收获了用户们广泛的意见和需求，但是考虑到敏捷开发的因素，我们将需求做了进一步筛选，保留那些与产品核心理念相关的例如个性化智能化的需求，滤去了其他竞品已经有的非本产品竞争性的需求，在Beta聚焦于关键的核心需求。

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

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

我们在开发之初构建仓库时就制定好了git规范以及代码规范，包括文件结构，命名等等，整体管理较为规范。但在开发过程中还有着代码风格不统一，在对其他同学的代码进行修改时需要花一定精力阅读，可以对于具体代码风格制定规范，使用代码风格检查工具、互相审计代码来提高代码质量。
整个程序的架构如何具体提高？如何通过重构等方法提高质量，如何衡量质量的提高？

在Alpha期间我们设计了较为合理的代码架构，在Beta期间几乎没有重构工作。下一步可以再提高代码的复用性，通过合理的解耦和复用让代码更加模块化层次化。
其它软件工具的应用，应该如何提高？

经过Alpha阶段，团队成员们在Beta期间能够熟练地使用代码管理工具和前后端接口工具，在测试工具上也有了一定的经验。下一步可以规范文档管理工具的使用，结合文档复审进行文档的系统管理。
项目管理有哪些具体的提高？
- 建立更加细致的项目计划，包括子目标设定，时间分配等等
- 明确考核绩效指标，指定更细致的贡献评定机制
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

目前我们通过查询数据库获取每日/周活跃用户等数据。计划提高的方面是可以使用一些统计日活与日访问次数的自动化工具，能够直观高效地反馈日活，避免通过查询数据库较为单一的方式统计。
项目文档的质量如何提高？
- 我们采用了团队成员认领+PM汇总的工作模式
- 应当继续增设文档审核机制，进行多轮评审
对于人的领导和管理，有什么具体可以改进的地方？请看《构建之法》关于PM、绩效考核的章节，或者《人件》等参考书
- 进行更多的更及时的沟通协调，充分了解各部分工作进度和难题
- 明确绩效指标，调动团队积极性
对于软件工程的理论，规律有什么心得体会或不同意见？请看阅读作业。 (这个作业的期中阅读)

在学期开始前，阅读构建之法的软件工程理论时还比较抽象，但是一学期的时间下来，再回看软件工程理论尤其是敏捷开发的各项原则的时候，对这12条原则几乎都有真切的实践经历来支撑，总体来说团队的两个月的敏捷开发实践较为成功，两个阶段的总结中都能从团队开发经验中对软件工程理论有更加深刻的认识。