创业6+1+2-事后诸葛亮

这个作业属于哪个课程	2021春软件工程实践|W班(福州大学)
这个作业要求在哪里	团队作业六——beta冲刺+事后诸葛亮
团队名称	创业6+1+2
其他参考文献	《构建之法》

---

一、设想和目标

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

   • 我们希望解决消息信息杂、信息乱和获取信息困难的问题
   • 定义明确
   • 典型场景

   ​

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

   • 原计划的前台功能基本完成
   • 基本按照原计划的交付时间交付
   • 由于未发布版本，用户数量暂未达成

   前台功能

   功能模块	完成情况	存在问题
   登录-找回密码	完成
   注册	完成
   浏览消息页面	完成
   浏览消息列表、查看消息详情及删除消息	完成
   浏览任务列表	完成
   搜索任务/帖子	完成
   选择任务/帖子类别	完成
   发布任务/帖子-发布或存为草稿	完成
   浏览任务详情-收藏或获取发任务者联系方式	完成
   浏览帖子详情-收藏、点赞、评论或分享	完成
   浏览个人信息	完成
   设置系统主题	完成
   进行学生认证	完成
   浏览已发布信息-浏览详情或删除	完成
   浏览个人草稿-浏览详情或删除	完成
   设置个人信息-设置密码、用户名、头像或手机号	基本完成，仍存在瑕疵	头像图片上传这块存在瑕疵。
   举报	未完成	任务安排，将安排在Beta阶段和后台一起完成。

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

   • 软件工程质量较上一个阶段有所提高

   • 在成员个人工作方面：经过上一个阶段，成员们可以较为准确地预计任务完成时间，无需按照alpha最开始，规定的每日工作开始和工作结束时间，成员可根据当日个人安排，动态安排冲刺时间。

   • 在项目管理方面：修改项目管理工具，改成使用禅道进行项目管理。

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

   • 由于前台功能仍旧存在瑕疵，因此版本尚未发布，无法评估用户行为。

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

• 经验：开发成员经过一阶段的磨炼，已经可以很好地预计个人当日开发所需时间。前后端对接在经过上阶段的实践之后，已经修改了沟通方式。
• 教训：前后端接口对接当中，成员沟通不及时会导致这部分的拖延。项目管理中，没有提前规划好本阶段完成的任务，将会严重影响项目的实际开发
• 改进
  • 沟通: 在开发阶段要及时关注前后端成员之间的沟通问题，对于文档的修改应及时反馈。
  • 合作：在开发阶段，项目管理应当持续调动成员的积极性，适当安排定时定量的线下团队冲刺。
  • 管理：在冲刺前期，制定并确认本阶段需要完成的任务。

二、计划

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

   • 有充足的时间做计划

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

   • 对于计划的不同意见，成员们会在开会时提出，并且现场讨论解决方案。

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

   • 原计划的工作基本完成，但仍存在瑕疵。

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

   • 有,具体请查看各成员个人编写的内容。

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

   • ​ 清楚

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

   • 项目遇到了前后端交互中接口对接不顺畅的意外，因为大家经验少，在开发前期没有预估到这个问题的发送。
   • 项目在注册功能遇到了无法使用session的风险，由于开发经验不够
   • 学生认证部分接口设计出现问题，由于教务处在冲刺时突然改版。

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

   • 在计划中没有留下缓存区，但是在实际开发中，由于本组提早进入冲刺阶段，因此后面遇到问题时，有一两天停止全体冲刺，将时间留给个人对对接中出现的问题进行修改
   • 缓冲区有起作用，具体请查看各成员个人编写的内容。

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

   • 在前后端对接之前，进行更全面的测试。
   • 修改技术实现方式
   • 修改项目部署计划

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

• 测试：在与他人进行工作对接之前，对自己负责的部分进行更全面的测试。
• 缓存区：明确为项目制定缓存时间。

三、资源

该部分由全体成员参与编写,具体内容请查看 (未补偿)

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

   • 时间：团队提早开始冲刺，为后期留下缓冲时间。
   • 技术：在开发前期，开发人员各自进行技术学习。

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

   • 根据以往经验，结合需要完成的任务数（接口、功能等）估计任务所需的时间。
   • 在冲刺开始阶段，精度较差；在冲刺中期，由于有了前期冲刺的经验，精度有所提高；在冲刺后期，正常情况下每日可以估计所需时间，但是当团队遇到风险/出现问题时，需要花费比以往更多的时间。

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

   • 足够

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

   • 偶尔感到我做的事情可以让别人来做。
   • 由于能力欠缺。

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

• 时间估算：提高时间估算的能力，应当将不可估量的因素加入时间估算的条件中。

四、变更管理

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

   • 团队中需要全体通知的消息主要通过三种途径传播：一是在站立式会议时提出；二是在团队群中提出；对于需要公示的信息，例如团队内自评互评表、评分情况等在团队文档中展示。保证每个相关的员工都知道了变更的消息。
   • 对于需要及时通知的消息，会选择以下两种方式通知：一是在团队群中@相关成员；二是直接私聊该成员。基本保证相关员工及时知道消息。

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

   • 定义“推迟”：每日制定的任务无法在两次站立式会议之间的时间内完成。
   • 定义“必须实现”：与项目核心需求（整合信息？）有关的功能。

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

   • 在项目组《需求规格说明书》中定义了验收标准及成绩评定，定义清晰明确。

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

   • 在开发之前，对于可能遇到的变更没有制定完善的应急计划。
   • 在开发阶段，对于实际遇到的变更，会立即讨论应急方案，保证及时解决。

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

   • 成员对于修改的原型都会欣然介绍。

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

• 制定应急计划：项目组将在冲刺之前制定，对于可能出现的问题和风险的现实处理的应急计划

五、设计/实现

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

   • 是在开发阶段开始前设计，由本组三位同学完成。
   • 是合适的时间，合适的人。

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

   • 没有

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

   • 单元测试：有效
   • UML：在实现过程中，前期设计的类图和各个功能的活动图在实际开发中起作用，并有效提高成员们开发效率。

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

   • 前后端交互。前后端对于接口的修改，没有及时在接口文档中体现，导致两端在对接的时候经常出现bug，例如，传输的数据无法传输到后台。
   • 由于该版本上尚未发布，暂无法评估发布后遇到的bug。

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

   • 严格执行代码规范。
   • 在冲刺前期，时间比较富裕的时候，有进行代码复审。
   • 在冲刺后期，由于成员忙于解决bug，没有进行完整的代码复审。

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

• 问题的产生是一环套一环的，在开发前期，前后端对接口的修改，没有及时将修改结果反馈到接口文档中，导致后期两端对接时经常出现bug。

六、测试/发布

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

   团队安排了一个测试计划，具体请查看团队测试文档

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

   • 团队在《需求规格说明书》中制定了各类验收标准。
   • 在冲刺最后半天进行验收测试，评定等级为良好

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

   测试类型	测试工具
   单元测试	Junit、chorme浏览器、firefox浏览器
   功能测试	iphone6\华为、chorme的插件React Dev、firefox浏览器
   接口测试	Postman、浏览器自带的检查、knife4j
   集成测试	iphone6\华为

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

   • 前后端均有使用对应工具对软件的性能进行测试，但尚未进行压力测试。
   • 测试工作有效，但是测试用例设计地不够精细，曾出现测试结果中测出问题时，并不清楚具体出问题的地方。

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

   • 尚未发布。

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

• 软件测试需要随着软件开发一同进行，对各位成员每日的成功进行及时的测试，可以更好地保证项目进度。
• 如果重来一遍，我们已经对测试有了更清晰的认识，每日进行测试的效率将会提高。同时，应对测试用例的设计多下功夫，争取在测试过程中精准地致命出现问题的地方，避免无用的修改及再测试。

七、团队的角色、管理、合作

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

• 团队首先确定是分前端和后端开发，然后，开小组会议讨论个人分工。

• 在组内，每个人都担任自己选择的角色，提升自己的能力，做到人尽其才，各有所得。

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

• 有的。当项目组成员出现Bug的时候，其他同学在自己完成任务的情况下，会帮助解决Bug

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

• 首先，团队在项目管理和前后端合作都选择了线上文档的方式进行交流。每日会议通知会发在qq群中，一些公告会发布在qq群或团队统一编写站立式会议内容的编辑器（hedgedoc）中，保证全员知晓公告。

八、会议记录

在这部分，将展示各位成员在“事后诸葛亮”会议中编写的内容。

【珏 - 061800217】

1. 计划

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

答：我的计划是对项目进行一系列测试:单元测试，接口测试，功能测试，界面测试，集成测试和压力测试，最后两项测试任务没有全部完成，因为项目存在一些小瑕疵需要改进，将后两项测试的部分内容挪到下阶段进行。

• 有没有发现你无用功？具体描述一下

答：有，在刚开始使用项目管理工具的时候，由于该平台属于新型平台，暂时没有关于敏捷模型使用的手册，于是自行学习和使用了一段时间，但是其中有很多功能用不上/不需要。有时候，在做事情之前，没有先考虑任务的进行和想要获取的结果，抓不住完成过程中的重点，导致做了很多无用功，比如在制作团队成员自评互评表时，没有仔细思考本阶段对于开发人员比较需要注重的工作质量，因此设计的第一版评分表并不契合当前团队状况。

• 在团队合作过程中，是否每一项任务都定义清楚，对于“完成”有明确的定义？

答：是的，在冲刺之前，项目组在《需求规格说明书》中定义了各页面的输入输出，并制定验收标准。

• 在团队合作过程中，是否遇到了没有估计到的风险，是什么风险呢？为什么没有估计到?

答：团队合作过程中遇到了关于前后端连接，连接花费了比预估更多的时间的风险。没有估计到是因为成员经验较浅，没有估计到zhg

• 在你的计划中是否有留下缓冲区，缓冲区有作用吗？

答：在我的计划中没有明确定义缓冲区，但是在实际开发中，会根据实际情况留出缓冲时间，并且起到作用了。

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

答：将明确定义缓冲区，合理预估个人工作所需时间，并且明确定义团队每日冲刺任务，避免“加班”。

• 你在Alpha中学习到了什么，如果历史重来一遍，你会做出什么改进？

答：学习到应当明确地为团队和个人定义缓冲区。如果历史重来一遍，我会在冲刺阶段开始前制定缓存时间，并在开发阶段中严格按照计划推进团队进度。

2. 资源

• 你是否拥有足够的资源完成各项任务？（时间，技术等等）

答：是

• 你是如何估计完成任务所需的时间？精度如何？

答：估计任务所需时间主要是根据任务量结合各成员开发情况。由于开发情况无法准确估计，精度一般

• 测试的时间，人力和软件/硬件资源是否足够?

答：足够

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

答：没有

• 就以上四个问题，你有什么经验教训，如果历史重来一遍，你会做出什么改进？

答：在开始做事情之前，先考虑需要经过那些部分，需要达到什么样的目标。如果历史重来，我希望能更好地估计完成任务所需要的时间，并且使用估算的时间激励自己提高效率。

3. 设计、实现

• 设计或实际编码工作有没有碰到模棱两可的情况？（例如，代码风格不同）

答：无

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

答：无

---

【九歌 - 111801429】

1. 计划

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

答：原计划是完成帖子和任务相关的页面，最后都做完了，好耶！

• 有没有发现你做了无用功？具体描述一下

答：有的。在编写前端的接口设置的时候，是按照之前设计好的接口文档编写的。但是，后端在实际实现的过程中，并不完全按照接口文档编写。而前端又不知道，所以在联调的时候，这部分的编写就全部都得重新写。

• 在团队合作过程中，是否每一项任务都定义清楚，对于“完成”有明确的定义？

答：每项任务定义清楚，对于“完成”的定义即在没有出现明显bug的情况下实现该项任务。

• 在团队合作过程中，是否遇到了没有估计到的风险，是什么风险呢？为什么没有估计到?

答：注册功能差点无法使用。因为在计划使用session的时候，并没有考虑到跨域之后无法携带session的问题。

• 在你的计划中是否有留下缓冲区，缓冲区有作用吗？

答：有留下缓冲区，并有发挥作用，利用缓冲区的时间加上了动画。

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

答：尽量在计划前期把任务做完，并预留一定的时间用于后期的一个机动。

• 你在Alpha中学习到了什么，如果历史重来一遍，你会做出什么改进？

答：学习到了react的相关插件的用法。如果重来一遍的话，应该改进关于react的组件复用。

2. 资源

• 你是否拥有足够的资源完成各项任务？（时间，技术等等）

答：有的。只要不摸鱼，时间就是有的。有了时间，总能通过自学、百度或者问同学的方式解决技术问题。

• 你是如何估计完成任务所需的时间？精度如何？

答：通过以前做项目的经验。由于react是刚学的，最开始的时间精度会比较差。之后一两天，就会比较准确些。

• 测试的时间，人力和软件/硬件资源是否足够?

答：足够。

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

答：不会。每个人都有自己的任务要做。

• 就以上四个问题，你有什么经验教训，如果历史重来一遍，你会做出什么改进？

答：在刚开始一个项目的时候，要先给自己预留足够的时间。毕竟，计划跟实际还是会有差距的。

3. 设计、实现

• 设计或实际编码工作有没有碰到模棱两可的情况？（例如，代码风格不同）

答：没有。在设计阶段就已经规定了代码规范。

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

答：有的。通过与之前写的代码规范进行比对，并严格执行代码规范。

---

【蔡家鑫 - 221801113】

1. 计划

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

答：原计划的工作基本上算是做完了，不过移动端的一个小功能在某些机型上还是有点小bug，具体原因还在研究。

• 有没有发现你做了无用功？具体描述一下

答：基本上是没有吧。

• 在团队合作过程中，是否每一项任务都定义清楚，对于“完成”有明确的定义？

答：定义挺清楚的。

• 在团队合作过程中，是否遇到了没有估计到的风险，是什么风险呢？为什么没有估计到?

答：注册功能吧，因为本地测试的时候session不会丢失，高版本Goggle好像对用户的隐私有了更好保护，导致session获取不到。这个还是因为开发经验不够的原因吧。还有就是学生认证部分吧，在冲刺前已经把接口都封装好了，但教务处在冲刺时突然改版，原先接口不能用了，接口就要重写。这个确实感觉属于偶然事件，并没有估计到。

• 在你的计划中是否有留下缓冲区，缓冲区有作用吗？

答：还是留有几天的缓冲区，挺有作用的，虽然之前写的认证接口不能用了，但还是有时间修改接口的。

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

答：像alpha一样在ddl之前留有一定时间

• 你在Alpha中学习到了什么，如果历史重来一遍，你会做出什么改进？

答：写完一个版本最好就直接部署上去进行测试，本地测试可能和部署上去的并不一样。

2. 资源

• 你是否拥有足够的资源完成各项任务？（时间，技术等等）

答：有的，时间技术还是没什么问题的。

• 你是如何估计完成任务所需的时间？精度如何？

答：估计还是有点不准，有点高估自己水平了，没有把可能遇到bug算在呢，都是以理想状态去估计，感觉就会遇到很多奇奇怪怪的bug。

• 测试的时间，人力和软件/硬件资源是否足够?

答：还是足够的。

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

答：应该没有吧，大家都可以完成自己的事情。

• 就以上四个问题，你有什么经验教训，如果历史重来一遍，你会做出什么改进？

答：不能太想当然，还是要在估计时间的时候预留一点时间。

3. 设计、实现

• 设计或实际编码工作有没有碰到模棱两可的情况？（例如，代码风格不同）

答：还是没有的，因为每个人负责的模块之间交叉还是比较少的，而且事先规定过代码风格，还是没什么问题的

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

答：代码规范有严格执行，复审在冲刺开始前还有做，后面感觉要加快进度就并没有自己进行复审了。

---

【陈毅力 - 221801128】

1. 计划

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

答：原计划的工作是做完了，但是代码仍需优化，且消息的长轮询当时是觉得没必要做，这段时间可以考虑一下。

• 有没有发现你做了无用功？具体描述一下

答：有，在调用接口前对变量定义的时候按照之前的接口文档编写。由于后端后来对接口文档的更改，未能及时变动。所以在对接的时候，数据的定义得重新按照返回的数据格式编写。

• 在团队合作过程中，是否每一项任务都定义清楚，对于“完成”有明确的定义？

答：在没有明显的bug下能够使用相应功能。

• 在团队合作过程中，是否遇到了没有估计到的风险，是什么风险呢？为什么没有估计到?

答：

• 在你的计划中是否有留下缓冲区，缓冲区有作用吗？

答：有的，利用这段时间更改了部分功能的展示形式（如徽标的显示位置）、也修改了点击已读，数据库会出现多条信息的bug，及时与后端组人员沟通解决。

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

答：尽量前期将自己部分的任务完成。

• 你在Alpha中学习到了什么，如果历史重来一遍，你会做出什么改进？

答：学会了使用React对组件的调用，重来的话也许会使用函数式组件完成编写（据说更好）

2. 资源

• 你是否拥有足够的资源完成各项任务？（时间，技术等等）

答：有，技术也一边做一边在多学一点。

• 你是如何估计完成任务所需的时间？精度如何？

答：估计是按理想状态（一切顺利的情况）去估计，实际上编写完会出现许多奇奇怪怪的bug，解决花费了较多时间。

• 测试的时间，人力和软件/硬件资源是否足够?

答：足够。

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

答：没有，各司其职，目前来看效率还不错。

• 就以上四个问题，你有什么经验教训，如果历史重来一遍，你会做出什么改进？

答：估计任务时间时要将bug等异常因素考虑清楚，再制定自己的编码计划。

3. 设计、实现

• 设计或实际编码工作有没有碰到模棱两可的情况？（例如，代码风格不同）

答：没有，项目开始前有进行对代码风格的制定。

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

答：严格执行了代码规范，对于代码复审由于技术一般，且花在解决问题上的时间较多就没有进行。

---

【唐凯秦 - 221801120】

1. 计划

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

答：都做完了。

• 有没有发现你做了无用功？具体描述一下

答：有的，在编写service层的方法时，其实有的方法可以直接复用父类的方法，但是因为对新技术mybatis-plus掌握的还不够，所以浪费了一些时间。还有就是接口设计的时候不太合理，在和前端对接的时候才发现，所以在接口设计上也做了一些无用功。

• 在团队合作过程中，是否每一项任务都定义清楚，对于“完成”有明确的定义？

答：挺清楚的。

• 在团队合作过程中，是否遇到了没有估计到的风险，是什么风险呢？为什么没有估计到?

答：有的，在接口对接时遇到了不少的问题，想象中前后端对接应该是很快的，但是实际上却花了很长的时间。

• 在你的计划中是否有留下缓冲区，缓冲区有作用吗？

答：有留下缓冲区，起作用了，利用这段时间修改对接遇到的问题。

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

答：尽量尽早完成任务，给自己预留更多的缓冲区。

• 你在Alpha中学习到了什么，如果历史重来一遍，你会做出什么改进？

答：学习了springboot和mybatis-plus的使用。改进一下代码，有存在一些冗余代码，希望可以提高代码质量。

2. 资源

• 你是否拥有足够的资源完成各项任务？（时间，技术等等）

答：资源还是挺充足的，边做边学，遇到问题可以和组内成员讨论。

• 你是如何估计完成任务所需的时间？精度如何？

答：我是按任务数（接口数）来估计的，感觉这样估计还是不太合理，接口的复杂程度不一，而且在编写过程中会遇到各种各样的问题，估计出来与实际情况多少有些不符。

• 测试的时间，人力和软件/硬件资源是否足够?

答：足够。

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

答：如果让一个对本次技术栈掌握更好的人来做我的工作，应该会更有效率。但是在这次冲刺中，我们团队成员各司其职，互相配合，这才更好地完成了任务。

• 就以上四个问题，你有什么经验教训，如果历史重来一遍，你会做出什么改进？

答：还要提高估算方面的能力，对时间的安排合理一些，避免后期手忙脚乱。

3. 设计、实现

• 设计或实际编码工作有没有碰到模棱两可的情况？（例如，代码风格不同）

答：有遇到代码风格不同的问题。

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

答：代码规范有严格执行，代码复审前期时间比较富余的时候还有考虑，后期就忙着解决bug，有所缺失。

---

【许晓蕾 - 221801119】

1. 计划

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

答：都做完了。

• 有没有发现你做了无用功？具体描述一下

答：后来才发现service层的部分函数其实没有必要写，可以使用封装好的方法。

• 在团队合作过程中，是否每一项任务都定义清楚，对于“完成”有明确的定义？

答：是的。

• 在团队合作过程中，是否遇到了没有估计到的风险，是什么风险呢？为什么没有估计到?

答：没有。

• 在你的计划中是否有留下缓冲区，缓冲区有作用吗？

答：有的。首先，缓冲区的存在让我在前期写代码的时候比较安心，不会担心临近DDL却无法完成自己的任务。其次，缓冲区的存在也给了我比较充裕的时间可以与前端对接接口、修正bug。

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

答：尽量尽早完成任务，给自己预留更多的缓冲区，以免以后手忙脚乱。同时，临近期末，需要协调好复习与冲刺的时间。

• 你在Alpha中学习到了什么，如果历史重来一遍，你会做出什么改进？

答：学习了接口测试。如果历史重来一遍，会进行更全面的测试，比前端对接的同学先一步发现程序的bug。

2. 资源

• 你是否拥有足够的资源完成各项任务？（时间，技术等等）

答：确实拥有足够的资源。

• 你是如何估计完成任务所需的时间？精度如何？

答：一般是在已经完成任务的一小部分后，才能大致估计出所需时间，但是最后实际需要的时间一般比预估的长一些。

• 测试的时间，人力和软件/硬件资源是否足够?

答：足够。

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

答：是的，因为能力有欠，不太能扛起“只有我做而别人不能”的活。

• 就以上四个问题，你有什么经验教训，如果历史重来一遍，你会做出什么改进？

答：进行更全面的测试。

3. 设计、实现

• 设计或实际编码工作有没有碰到模棱两可的情况？（例如，代码风格不同）

答：写接口时，如果把数据包装成接口文档中设计的形式会很不方便。最终和前端同学沟通了一下，调整了数据返回格式。

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

答：代码规范有严格执行，也有进行代码复审。

---

【谢雨欣 - 221801119】

1. 计划

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

答：做完了。

• 有没有发现你做了无用功？具体描述一下

答：service层的部分函数其实没有必要写，可以使用封装好的方法。

• 在团队合作过程中，是否每一项任务都定义清楚，对于“完成”有明确的定义？

答：是的呀。

• 在团队合作过程中，是否遇到了没有估计到的风险，是什么风险呢？为什么没有估计到?

答：暂时没有。

• 在你的计划中是否有留下缓冲区，缓冲区有作用吗？

答：有的，提前预留一些缓冲区，可以让我们更多的时间修改BUG。

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

答：提前开始规划，尽早完成任务，预留更多的时间完善和改进项目。

• 你在Alpha中学习到了什么，如果历史重来一遍，你会做出什么改进？

答：学会了使用postman进行接口测试；如果历史重来一遍，我会更认真进行接口测试，确保在前后端对接的时候不再出现bug。

2. 资源

• 你是否拥有足够的资源完成各项任务？（时间，技术等等）

答：有足够的资源。

• 你是如何估计完成任务所需的时间？精度如何？

答：一般是在已经完成任务的一小部分后，实际精度还是根据项目情况吧。

• 测试的时间，人力和软件/硬件资源是否足够?

答：足够。

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

答：是的，因为能力欠缺。

• 就以上四个问题，你有什么经验教训，如果历史重来一遍，你会做出什么改进？

答：进行更全面的测试！

3. 设计、实现

• 设计或实际编码工作有没有碰到模棱两可的情况？（例如，代码风格不同）

答：写接口时，如果把数据包装成接口文档中设计的形式会很不方便。最终和前端同学沟通了一下，调整了数据返回格式。

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

答：代码规范有严格执行，也有进行代码复审。

---

【黄贸之 - 221801318】

1. 计划

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

答：工作都按照计划完成了。

• 有没有发现你做了无用功？具体描述一下

答：有。邮箱验证码验证这个功能的实现，我最初使用的是session来暂时存储信息，但是后面在测试的时候发现高版本的Chrome浏览器把这块功能给禁用了，导致我不得不绕过session进行邮箱验证码验证。

• 在团队合作过程中，是否每一项任务都定义清楚，对于“完成”有明确的定义？

答：是。按照功能点可以实现预期功能视为完成。

• 在团队合作过程中，是否遇到了没有估计到的风险，是什么风险呢？为什么没有估计到?

答：暂时没有。

• 在你的计划中是否有留下缓冲区，缓冲区有作用吗？

答：有，缓冲区可以让我进行思考，思考现有实现方案能否进行优化。

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

答：增加计划缓冲区的时间，因为总有奇奇怪怪的因素会耽误项目进程。

• 你在Alpha中学习到了什么，如果历史重来一遍，你会做出什么改进？

答：学到了项目计划安排。如果重来一遍的话，我会对自己的任务进行更细化更可实现的安排。

2. 资源

• 你是否拥有足够的资源完成各项任务？（时间，技术等等）

答：有。

• 你是如何估计完成任务所需的时间？精度如何？

答：凭借经验，精度会出现误差，因为会有BUG出现，而修改这些BUG会花费计划之外的时间。

• 测试的时间，人力和软件/硬件资源是否足够?

答：足够。

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

答：有，因为刚开始接口对接的时候有一些接口不是我负责编写的，但是实际上是我在负责对接。这样有一个不好的地方就是底层代码不是我写的，只是这个底层代码在实现时有调用我写的方法类，导致常常是底层代码出问题而不是我的方法类出问题，我要修改底层代码需要先读懂，这增加了不必要的时间开销。

• 就以上四个问题，你有什么经验教训，如果历史重来一遍，你会做出什么改进？

答：严格实施接口编码是谁负责的，这个接口与前端对接也是该同学负责。

3. 设计、实现

• 设计或实际编码工作有没有碰到模棱两可的情况？（例如，代码风格不同）

答：没有。

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

答：复审过，通过Alibaba的一个代码规范插件进行代码复审。理论上我自己负责的部分大部分代码执行了代码规范。