[T.18] 团队项目：Beta 阶段项目总结

移山小组 2024-06-30 23:27:46

这个作业属于哪个课程	https://bbs.csdn.net/forums/buaa-ase2024
这个作业的要求在哪里	[T.18] 团队项目：Beta 阶段项目总结-CSDN社区
我在这个课程的目标是	了解熟悉敏捷开发的方法论，培养团队合作能力，通过实际开发产品进行实践
这个作业在哪个具体方面帮助我实现目标	为软工课程画上一个完美的句号

设想和目标

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

同学们预约体验馆困难，老师管理体验馆繁琐，需要一个系统解决两边的需求。我们将典型用户和典型场景划分为三种：个人预约，团队预约，老师管理，囊括了全部的使用场景。详细的描述在beta阶段的功能规格说明书中已有进行了详细的说明。

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

完成情况如下表所示：

计划完成的功能	完成情况	未完成原因
展示私信内容，删除已读消息	已完成
团队预约界面批量导入预约人员名单	已完成
个人主页：展示预约记录和预约状态	已完成
常见问题解答界面	已完成
答题界面	已完成
学生申请驳回功能	已完成
导出签到表功能	未完成	用户需求发生了变化

我们在规划时预计用户数量达到100人左右，在发布后实际体验人数约70人，我们的预计和实际情况差别不大。

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

在推广我们的系统时，我们发现用户对于重要功能（预约参观体验馆）的接受程度较高，对于其他功能的兴趣稍微少一些，我们也搜集到了许多的建议。在beta阶段后期，我们根据这些意见进行了调整和修改，进行了迭代。我们原先预期做一个专注预约功能的小程序，现在，我们的系统比起小程序更类似于“预约系统”，包含很多场馆预约以外的内容，有助于同学们积累更多安全知识，在一种新的角度上达成了安全教育体验馆进行安全教育的功能。

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

beta阶段的计划整体上还是很完善的（特别是相较于alpha阶段而言）。如果重来一遍，我们可能把更多任务放在开发的前期（而非平均分配），在实际开发的过程中，我们感觉在任务前期没有那么忙，任务推进较快，开发后期各个课程任务量均比较大，考验同学们的时间分配能力。

计划

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

有。我们在beta阶段的第一周集中精力进行了计划，对于每周应该完成的任务进行了计划。当然对于软件工程而言，一个宏观的计划肯定是不够的，还需要根据任务完成的实际情况随时调整计划，以确保产品能够在发布时间之前完成。在任务中，由PM统计大家的任务进度，对计划进行更加细致的调整。

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

对于大多数的不同意见，我们经过充分的讨论后达成共识，再加入到最终计划中；对于少数较为边缘化且计划时不好明确的问题，我们暂时将问题搁置，通过其他方式确定最终计划（比如询问用户对于几种意见的看法）。在beta阶段的第一周结束时，我们完成了对整体计划的确认。在开发的过程中，我们发现在一些细节无法按照原定的计划来进行开发，这时PM会和负责的同学进行交流，重新制定计划，而不是召集全部同学进行讨论。当然，这一过程大多在会议上进行，如果其他同学对于更改存在异议，可以随时提出。

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

在beta阶段，我们没有完成的工作是导出签到表功能。在beta阶段初期，我们根据alpha阶段所做的用户调研，计划做这个功能。可是在开发过程中，用户需求进行了调整，因为在使用线上预约系统后，纸质材料的重要性就降低了，留存材料可能会采取其他形式，为了留出更多时间开发核心功能，我们放弃了这个工作。实际上这一工作实际需要花费的时间不超过4小时，属于较为简单的任务。

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

在计划阶段，我们认为对于答题界面和常见问题解答部分，搜集充足的数据会提高用户体验，所以我们专门安排了一位同学搜集安全方面的知识，并整理成后端同学需要的形式。我们开始时还计划将知识问答的题目分成不同的种类，类似消防常识、地震防护等等，在最后统计每类题目的正确率，在首页生成类似于“知识面板”的雷达图。负责整理数据的同学从任务开始时便开始搜集安全相关题目并整理成合适的格式，然而后面我们发现体验馆的资料中存在非常丰富的题库，相较于重新整理题目，使用现有的题目明显更加合适。至于统计每类题目的正确率，我们考虑到本系统用户的粘性不足，大家答题的意愿也不是很强，如果再对题目的种类进行区分，可能会在首页展示出许多空白，这样就不美观了。所以最后我们呢只在首页展示所有题目的总正确率。

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

在beta阶段，每一项任务都有明确的交付件，而且都得到了PM的确认。在notion中，我们将所有任务单独设置了文档，进行任务的简述和提交，组员存在问题时，也可以在文档中标注，后端可以根据文档中标注的内容了解到后端应该如何实现api接口。

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

项目未出现意外，整个工程按照计划进行推进。项目当中，陆续有同学感冒、生病，这是之前没有料想到的。然而由于在开发初期我么嗯就对计划有了合理的设计，组员们有时间打好提前量，在痊愈后也能根据文档说明确定目前的任务进度，可以立即开始追赶进度，我们的开发还是大体按照计划进行了。

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

有留下缓冲区，我们计划把最后一周作为缓冲区，对我们的产品进行精修和调整。我们确实使用了缓冲区，在开发的最后阶段把产品发布到社团群中，搜集了大家的意见，最后在原产品的基础上进行了优化。

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

目前，我们的计划大致可以支持一次工程的完整开发，如果要进行修改，可能我们会在后端提出更加明确的计划，以提高效率。

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

计划的意义可以不在于push大家赶快完成任务，拼图和积木的完成图同样是一种计划，其中的区别在于，这种完成图可以激励大家朝着完成任务这一目标不断努力。而且，如果所有人对于任务的完成度有一个认识，大家就知道啥时候该冲刺了。

资源

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

资源是足够的，大家的时间和精力足够完成开发任务，通过优化管理方式，我们能更好地完成任务。

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

在beta阶段，我们根据各自的经验估计开发各部分所要花费的时间，在开发过程实时调整。

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

测试过程时间比较紧张，软件和硬件资源足够，美工设计我们参考了体验馆的部分宣传品，花费的时间较少；文档编写占用的时间较多，花费了一些时间和精力，但没有影响编写文档相关部分成员按计划交付任务。

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

对于这个问题没有非常强烈的感受。

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

再来一遍，我们可能会申请一个域名，这样有利于我们进行产品推广。

变更管理

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

相关成员对变更的信息了解速度较快，我们在notion、微信群和会议中进行说明。

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

我们通过会议讨论来决定推迟功能和实现功能，在所有人达成统一意见后决定。

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

我们项目的出口条件如下：

1. 实现基本功能，能够满足用户的基本需求；
2. 在至少三种浏览器和两种操作系统下进行测试，测试不同分辨率下的web显示，测试手机端和电脑端打开效果；
3. 通过一部分用户的测试，搜集意见，进行优化；
4. 发布说明文档。

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

对于突发的变更我们会及时进行调整，但不会制定完整的计划，我们通过成员之间的交流确定更改内容。

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

在beta阶段，我们没有遇到意料之外的工作需求，但是基于我们的工作情况，我认为我们小组处理意料外任务的能力较强，当然前提是该请求任务量维持在正常水平。

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

在开发过程中建立共享文档，将一些关键问题填在文档中，类似于计网课程的常见问题解答文档。

设计/实现

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

在开发过程中，由负责各块的成员自行设计。对于一些任务如设计ui等，由各个成员设计显然不太合适，应该在团队开发开始之前由前端架构师设定全局的ui。

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

有，在这样的情况中，由负责的同学提出自己的想法，和后端以及PM进行商议后实现。

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

我们使用了UML进行面向对象分析，在此基础上进行功能设计，最开始的UML文档和现在的状态一致，没有进行调整。

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

预约功能实际产生的bug最多，预约部分实际限制最多，最复杂，涉及到和后端的交互也最多。发布之后我们发现注册部分存在后端返回token错误的问题，严重影响用户体验。后端没有标明每种返回值对应何种情况。

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

每个人提交的pr需要另一个同学进行合并，合并的同学负责复审代码。

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

在重要功能的实现部分，需要编写设计文档，确保相关同学都能明确实现的具体功能，在后续测试时不会错误理解要实现的功能。同时，及时编写设计文档也有利于发布后编写功能说明文档。

测试/发布

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

是，我们设计了一个测试计划，确保我们的产品能够经得起检验。

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

我们进行了压力测试，测试了各个接口的功能，并得到了100%的正确率。在开发过程中，我们进行了单元测试。

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

我们使用ApiFox辅助前后端进行测试。

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

通过使用自己编写的数据生成器生成大量的数据集，并将数据集通过apifox访问服务器，判断返回值是否符合测试的预期。压力测试方面主要通过apifox模拟多个用户进行并发访问，来进行压力测试。我认为apifox还是非常有用的，不仅可以实现相关的测试，还可以生成测试报告，方便测试人员分析。

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

安全性还存在一些问题；在关闭debug功能后，我们的首页无法显示图片，这个问题是出乎我们预料的。

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

我们会进行更加丰富的测试，而且在测试过程中完全关闭各类debug功能，以求在发布后少出现bug。

团队的角色，管理，合作

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

在本次开发过程中，负责每个部分的成员都有过相关的开发经验（除了PM），较大地发挥了大家的能力。

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

我们进行了压力测试，测试了各个接口的功能，并得到了100%的正确率。

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

有，在部分成员没办法按照计划交付时，其他同学会帮助其完成功能的开发。

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

在PM的介入下进行讨论，确保双方能够达成共识后再进行开发。

总结:

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次? 你觉得团队目前处于 *萌芽/磨合/规范/创造* 阶段的哪一个阶段? 你觉得团队在这个里程碑相比前一个里程碑有什么改进? 你觉得目前最需要改进的一个方面是什么?

第二级，管理级，对于要做的目标清晰，能够遵守既定的规则和计划进行开发。目前团队处于磨合阶段，大家对于彼此的性格和开发能力逐渐有了了解。

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

原则	完成质量
尽早和持续地交付有价值的软件来满足客户	⭐⭐
欢迎对需求提出变更	⭐⭐⭐⭐⭐
要不断交付可用的软件	⭐⭐
项目过程中，业务人员与开发人员必须在一起	⭐⭐⭐⭐⭐
要善于激励项目人员	⭐⭐⭐⭐
最有效的沟通方法是面对面的交谈	⭐⭐
可用的软件是衡量进度的主要指标	⭐⭐⭐⭐
提倡可持续的开发	⭐⭐⭐
对技术的精益求精以及对设计的不断完善将提升敏捷性	⭐⭐⭐
要做到简洁，尽可能减少不必要的工作	⭐⭐⭐
最佳的架构，需求和设计出自于自组织的团队	⭐⭐⭐⭐⭐
团队要定期反省如何能够做到更有效，并相应调整团队的行为	⭐⭐⭐