事后诸葛分析

成员角色及具体贡献

设想和目标

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

   我们的软件，要解决的是帮助用户简单话购物过程中的对比步骤，使用户不需要跑几家平台去货比三家。我们的典型用户是购物精打细算的人群，典型场景是购物时进行商品的对比。

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

   我们原计划实现集成各购物平台的商品信息并进行对比，在最后我们按时完成了所有功能，并且在测试阶段通过分享找到了20+的人数进行测试，后续的用户数量需要在平台更加成熟以及推广之后才能达到预期。

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

   在每一个阶段，我们都可以清晰感受到软件的成长与蜕变，在需求分析与改进阶段，我们可以看到软件的需求逐步清晰与精准；冲刺阶段，我们每一天都可以看到软件在向着成熟出发；在alpha阶段，软件在测试中，逐渐走向完善与流畅，用户体验也在这个阶段有了很大的提升。我们可以通过我们的文档去进行衡量我们软件工程的质量，随着每一个阶段的推进，文档都会有所积累。

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

   在测试的过程中，用户对于软件的接受程度是达到我们的预期的，但是对于一个与购物相关的平台来说，我们的用户量是远远不够的，因此我们虽然有在向着目标前进，但是我们离我们的目标还很远，只能说达到一个好用的地步，但是没有那种经过大用户量冲洗的结实。

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

在开发的过程中，我们吃了很多对技术不熟悉的苦。比如说有同学完全没有接触过后台技术或者是AI技术的，但是项目要求下需要在一两周内将技术学了并应用到项目中，但是实际的应用效果并没有很好，特别是对于一个完整的项目，需要学习的东西是很庞大的。如果历史重来一遍，我们可能会留出更多的时间给对技术不熟悉的同学去学习技术的时间，然后再来反哺到项目中。

计划

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

   我们做计划的时间是充足的，只要几次大大小小的会议，大家就可以对目标以及过程有一个很清楚的认知。

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

   通过友谊性的争吵来解决。争吵是可以解决很多问题的，因为争吵也是一种沟通。

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

   我们计划的工作都完成了。

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

   有的，比如说网页的加载性能优化，实际上在目前来说这么小的一个项目，根本没有必要做页面加载性能优化。

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

   是的，我们使用azure来分发定义我们的任务，并在上面进行交付，且每一件任务都会通过组长的验收。

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

   在项目功能本地测试没有问题后，我们准备进行发布的时候，发现项目总是无法在公网被访问到，以及接口放在服务器上后同样无法被访问到。这个问题我们后来通过配置解决了。这就是我们当时没有估计到的风险，因为我们组里面没有对服务端技术熟悉的人，因此在这一方面的经验有所缺失。

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

   有，用于应对一些突发情况。

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

   一般来说不会，因为已经预留有足够的缓冲区。

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

我们觉得一个团队中应该有不同领域的人才，这样才可以有条件去应付不同的情况。或者是团队里面的每一个人都有很强的学习能力，可以在遇到情况的时候通过各种方法去解决一些可能不在自己原有领域中的难题。

资源

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

   有的，一般的软件只需要简单的智能设备就可以运行

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

   通过我们之前积累的开发经验来进行估计，精度这方面多多少少会有偏差，但是我们留有足够的缓冲区。

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

   足够的，一般的软件，软件、硬件资源都是足够的，毕竟是要一般用户去使用的，人力这方面也是无需担心的，而美工设计、文案等因为我们组里面有丰富设计经验的前端同学以及有相关的产品去参考，因此我们从一开始就没有很担心，事实证明我们不担心是没有错的。

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

   我们组里面的每一个人都有自己擅长的领域，并且我们的领域重叠部分不大，因此我们团队效率很高。

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

在资源这一个方面我们暂时没有可以改进的地方。

变更管理

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

   是的

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

   讨论

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

   有，我们事先就对核心功能做了定义，然后定好了出口条件。

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

   可以的，因为大家都是学生，对于可能的变更，有充足的时间去做出反应与计划应对。

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

   是的。我们很好地处理了在部署与发布的过程中遇到的问题。

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

在变更管理这一方面我们暂时没有可以改进的地方。

设计/实现

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

   设计工具由前端部分负责人在项目开发之前完成。这是最合适的时间，也是最合适的人。

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

   没有，我们事先就确定好了各种任务以及相关的事项，所有的事情都是有条有理的。

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

   是的。我们在后端代码中使用单元测试来确保服务可以正常运行。而UML则贯穿了整个项目的开发过程，从项目流程设计到函数设计等等，这些工具无疑都是可以帮助我们进行高效开发的。项目开始时候的UML文档还很单薄，但是在项目已经截止的现在，我们已经积累了很多的UML流程图。

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

   搜索功能，因为搜索是与推荐绑定的，然而推荐这个问题，是很复杂的，现在很多公司都还投着有很大的一块资金在推荐这一方面，因此我们可以看出来，一个精确的推荐是很难的，也因此所以在这个过程中就产生了相对来说较多的bug。在发布之后我们就没有找到太多的bug了，因为项目本身的功能还是比较单一的。

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

   代码复审首先是经过代码编写者自己的审查，然后要经过组长的审查才可以签入到公共分支中，我们的开发都遵守各自语言以及环境的代码规范。

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

客户端部分也可以尝试进行集成测试，虽然现在的工具不多，但这样对项目的持续改进是有很大的好处的。如果再来一遍，我们会将集成测试框架引进客户端。

测试/发布

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

   有的，我们全员开发者以及一批测试者一起对软件进行测试，而且在开发过程中也有对代码进行单元测试与集成测试。

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

   是的

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

   我们使用unittest

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

python可以使用Pytest这个自动化测试工具进行测试，这样就不需要每次都手动测试了

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

   我们使用chrome的lighthouse来对web页面进行性能测试等，使用unittest、pytest等工具对python代码进行单元测试、集成测试，使用 对服务端接口进行测试 ，这些测试工作都是有用的，它使我们的项目更加安全。

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

   发布之后接口无法使用。

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

在测试这一方面我们暂时没有学到什么。

团队的角色，管理，合作

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

   我们根据每个人的特长去分配任务，但是确实没有做到人尽其才。

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

   有的，在遇到问题的时候我们都是沟通解决的。

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

   我们会一起进行沟通，去探讨解决方案。

总结:

团队状态

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

   可重复级。

2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

   规范期。

3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?

   我们的复盘效率提升了，现在我们可以很快地总结出犯的一些错误并进行反思改进。

4. 你觉得目前最需要改进的一个方面是什么?

​ 每一个人的知识储备和技术储备还是远远不够的

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

   • 第一条原则：我们最重要的目标，是通过持续不断地及早交付有价值的软件使用户满意。我们小组在每个里程碑中都能够按时交付可用的软件，而且能够根据用户的反馈和需求进行调整和优化，提高了软件的价值和质量。
   • 第九条原则：可工作的软件是进度的首要度量标准。我们小组在每个里程碑中都能够通过单元测试和集成测试来保证软件的可工作性，也能够通过场景测试和用户验收测试来保证软件的可用性，提高了软件的稳定性和可靠性。

软件工程质量

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

   将代码规范检查加入到仓库提交过程中，代码规范可以通过我们内部的协商一步商定。

2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

   我们需要有一个更大的目标，在此目标的基础上对架构进行升级，重构也是一样的道理，但是重构可以发生在我们每一次的开发过程中，对一些不合理的地方进行小重构。质量的提高可以体现在项目的可维护性以及项目的功能这方面。

3. 其它软件工具的应用，应该如何提高？

   在觉得有必要的时候，可以去进行专门的学习。

4. 项目管理有哪些具体的提高？

   我们学会了通过azure进行任务的分发、项目的管理以及项目的持续构建。

5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

   在这一方面我们计划再编写一个平台去监控用户的活跃程度等及其他数据，进行分析并优化反哺原本的平台。

6. 项目文档的质量如何提高？

   需求变更、验收的细节问题等都可以加入到文档中，并且接口文档、设计文档、使用说明书等都要进行产出。

7. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

   • 制定明确的会议目的、议程和时间，邀请相关的人员参与，确保会议的有效沟通和决策；
   • 使用合适的工具和方法来估算项目的工作量、成本和时间，考虑项目的复杂性、不确定性和风险；
   • 采用迭代式的开发模式，定期检查项目的进度和质量，及时发现和解决问题，避免项目延期和超支；
   • 建立风险管理机制，识别和分析项目的潜在风险，制定应对措施和预案，减少风险的影响；
   • 实施变更控制流程，对所有的变更请求进行评审和批准，保持项目的一致性和完整性；

8. 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)

   • 我们认为这篇文章对软件工程的理论和规律做了一个比较全面和系统的概述，涵盖了软件工程的基本概念、核心问题、主要方法和常用模型等方面，对于初学者有一定的参考价值
   • 我们觉得这篇文章的优点是用了很多具体的例子和图表来解释和说明软件工程的理论和规律，使得内容更加生动和易懂，例如用飞机的发展历史来比喻软件开发的不同阶段，用瀑布模型、V-W模型、原型模型等来展示软件生命周期的不同形式
   • 我们认为这篇文章的不足之处是没有深入探讨软件工程的理论和规律的适用性和局限性，没有分析软件工程的发展趋势和挑战，没有提供更多的实践经验和建议，也没有引用更多的权威的文献和资料

会议照片