Tomato——alpha阶段问题总结随笔

托码头小队团队 2024-05-21 22:08:47

这个作业属于哪个课程	<2302软件工程社区>
这个作业要求在哪里	团队作业—beta冲刺+事后诸葛亮
这个作业的目标	针对alpha阶段问题的总结
团队名称	托码头小队
团队项目	Tomato时间管理小程序
其他参考文献	《构建之法》

典型场景：

1.普通大学生小林，在校期间沉迷手机，上课没精力，学习出现问题，需要学会安排好学习时间。

2.某职场工作人士，因为缺乏时间管理导致工作在短时间积压，工作无法完成，需要摆脱拖延症，安排好工作生活时间。

3.在校大学生小陈，因为拖延症导致期末复习时间紧张导致成绩不理想，可以通过此小程序帮助安排学习时间。

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

1.原计划功能大体上已经完成，只剩待办、评论和专注的部分页面还需要完善，主要是评论文章页面的比例不对、
文章内容以及图片的适配还未完善。

2.项目的Alpha冲刺也已按照原计划交付并通过答辩。

3.因为小程序暂未通过微信审核，暂时只有团队内部以及部分人员使用过，原计划的用户数量暂未达到。

3.和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？

1.与上一阶段相比，团队软件工程的质量明显提高了。在团队项目开始前，我们把团队项目任务分成前端和后端，前后端各设一个组长，
这样子团队之间的交流会更加方便。并且在Alpha阶段我们每天还举行了站立式会议讨论项目开发进度、困难以及第二天的开发计划，这样我们能对项目整体的进度有一个清晰的认知，
共同推进项目开发进度。

2.主要在团队沟通合作上有明显的提高，具体提高了25%，上一阶段，大家对团队开发还处于摸索阶段，
团队成员对于微信小程序的开发以及团队沟通合作还没能熟练掌握，经过Alpha阶段的熟练之后，团队之间的沟通也更加流畅，我们的分工与协作更加合理，而且每一天都有站立式会议，团队成员不断的加强交流，所以我们的效率大大提升了。

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

1.因为小程序暂未通过微信审核，暂时只有团队内部以及部分人员使用过，原计划的用户数量暂未达到。

但我们让其他宿舍的同学来体验了一下，在微信小程序项目的主要功能上，我们的大体方面已经完成但仍有部分功能需要完善。当然，我们还会寻找更多的体验者来体验我们的产品，我们将会不断地优化，从其他体验者的体验结果上来看，用户接受程度与我们事先的预想一致，我们认为我们离目标已经比较接近了。

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

1.合理安排工作量，小组内对于项目开发进度需要有一个清晰的规划，防止最后的任务积压。提高工作效率，加快项目进度。

根据Alpha阶段的项目开发燃尽图，有部分时间，我们小队的开发进度是低于预期开发进度的。如果能重来一次，我们会更加合理的规划项目工作，提高工作效率。

2.认真加强团队交流。团队前后端各有一名小组长，团队交流十分顺利，但是在开发过程中，前后端组长有时会缺乏对各组成员的沟通，
导致缺乏对前后端进度的具体了解，进而影响项目进度。所以，如果能再来一次，我们一定要加强各组间的交流，提高我们项目的开发效率和完整性。

3.在开发前，要对项目功能有一个完整的讨论，我们要更充分和详细地规划和设计新增功能，多从用户角度出发，保证用户的使用体验。合理规划，确保所有功能能按时交付，避免用户体验不完整的情况。

4.认真审查文档，在Alpha阶段，有部分博客和文档存在错误和空白，还需要后期不断地修改。如果能认真审查博客和文档，我们就能省去这部分的时间和精力，能够加快项目进度。

二、计划

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

在Alpha阶段开始前我们的计划准备地较为充足，我们制订了Alpha阶段的大概计划与小组分工，但是具体细节仍然欠缺，没有精确到日。

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

我们小组中的氛围非常好，大家都乐意去听取别人的意见。而针对不同的意见，我们采用了投票的方式来决定。就是每个人都可以提出自己的想法和建议，然后大家一起讨论优缺点，最后进行投票表决。

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

我们小组原计划的工作大体上都已完成，但是仍有只剩待办、评论和专注的部分功能和页面还需要修改完善。
没有完成的主要原因是小组对于项目进度的规划出现了偏差，部分功能没能完成，并且小组对于微信小程序的开发还是有些不熟悉，影响了进度。
4.有没有发现你做了一些事后看来没必要或没多大价值的事?

暂时没有发现，我们每一步进度都是按照我们之前的计划而进行的，在Alpha阶段开始前，我们就对项目有了一个整体的规划与项目分工，我们认真完成了每一个开发点，共同完成了冲刺阶段的任务。在开发过程中并没有发现一些事后看来没必要或没多大价值的事。

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

是的，我们对于每一项任务都有着清楚的定义，我们前后端各设立了一位小组长。每日冲刺结束，前后端组长会对组员的提交结果进行审查，查看是否符合文档要求，最后报告给组长。通过审查后，小组开始编写冲刺博客记录每日进展。在最后阶段，全体小组成员还会对每一个开发点进行审查讨论。

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

在Alpha阶段开始前，我们就对项目有了一个整体的规划与项目分工，我们的项目开发都按照计划进行，但仍遇到了一些意外：

1.在前后端整合时出现了一些问题，前端无法联系后端。

当时没有估计到的风险有：

1.微信小程序的审核不通过。

2.前后端整合会出现问题。

没有估计到的原因主要是团队的小程序开发经验不足，导致各种风险没有考虑到。
7.在计划中有没有留下缓冲区，缓冲区有作用么?

在计划中，我们留有一天的时间作为缓冲区，在最后一天，完成项目最后的整理。缓冲区还是有作用的，可以让小组工作不至于太过忙乱，减少出错。

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

1.增加缓冲区时间，在项目开发中期增加一天的缓冲时间

2.我们也会根据项目进度适当增加会议次数，以便团队成员更好地分配和管理自己的工作时间。这将有助于提高工作效率和协作质量。

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

在这个项目中，我们学到了凡事预则立的重要性。在进入开发阶段前，制定详细和全面的计划是非常关键的。
我们也认识到软件工程的每个环节都至关重要，不能忽视任何一个环节。因此，如果历史重来一遍，我们会制定详尽的开发计划，安排好小组分工，提高开发效率。重视好每一步，减少出错。

三、变更管理

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

我们使用项目管理工具来发布通知，并且我们还建立了团队项目交流群，确保每位成员都能及时知道变更信息。

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

团队中，我们采用集体讨论 + 投票表决的方式来决定功能的优先级。我们会召开线上或者是线下会议，让所有团队成员参与讨论，共同决定哪些功能需要推迟，哪些功能是必须实现的。
3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

有的，我们对于项目的出口条件有着清晰的定义。出口条件包括但不限于：所有界面设计与原型一致，模块功能符合系统设计说明书的定义。
并且还需要参考其他用户的体验，只有大部分用户的使用体验达到良好才能满足出口条件。

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

是的，我们也意识到在项目开发中可能会面临变更和意外情况，因此我们制定了应急方法来应对这些情况：比如我们在项目中期设立了一天的缓冲时间，用以暂停项目开发进度，分析变更和意外情况，及时修改。首先，我们会暂停开发进度，由负责人了解变更计划，与成员进行讨论或者是通过网络寻求解决办法，然后将解决办法拆分成任务分配给前后端，最后，团队进行应急处理，这样才能有效地处理项目中的变更和意外情况。
5.员工是否能够有效地处理意料之外的工作请求？

是的，我们的团队成员都具备良好的沟通和协作能力，能够有效地处理意料之外的工作请求。但是组员的个人能力水平是不一致的，因此，
会有部分水平能力高的组员帮助其他组员解决困难。我们也鼓励团队成员之间的合作和互助，在面对额外的工作请求时，大家会共同协商、分配任务以确保工作得以顺利完成。团队成员之间的良好氛围能够帮助我们适应变化、更好地处理意料之外的工作请求。

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

1.我们会更加注重需求分析阶段，努力减少潜在的需求缺漏，以确保项目的稳定性和可持续性.

2.要有心理准备，在进入开发阶段前，需求分析的时候总归是会有缺漏的，需求的变化是正常的。我们要灵活适应变化以适应项目的变化。

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

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

首先，组长会确定团队各个岗位的需求：前端3人（其中一人为前端组长），后端3人（其中一人为后端组长），运维1人，项目经理1人。

接着，组长会了解每个团队成员的需求和可分配时间。首先根据个人意愿进行分配，最后，剩下的岗位则根据每个人的擅长领域来分配，
逻辑能力强的成员通常会负责后端开发，而擅长用户界面设计的成员则会负责前端开发。通过这样的分配方式，我们的团队成员能够在自己擅长的领域发挥最大的能力。
从最后的开发体验上来说，大家满意程度较高。

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

当然有的，我们的团队成员都具备良好的沟通和协作能力，组员的水平不尽相同，所以需要互帮互助，熟悉微信小程序开发的组员，能够直接分享微信小程序开发经验给其他组员，代码水平能力较高的成员也会帮助其他组员解决困难，水平较低的组员也会主动沟通交流，寻求解决方法。
3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？

当出现项目管理、合作方面的问题时，团队成员会采取以下解决方案：

1.团队内部进行讨论，共同找出解决问题的办法。通过这种方法，大部分的问题都能够得到很好的解决。

2.如果在团队内部讨论后仍无法解决问题，团队成员将寻求网络或者是其他人的帮助，找到适当的解决方案。

通过这种方式，我们能够高效地解决绝大部分项目管理、合作方面的问题。

五、设计/实现

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

团队的设计工作都是在需求分析、系统设计与概要设计阶段，由全体小组成员讨论后完成的。在这一阶段，我们有着足够的时间来进行设计工作。而团队内部成员参与设计工作是非常合适的，因为他们通过完成设计工作能够很好地了解开发项目，并且团队成员作为真正意义上的第一批用户，能够很好地从用户的角度来进行设计工作。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？

设计工作确实有碰到模棱两可的情况，最后我们通过讨论 + 投票表决的方式来确定最终结果。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

接口设计部分运用了Apifox接口设计工具,这个工具可以快速生成接口文档，详细标注了各个接口的入参和返回数据的格式，便于我们进行前后端的交接。
在开发的过程中我们运用了postman进行单个接口的基本测试，在后端组编写完所有的接口后，使用Apifox的自动化测试功能，通过预先设定数据集来进行所有接口的统一自动化测试。
上述的两款工具都很有效，对接口的设计和测试工作均有很大帮助。
4.什么功能产生的 Bug 最多，为什么？在发布之后发现了什么重要的 bug? 为什么我们在设计/开发的时候没有想到这些情况?

主要的bug还是集中在跟图片上传有关的功能中。在最开始的设想中，我们是想将图片的url地址保存在数据库中，然后直接将地址返回给前端。但是我们没有考虑到文章可以上传多张图片的情况，并且最开始数据库的数据格式是字符串，导致多张图片的地址糅合在一起，对于单张地址的提取非常麻烦。除此之外，一开始也没有注意服务器的文件存储路径和本地是不一样的，故导致在本地调试可以，部署到服务器上反而不行的情况。上述这些问题的产生主要还是在设计阶段没有考虑周全以及对Linux环境的不熟悉所导致的。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

在我们的项目中，代码复审是通过交叉检查 + 组长检查的方式进行的。首先，在组员进行代码编写之前，他们会自行阅读代码规范，并在编写过程中遵循规范进行开发。然后，在代码编写完成后，前后端小组成员会交叉复审代码。最后，前后端组长也会总体的代码进行审核，查看是否严格执行了代码规范。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

首先，我们要注重Alpha阶段之前的准备工作，只有前期的规划做好了，后面的开发阶段就是水到渠成。如果历史重来一遍，
我们会在规划阶段要给予足够的时间来制定计划，做好准备。

其次，我们要加强团队成员间的沟通协作，对于项目开发过程中出现的分歧，我们要注重倾听和理解，并通过更深入的讨论和协商来达成共识。

最后，我们还意识到在整个项目过程中，代码复审和代码规范的严格执行的重要性。如果历史能够重来一遍，我们一定要更加注重代码复审和代码规范，确保代码质量和一致性，以提高整体项目的稳定性和可维护性。

六、测试/发布

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

有的，详情请看Tomato——alpha测试随笔，我们使用的是模块化编程，后端成员完成一个功能模块后就可以开始对该模块进行测试。在项目完成之后，团队还会对前后端整合、各个模块、前端页面再次进行一个全体的测试。
2.是否进行了正式的验收测试？

是的，我们进行了正式的验收测试。在项目开发的后期，我们进行了多轮次的验收测试来确保小程序能够满足用户需求和预期。这些测试旨在验证系统的功能、性能和稳定性，并确保软件满足项目要求和标准。

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

在开发的过程中我们运用了postman进行单个接口的基本测试，在后端组编写完所有的接口后，使用Apifox的自动化测试功能，通过预先设定数据集来进行所有接口的统一自动化测试。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

在项目中，我们并没有充分测量和跟踪软件的性能。我们只对软件的各个模块功能进行了测试，并没有进行效能测试，这是我们的疏忽。

效能测试能够很好地评估软件的响应时间、负载能力和资源消耗情况，帮助我们提高软件的效能。因此我们应该引入性能测试工具和技术来测量和跟踪软件的性能。
5.在发布的过程中发现了哪些意外问题？

1.服务器的文件存储路径和本地是不一样的，导致项目在本地能够调试，部署到服务器上反而不行。

2.在最开始的设想中，我们是想将图片的url地址保存在数据库中，然后直接将地址返回给前端。但是我们没有考虑到文章可以上传多张图片的情况，并且最开始数据库的数据格式是字符串，导致多张图片的地址糅合在一起，

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

首先，我们要注重Alpha阶段之前的准备工作，对产品测试以及效能测试及进行规划。

其次，我们要更加注重性能测试和跟踪，引入性能测试工具和技术，对软件的性能进行定期测量和跟踪，以及时发现和解决潜在的性能问题

最后，我们会加强对测试工具和技术的了解和应用，我们会不断学习和掌握新的测试工具和技术，以提高测试的效率和准确性。

...全文