目录

一、设想与目标

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

​ 我们的二手交易平台旨在解决大学生在买卖二手物品过程中遇到的问题，包括信任度低、信息不透明、交易繁琐等。我们的平台将提供一个安全、透明、高效的交易环境，以便同学们能够轻松买卖二手物品。

​ 典型用户：想要出售或购买二手物品的同学和寻找销售渠道或购买二手库存的小型商家。

​ 典型场景：

1. 个人用户：用户可以轻松发布二手物品，提供详细的商品描述和照片，并与潜在买家直接沟通。买家可以浏览丰富的信息，通过平台进行安全快捷的交易。
2. 商家用户：商家可以在平台上建立二手店面，吸引更多客户，提高销售效率。

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

​ 原计划功能：我们已经成功实现了关键功能，包括用户注册与登录、商品发布与搜索、支付与评价系统等，但前后端接口还未对接。

​ 交付时间： 大部分功能在原计划的时间内交付，但在一些复杂功能上可能存在一些延迟，总体而言仍然在可接受的范围内。

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

1. 在原型设计上多下功夫，在实际的开发过程中，我们发现设计文档中具有不少的纰漏，造成了意料之外的延后。
2. 加强团队交流。前后端对接较难，需要大量沟通时间。

二、计划

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

​ 有，在Alpha冲刺开始前，我们花了两天的时间制定计划。

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

​ 大家有问题就直接提出来或者给我提建议了

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

​ 还剩下接口对接未完成，因为后端接口众多，前后端接口对接是一项艰巨的工作。

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

​ 暂时没有。

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

​ 对于前端页面，我们用界面和原型设计的匹配度来交付；对于后端接口，我们用接口测试返回正确的结果来交付；对于功能，我们用完成原型设计说明书上的定义来交付。

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

​ 并不是项目的整个过程都按计划进行，由于这两周考试众多，冲刺中有一两天大家是没有出什么成果的。而且有些课我没有选，导致了我对剩余时间规划出现了一些问题。

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

​ 留下了两天的缓冲区，有一些作用，起码把基础功能做完了。

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

​ 缓冲区保留不变，更改分配任务的模式，以模块形式分配任务。

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

​ 1、在开发前要做好计划。

​ 2、不能闭门造车，要多看别人的最佳实践。

三、变更管理

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

​ 知道，我们有事直接在群里说。

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

​ 按照优先级讨论决定。

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

​ 对于前端页面，我们用界面和原型设计的匹配度来交付；对于后端接口，我们用接口测试返回正确的结果来交付；对于功能，我们用完成原型设计说明书上的定义来交付。

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

​ 能，在小组讨论后，一般能够做到较好地处理变更，解决问题。

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

  每天的问题都在站立式会议上得以解决。

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

  1、尽量不要私聊，效率很低

  2、面对面开会是效率最高的交流方式

  四、团队的角色，管理，合作

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

​ 组长了解每个人熟悉的领域和意向进行的领域，分配了前端、后端和测试的角色，确实大家都做得很好。

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

​ 开发时遇到不会的功能会互相请教，如果能够有复用的时刻，组员也都能很好的互帮互助。

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

​ 在每天开会时讨论解决。

五、设计/实现

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

​ 在原型设计阶段由所有组员共同完成，时间和人员都很合适。

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

​ 有，通过线下讨论解决。

• 3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

​ 有运用单元测试和uml画类图，这些工具很有效，帮我们解决了很多问题。

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

​ 订单功能的bug最多，有一些是因为vue的this指针指向不明确，有一些是因为mybatis有时会返回错误的自增主键，有一些是因为spring的反射默认传参是小写+下划线格式，前期遇到这些问题时基础不牢，才会被这些问题折腾好久。

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

​ 代码复审由我在合并分支前进行。Alpha 阶段对于代码规范的审查确实没有做好，不同组员写的代码风格截然不同，我怀疑他们没有看代码规范文档。

六、测试/发布

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

  ​ 团队有测试计划，每天站立式会议时成员汇报自己今天的成果、实现的方法，测试组的同学们次日的任务便是测试这些东西。附上测试随笔

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

​ 还没有，我们还没有发布正式的App。

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

​ 有的，使用Postman（后期使用Apifox）来做接口测试，用junit做单元测试。

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

​ 目前还没有做这一点的考量，确实是一个后续开发需要注意的问题。这些测试很有用，帮我们发现了不少问题。

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

  返回数据异常、数据库为空的时候插入失败、mybatis返回错误的自增主键、PostMapping只能接收到小写开头的数据等等。

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

​ 1、应该预留足够的时间进行测试和发布调试，进行全面、全方位的测试。

​ 2、要预先做好测试计划。