项目 内容
这个作业属于哪个课程 课程社区
这个作业的要求在哪里 作业要求
我在这个课程的目标是 凝聚整个团队通过一定的软件开发流程，在预计时间内发布”足够好”的符合用户需求的软件，并证明其是可维护和持续发展的，并在其中做出应有的贡献，提升进行软件工程开发的能力。
这个作业在哪个具体方面帮助我实现目标 帮助我们总结alpha阶段的开发经验，并从相应的问题中学到教训，为后续beta阶段的开发铺好道路。

[T.14] 团队项目：Alpha 阶段项目总结

设想和目标

问题

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

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

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

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

回答

  1. 我们的软件要解决的问题是让那些有好点子的扑克牌发烧友能够自由的创作他们想要的规则并且和好友共同分享竞技，体会打牌的快乐。定义的较为清楚，对于典型用户和典型场景有较为清晰的描述，详见项目展示。
  2. 我们除了规则构建的实现没有正常实现，其他功能都已经完成并按时交付。
  3. 当前为alpha阶段总结，因此目前不存在前一个阶段。
  4. 由于分工的不合理原因以及部分同学的失职，导致预期的功能没能按时完成，导致最后全员赶工，因此未能完成发布后的用户体验环节，此处没有相应的数据，争取调整后续分工安排在beta阶段获取对应的用户体验。我们正在朝着目标努力靠近。

计划

问题

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

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

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

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

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

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

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

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

回答

  1. 是的。
  2. 组织开会，由每位持有不同意见的同学分别发表对于计划的意见，再由所有团队成员进行投票决定支持谁的意见，然后以票高者为准。
  3. 有的，由于分工的不合理原因以及部分同学的失职，导致预期的功能没能按时完成，导致最后全员赶工，因此未能完成发布后的用户体验环节，此处没有相应的数据，争取调整后续分工安排在beta阶段获取对应的用户体验。
  4. 没有，倒是少做了很多事。
  5. 没有，我们认为这也是我们没有最终驱使后端的开发同学及时启动开发的最主要的原因。
  6. 出现了后端同学的进度迟缓导致项目一度停滞的情况。我们错误的估计了后端开发的工作量并将其交给了一位崇尚古法编程的同学，为什么没有估计到一是因为我们一度认为较多的工作应该在前端而非后端，导致分配的不合理；同时，出于后端开发的同学的信任(拍胸脯说一个人行)且缺乏足够的沟通，导致进度拖慢。
  7. 没有。
  8. 提前进行规划，并且严格按照计划进行执行，形成相互监督的机制，共同督促按时完成计划。

资源

问题

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

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

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

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

回答

  1. 有的。
  2. 通过大家一致表决并投票来估计各项任务所需的时间和其他资源，精度一般。
  3. 由于阶段后期项目大赶工，导致来不及做相关的测试，因此测试的时间不够，同时后端开发部分人员配置不合理，资源不够。对于那些不需要编程的资源，例如接口的设计和功能的定义等，低估了其难度，并且没有在一开始的时候就确立好，导致后端同学迟迟不动手而拖慢了进度。
  4. 后端的工作应该及时的分出来多一个同学参与，而不是让一个人用古法编程手搓。

变更管理

问题

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

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

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

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

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

回答

  1. 在微信群上的消息可以及时的通知到所有相关的员工，但是飞书上的消息由于其独特的提示方式且内存不合后端开发同学的意，导致飞书上的消息难以通知到这位同学，因此我们调整了一些相关的变更消息统一在微信群中进行，而飞书上只进行文档的共享工作。
  2. 采用了一致开会表决的方式来决定“推迟”和“必须实现”的功能，具体就是某一功能是否会严重影响用户的体验来区分是否“必须实现”。
  3. 定义的出口条件就是团队内所有人都同意且开发的相关功能基本涵盖预期目标以及使用和测试过程中不会出现明显bug。
  4. 可以的，由于后端同学的开发进度问题，我们在alpha阶段后期紧急征调一位运维和一位测试人员参与到最后的前后端开发中，以此来应对这一应急情况。
  5. 可以的。

设计/实现

问题

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

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

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

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

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

回答

  1. 设计工作在项目初期进行，后续由于后端同学不清楚部分接口和通信帧的定义因此后续又统一进行了一次设计工作，前一次是合适的时间，但是后一次不是，两次都是由合适的人即pm进行。
  2. 有，通过协商讨论来确定一个较为清晰的设计。
  3. 没有，主要依靠团队pm进行文档撰写。
  4. 规则构建的功能，因为这个规则构建这件事本身就存在一定的难度。
  5. 此前由于工期较赶，没有进行代码复审，同时开发组的同学认为不需要代码规范，因此也没有采用相关的代码规范。

测试/发布

问题

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

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

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

    很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

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

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

回答

  1. 有测试计划，目前是做单元测试和e2e测试，后面补压力测试、真实websocket测试。
  2. 进行了正式的测试验收，通过不同浏览器条件下手测平台的适配情况。
  3. 团队使用了相应的测试工具来帮助测试，已使用的测试工具如下：
    • 前端单元/组件：Vitest
    • Vue 组件挂载：@vue/test-utils
    • DOM 环境：happy-dom
    • 前端覆盖率：V8 coverage，通过 @vitest/coverage-v8
    • 前端 E2E：Cypress
    • E2E 服务编排：start-server-and-test
    • 前端构建/类型检查：vue-tsc、Vite
    • 后端测试：cargo test
    • 后端格式检查：rustfmt
    • 后端静态检查：clippy
    • 后端参数化测试：rstest
    • 后端 mock：mockall
    • WebSocket 测试依赖：tungstenite
    • CI 平台：GitHub Actions 测试工具
  4. 目前仍处于赶工阶段，因此并未考虑效能和压力测试。实测效果来看，还是可以减少一些犯简单错误的风险。但是仍存在较为复杂的情况无法测试出来的情况，因此仍需要对覆盖率以及复杂情况进行考虑，需要提升测试的精度和粒度。
  5. 发布时出现了页面跳转异常的情况，但经过查看相关代码发现是地址分发出现了问题，修改后就可以正常跳转了。

讨论

  1. 对比敏捷的原则，你觉得你们小组做得最好的是什么？
  2. 什么是在下个阶段要改进的地方？越具体越好。

讨论截图如下：
image

image

image