MachineGuard机房捍卫者——alpha阶段问题总结随笔

机房捍卫者队团队 2023-06-02 22:30:30

这个作业属于哪个课程	2023软工W班
这个作业要求在哪里	https://bbs.csdn.net/topics/615412167
团队名称	Machine Guard
这个作业的目标	alpha阶段问题总结
其他参考文献	无

我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 这个软件旨在解决机房安全监控方面问题，远程监控和维护问题，信号电源管理问题，以及机房数据统计和分析问题。
- 这个项目已经定义的足够清楚，项目使用统一化的控制平台，结合数字孪生概念、web监控和维护机房内仪器，整合ioT和AI技术实现多维度安全监控，信号电源接管以及后台数据统计等功能。
- 典型用户包括机房管理员、IT运维团队、安全团队等等，典型场景包括数据中心、IT基础设施提供商、企业机房以及公共服务设施等等。
我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)
- 原计划的功能基本全部完成，例如：用户登录、监控模块、日志模块、统计模块以及管理员控制模块。
- 按照原定的计划，我们准时完成了alpha冲刺阶段的预期目标并如期交付。
- 原计划中，这个阶段的产品并不对外公布，仅在小范围的局部用户试用。试用达到了预期的用户量。
和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
- 是的，团队软件工程的质量确实提高了。团队成员的编程技能水平提高，大概提高30%，通过成员的编程效率、代码出错率等因素来进行衡量。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 我们的试用情况与预期一致，用户对重要功能的接受程度与我们的预期基本一致。
- 我们离目标确实更近了，团队会继续努力。

计划

是否有充足的时间来做计划?
- 我们有充足的时间来做计划，以确保计划的有效性和执行力。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 我们会积极促进大家之间的交流，相互倾听，来了解每个人的观点和建议，努力达成共识，来寻找最佳的解决方案，确保计划的质量和可行性。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 是的，我们成功地按照原计划完成了所有的工作任务。
有没有发现你做了一些事后看来没必要或没多大价值的事?
- 没有发现，我觉得我们做的事情都是有意义的。
是否每一项任务都有清楚定义和衡量的交付件?
- 是的，每一项任务在计划阶段都有清晰的定义和明确的交付件。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 项目的整个过程基本都按照计划进行，但是在alpha结尾时，前后端的对接发生了一些问题。
在计划中有没有留下缓冲区，缓冲区有作用么?
- 我们留下了一定的缓冲区，在发生问题时还是起到了一些作用。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 未来的计划我们会针对新加入的人的岗位做一些灵活的变动。因为考虑到新加入的同学可能在刚开始的效率会比较低，有可能会完不成我们既定的原先岗位要求的任务量，实际上这个任务是动态分配给相同岗位的其他人共同承担，之后的任务量会再平衡。

资源

我们有足够的资源来完成各项任务么?
- 是的，我们团队拥有足够的资源来完成各项任务。
各项任务所需的时间和其他资源是如何估计的，精度如何?
- 我们根据项目的需求、复杂性、之前类似任务的经验以及团队成员的能力和可用资源等进行估计，尽管我们尽力做到准确估计，但还是受到一些不可预计的因素的影响。但我们会持续监控和评估任务的进展，并灵活调整计划来应对偏差。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 测试的时间足够，人力资源足够，硬件资源也足够。对于那些不需要编程的资源，我们还是尽量做到完善。
你有没有感到你做的事情可以让别人来做（更有效率）?
- 没有，在考虑到目前团队成员的技能水平情况下，我相信将这个任务分配给我会是最佳的选择，我可以有效分担团队成员的工作负荷，进而提高团队整体工作效率。

变更管理

每个相关的员工都及时知道了变更的消息?
- 是的，通过每日的站立式会议，变更的消息会及时地告诉每个相关的员工。此外还会通过即时通讯软件、共享文档等形式来通知消息。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 考虑项目的时间限制和可用资源，对功能进行评估。在时间不够充裕地情况下，我们会推迟一些优先度较低的功能，以确保在有限时间内实现最为重要的功能。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 项目的预期功能全部实现，并且通过测试即可。
对于可能的变更是否能制定应急计划?
- 可以。对于可能的变更，我们能制定应急计划。
员工是否能够有效地处理意料之外的工作请求？
- 可以。在制定计划时，就考虑类似到情况，因此会适当地给每个人分配任务。

设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 设计工作在需求分析后，由我们团队的组长完成的。是的，是合适的时间，以及合适的人。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 有的，一般选择听取团队其他成员意见，集中分析，解决问题。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 在团队定题之后的需求分析中，就使用了大量UML来帮助设计，包括UML中的类图和用况图等。在团队的项目开发过程中，我们使用了Junit这个单元测试工具来完成单元测试工作。
- UML工具在帮助我们理清我们项目的功能、使用场景、业务流程等方面起到了帮助作用。单元测试帮助我们模块地测试代码功能。
- 项目刚开始设计的UML文档比较理想化，很多时候没有考虑到实际在开发过程中，特别是前端开发过程中遇到的问题。在开发过程中，我们的项目最终表现出来的样子并没有完全按照原先UML的设计的样子。
- UML并没有更新，因为大体是相同的，有一些细节的差别。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 我们项目的监控功能产生的bug最多，因为这个功能涉及到众多类和交互，更加容易产生bug。
- 在发布之后，我们发现监控不能正常推流，这是因为开发环境与生产环境的不同，导致我们没有意识到这个问题。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 由后端成员进行代码复审。是的，严格执行力代码规范。

测试/发布

团队是否有一个测试计划？为什么没有？
- 是的，我们团队会进行基础功能测试、性能测试、安全测试以及用户体验测试并生成相关测试报告。
是否进行了正式的验收测试？
- 是的，进行了正式的验收测试。
团队是否有测试工具来帮助测试？很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
- 是的，我们借助了测试工具，例如apiFox，来进行自动化的测试以及自动生成测试结果报告。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 可以通过模拟不同负载和场景下系统性能表现，记录各项指标，测试软件的效能。
- 利用压力测试工具，例如：Apifox，来模拟用户请求接口，对系统进行压力测试。
- 这些测试是有用的，性能问题或许是我们应该优化的地方。
在发布的过程中发现了哪些意外问题？
- 发布的时候，软件需要运行在区别于开发时的环境中，这导致一些功能受限，不能像在局域网中一样运行。这使得我们只能大概地演示某些项目，而不能做到直接让用户去体验。

团队的角色，管理，合作

团队的每个角色是如何确定的，是不是人尽其才？
- 根据团队成员擅长的技能将其分配到前端或者后端开发，再根据团队成员的技能水平高低分配不同难度的任务，以此尽量做到人尽其才。
团队成员之间有互相帮助么？
- 是的，我很经常看见大家，相互请教。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 改进团队的沟通，在团队成员之间建立良好的沟通渠道，集中分析问题，最后解决问题。

总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 我觉得我们团队目前的状态属于CMM中的第三级别——定义级别，项目具有标准的软件开发流程和文档。
你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
- 一开始我们团队应该是处于磨合阶段，大家之间的交流并不是非常流畅，但通过这次alpha冲刺，每个人都经历了充分地磨合，所以我觉得现在我们的团队处于规范阶段，并且我们会努力迈向创造阶段的。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 大家都学习了许多新技能，知识水平也有所上升，增强了团队的综合实力。
- 团队成员之间的沟通也变得频繁，协作效率大大提高。
你觉得目前最需要改进的一个方面是什么?
- 团队成员的技能水平参差不齐，往往某个技能水平高的成员的工作量会远超于一些技能水平不足的成员，我觉得应该让技能水平不足的成员多抽出时间学习，让每个团队成员的工作量得到较为合理的分配。