奇迹行者不吃牛肉——Alpha阶段问题总结

奇迹行者不吃牛肉团队 2024-05-27 15:15:38

这个作业属于哪个课程	202302软件工程实践
这个作业要求在哪里	团队作业—bate冲刺+事后诸葛亮
团队名称	奇迹行者不吃牛肉
这个作业的目标	对于Alpha阶段所存在的问题进行经验教训的总结
项目名称	福助助
参考文献	《构建之法》、项目管理——事后诸葛亮

Alpha阶段问题总结随笔目录

一、
设想和目标
计划
资源
二、
变更管理
团队的角色，管理，合作
三、
设计/实现
测试/发布
四、总结

一、

设想和目标

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

我们的福助助校园互助小程序是一款基于移动端的应用软件，旨在为用户提供一个集中、高效、安全的校园互助平台。通过该小程序，学生可以方便地进行跑腿服务、二手交易、拼车、求助等活动。该小程序具有直观友好的用户界面，支持用户快速找到所需的帮助或资源，并提供安全可靠的交易环境。
定义清晰明确。明确指出了小程序是一款基于移动端的应用软件，同时描述了旨在为用户提供集中、高效、安全的校园互助平台，并为用户列举了具体的功能和服务内容。这些信息可以帮助用户更好地理解我们小程序的定位和特点。
有对典型用户和典型场景有清晰的描述。在我们之前发布的《福zZ需求规格说明书》有对具体的用户和场景进行清晰的描述，并且在Alpha阶段根据此说明书执行。截取其中一个典型用户与典型场景作为说明：

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

我们已经基本实现了原计划中设想的跑腿服务、二手交易、拼车、互助四大功能，并且按照原定计划的时间表（10天Alpha冲刺）交付了一个可以实现基本功能的小程序。虽然还未正式上线，但在用户数量方面，我们只是对周围同学进行了使用测试，也基本达到了我们所设想的用户数量。
和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
与上一个阶段相比，团队软件工程的质量有了大幅度的提高。在Alpha阶段，软件的
- 可测试性强（↑60%），软件能易于进行测试，通过设计合理的测试用例，我们的软件具备良好的测试覆盖率。
- 功能性（↑65%） 迈出了重要的一步，我们基本实现了基础功能、四个核心功能以及附加功能。
- 可用性高（↑75%），团队专注于软件的易用性和用户友好性，前端人员经过了精心设计为用户提供了良好的用户界面和交互方式，以及方便用户进行操作。
- 此外我们强调团队的协作与沟通（↑90%），十天的站立式会议共同解决每日存在的问题。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

用户对于重要功能的接受程度基本与我们事先的预期一致，尽管还有一些细节需要进一步完善，总体来说，他们的接受程度是很高的。
我们正朝着目标更近了一步，Alpha阶段是一个很关键很有意义的一个阶段。整个项目正在有条不紊地朝着更加完善的方向迈进。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 在团队开发中，信息获取能力非常重要。我们应主动利用网络学习前人的开发经验，以提高整体开发效率。
- 当遇到问题时，及时提出并讨论是至关重要的。个人反复思考而无法解决问题最终会拖累整个团队，耽误项目的开发进度。
- 测试应与项目开发同时进行，及时获得失败的测试结果可以更好地完善功能并解决错误。
- 我们需要加快服务器的部署进程，因为目前的部署效率远低于预期。
- 每个人都应明确自己的分工，并及时记录和总结工作内容。不能出现在阶段性完成后不清楚自己所做工作的情况。

计划

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

在Alpha阶段，我们有充足的时间来做规划，在任务发出后的两天，我们团队对该阶段作了细致的任务分块、人员分工、十日规划表等等，以确保任务能够按期完成。
团队在计划阶段是如何解决同事们对于计划的不同意见的？

在计划阶段对于组员的不同建议，我们积极听取不同的意见，为了整个项目而考虑，努力将不同的建议进行客观地分析，并且在各方利益和关注点之间寻找平衡点，促进理解以达成共识并推动计划的顺利进行。
原计划的工作是否最后都做完了? 如果有没做完的，为什么?

原计划的工作最后都做完了并且超额完成。
有没有发现你做了一些事后看来没必要或没多大价值的事?

没有。在冲刺阶段之前，我们的团队成员已经明确了各自的分工和任务模块，并且有了清晰的工作方向。因此，我们所做的工作都是有意义的。尽管有时个人的疏忽可能导致某些功能无法迅速实现，浪费了一些时间，但通过问题的分析和解决，最终我们还是能够实现这些功能。这样的经验也具有价值，同时也可以给其他开发队员提供一些提醒和建议。
是否每一项任务都有清楚定义和衡量的交付件?

是的，每一项任务都有清楚的定义以及衡量的交付件。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

在项目规划阶段，我们会确立一个总体方向和计划，整个项目实际的Alpha进程也根据这个计划有条不紊地进行着。然而，在Alpha冲刺期间，我们也将密切关注实际项目进展的情况，随时准备对计划进行动态调整。我们会根据实际情况灵活地做出改变，以确保项目能够顺利前行并达到既定的目标。
技术挑战：项目会遇到各种各样的技术难题，导致开发进度受阻。这些技术挑战是在项目初期并没有预估到的，导致没有办法严格按照预期计划实现下来，因为一些问题只有在实际开发中才会暴露出来！
在计划中有没有留下缓冲区，缓冲区有作用么?

在计划的过程中当然有预留缓冲区，为我们团队的项目管理提供了灵活性和应变能力，帮助项目团队应对风险、变化和不确定性，从而提高成功率和交付质量。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）

考虑到时间紧迫且任务繁重，我们需要根据任务的难易程度平均分配给每个成员。随着新人加入团队，需要时间来熟悉整个项目，因此在分配任务给新人时，会优先考虑那些上手快的任务。具体的计划会根据实际情况进行调整。

资源

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

我们有各种资源来完成实验中的各项任务，包括网络上的资源和助教提供的帮助和指导。这些资源为我们完成项目提供有力支持，使我们更加顺利地完成实验任务。
各项任务所需的时间和其他资源是如何估计的，精度如何?

首先我们会根据过去任务的经验，结合每个组员以及团队的实际情况，估计每个任务所需的时间与资源，然后将大的任务分解为更小的子任务，并估计每个子任务的时间和资源需求。这样基本可以比较准确地估计整个任务所需的时间和资源。对于精度，在实际项目的进展过程中，根据计划表百分百地完成下来是很难做到的，实际情况可能会有所变化，因此我们会根据具体的情况对各项任务进行动态调整。

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

测试的时间、人力和软件/硬件资源基本足够，以及测试资源足够，在上一阶段测试覆盖比较全面。对于不需要编程的资源，如美工设计和文案，有时候会被低估难度，因为大家可能往往更多关注技术开发方面，而忽视了这些细节领域也是很重要的！
你有没有感到你做的事情可以让别人来做（更有效率）?

鉴于每一团队成员的技能水平，在进行任务分配的时候，都会考虑到成员的优劣所在，相信每位成员承担这个任务会是最佳选择，当然也会在具体项目进行时候进行动态调整，从而提高整个团队的工作效率。

二、

变更管理

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

团队内的每个成员都会及时了解到任何变更的消息，我们每天都会在站立式会议上讨论并确定接下来一天需要完成的任务，并根据情况动态调整计划。此外，我们也会通过团队群进行即时交流和沟通。
我们采用了什么办法决定“推迟”和“必须实现”的功能?

我们通过对功能进行优先级划分来确定 "推迟" 和 "必须实现" 的策略。例如，对于福助助小程序，我们将拼车、交易、跑腿和互助社区这四个核心功能视为最为必须实现的，因此它们具有最高的优先级。而像评论、点赞、搜索等附加功能的优先级次之，这些功能都是为了让整个小程序更加完善。相比之下，一些类似于其他吃了么功能的附加功能在有限时间内可能会被赋予较低的优先级，因此它们可能会被推迟实现。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

根据项目的预期计划，逐项完成计划中的任务；然后，通过项目测试，例如界面功能测试、压力测试和云函数接口测试，确保测试顺利通过；并通过用户体验和用户反馈不断完善项目，逐渐满足项目的出口条件。
对于可能的变更是否能制定应急计划?

对于可能的变更能够制定应急计划。通过每日的站立式会议，若有变更，就会在当次的会议中进行说明，若无变更，则继续按照计划行事。
员工是否能够有效地处理意料之外的工作请求？

在我们团队中，每位成员都表现出了对意外工作请求的高效处理能力。在每个阶段开始之前，我们会进行任务分配，并且组长会提前说明每个人的任务都是基于预分配的，随着项目的进行，可能会根据具体情况增加一些工作量。

团队的角色，管理，合作

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

根据团队成员的技能、经验和兴趣来确定他们的角色，比如擅长后端技术的成员会负责后端开发，擅长前端设计的成员则会负责前端工作，旨在实现人尽其才的目标。

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

当然有。在遇到问题的时候，团队成员会在每日的站立式会议上提出来，大家一起解决，也会在qq群中进行探讨问题，最终解决问题。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？

当出现项目管理和合作方面的问题时，团队成员会秉承"有问题直接说"的基本准则，加强沟通，每个人都有发言的权利，并通过讨论、协商和寻求共识的方式解决问题，以确保能够共同应对挑战并取得成功！

三、

设计/实现

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

设计工作是在项目需求分析完成后进行的，由全体团队成员经过讨论共同完成，确保在适当的时间和由合适的人员进行。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？

设计工作经常会遇到模棱两可的情况。在这种情况下，团队会积极倾听不同意见，寻求平衡并解决问题。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

我们团队使用微信开发平台自带的自动化单元测试进行测试，并且使用BoardMix在线绘制UML图和墨刀进行原型设计。这些工具都非常有效，显著提高了整个项目的开发效率。
当前的状态与最初的UML文档基本没有太大区别。我们已经实现了一些基本类的功能，并在概要设计和数据库设计阶段更新了UML文档。这些更新主要是对小程序进行了更加细致地逐层分析每个功能需要什么功能。现在UML文档已经相当完善，因此后续对UML文档的更新将取决于具体情况。

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

帖子功能通常是最容易产生bug的部分。因为帖子功能涉及到诸多复杂的交互和数据处理，包括帖子的创建、编辑、删除，评论的添加和删除，点赞等等。这些功能涉及到大量的用户交互和数据传输，容易出现各种意外情况。
在发布之后发现的重要bug包括：
帖子内容显示问题：文字或图片排版错乱、展示异常等。
评论或点赞功能异常：导致用户无法正常进行评论或点赞操作。
数据同步问题：帖子在不同设备上显示不一致、评论未能及时同步等。
在设计和开发阶段，没有充分考虑到这些情况的原因包括：
网络环境和设备差异：不同的网络环境和设备可能会对帖子功能产生影响，这些影响难以在开发阶段完全模拟和测试。
用户行为多变：用户在实际使用中的行为和操作方式多种多样，有时难以完全预料到用户的操作路径和频率。

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

当一个开发人员完成了一部分代码时，会请求其他团队成员进行代码复审，也就是相互检查。在复审过程中，会检查代码是否符合预先定义的代码规范，包括命名约定、缩进风格、注释规范等。此外，还会评估代码的质量、性能和安全性等方面。通过这种方式，我们确保团队中的所有代码都符合统一的规范，并且能够得到组员的审查和反馈，从而提高代码质量和可维护性。

测试/发布

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

当然有测试计划——>可见奇迹行者不吃牛肉——Alpha冲刺测试随笔的测试工作安排。
是否进行了正式的验收测试？

有测试人员进行正式的验收测试——压力测试、界面功能测试、云函数接口测试。
团队是否有测试工具来帮助测试？很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

每一项测试都有测试工具：

为了提高测试效率，可以考虑引入自动化集成测试工具，例如Selenium或Appium，这些可以来覆盖至少一个方面的测试。自动化测试结果可以生成详细的报告，包括测试覆盖率、通过和失败的测试用例等信息。

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

通过真机测试，进行实际上手，更加直观地感受软件的效能，然后就是身边同学的反馈和体验，收集他们的反馈，用来评估软件在实际使用中的表现。
对于压力测试，团队会模拟系统在极端负载下的表现，以评估系统在压力下的稳定性和性能。这些测试工作非常有用，因为它们可以帮助团队发现系统的性能瓶颈、潜在的故障点和性能优化的空间。
然而，从实际运行结果来看，这些测试工作在下一个阶段可能需要结合业务场景：将性能测试和压力测试与真实的业务场景结合起来，更好地模拟实际使用情境，以提高测试的真实性和有效性。

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

数据加载问题：包括头像、背景等数据没有正常刷新出来。
样式在真机展示问题：在真机上展示时出现了样式问题。

四、总结

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

我认为我们团队目前的状态处于CMM中的——已管理级(Managed) 。整个产品和过程已建立了定量的质量目标。并且在开发活动中的生产率和质量是可量度的。已建立数据库。可预测过程和产品质量趋势，实现及时纠正。
你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?

在Alpha阶段，团队处于规范阶段。在这个阶段，团队建立起规范的工作流程、沟通方式和标准操作程序，以确保项目能够按照既定的计划和标准进行。团队着重于确立稳定的工作基础，为接下来的β阶段奠定良好的基础！
你觉得团队在这个里程碑相比前一个里程碑有什么改进?

在这个里程碑中，团队在沟通和合作方面取得了显著的改进。通过每日的站立式会议，团队成员之间的沟通得到了加强，更加懂得如何协作解决项目中的问题，共同朝着项目成功的目标努力。这种合作精神提高了团队的效率和团队成员之间的理解，从而为福助助项目的顺利完成奠定了坚实的基础。
你觉得目前最需要改进的一个方面是什么?

目前最需要改进的一个方面是团队的任务分配和工作量平衡。