事后诸葛亮

Posted 2021-01-24 hizxk

1.团队成员

• 郑西坤 031602542 （队长）
• 陈俊杰 031602504
• 陈顺兴 031602505
• 张胜男 031602540
• 廖钰萍 031602323
• 雷光游 031602319
• 苏芳锃 031602330

设想和目标

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

- 我们的软件是要为用户提供一个可以在线组队的地方，让他们学习生活都可以有个伴。
- 定义清楚。主要是实现通过发布拼帖与加入组队两个功能实现在线组队。其余的还有聊天功能等。
- 对典型用户和典型场景有清晰的描述，切合问卷调查与用户场景分析来进行开发。

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

• 有。每个阶段都有每个阶段的任务，问卷调查、需求分析、原型设计及修改等，从十月份开始，到目前已有两个月的i时间。

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

• 一般会在开会时收集不同的意见，进行讨论后投票决定。

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

• 设想的时候感觉还是很不错的，但是在实现的时候没有考虑到成员的自觉性，也没有考虑到卡法的实际难度比想象的高。
• 在定制目标的时候，对各种东西的衡量还是要保守一点。

---

计划

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

• 服务器与数据库部分大都已经完成。还有一些功能的实现未完成。
• 计划还是比较完善的，但是由于执行不周、不够自觉导致未能达到预期效果。

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

• 计划的时候安排了一些附加功能的实现，但是后来发现与主要功能实现的时候有与其差不多的功能，那样再实现附加功能就多余了。

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

• 大部分都有，因为在发布任务时给了较清晰的要求文档。

4. 是否项目的整个过程都按照计划进行?

• 一开始有按计划进行，但是后期随着开发难度加大以及成员自觉性降低，就逐渐跟不上计划。

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

• 有。可以说起了一定的作用吧。但是后期难度高的同时成员自觉性也降低了，所以缓冲区并没有达到预期效果。

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

• 对任务进行更为明确的时间安排，制定每个时间点需要完成什么目标。
• 多集合队员一起出来开发，减少成员自觉性不够带来的影响。

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

• 实际开发没有跟上理想开发进度，主要是执行方面的问题。
• 还是需要多督促、多集合开发，对队员的要求更严格一点，不能太宽松。

---

资源

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

• 时间上来说应该还是足够的。
• 人员上来说7个人也差不多。但是每个人都没有开发经验，所以在时间的分配上还不够合理，开发进度的把控也不准确。
• 开发过程中，可以咨询教师、助教等，但我们并没有咨询。网络资源可以说是相当丰富的，但是有好多都不是完全正确的，参考起来有点麻烦。

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

• 在任务的时间估计方面，主要是根据分配人物的难易程度，但都会预留出一些时间来应对各种可能出现的情况。前期的开发还很生疏，所以基本上是两天开一次会，前期精度是两天，后期Alpha阶段冲刺每天都要汇报进度，所以后期精度是一天。

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

• 用户测试的时间按照目前的进度来说可能会不够。软硬件资源是足够的。

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

• 任务的分配是按照队员会做什么且想做什么来分配的。能力不足的同学分配的任务比较简单，学习能力比较强的同学会分配难度高一点的（也有考虑一些同学的开发愿望）。所以虽然会有这样的情况出现。（对能力不够的同学来说，任务让比较强的人来做效率会比较高，但是比较强的队员需要去完成其他难度高的任务）

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

• 要更为客观实际的分配好资源。

---

变更管理

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

• 有创建项目开发的群组，所以有什么变更消息都可以即使通知到，开会的时候也会具体说。

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

• 在Alpha冲刺开始前有进行开会讨论来决定冲刺时间里的主要任务。

3. 项目的出口条件（Exit Criteria）是否得到清晰的定义?

• 没有清晰定义。目前只实现了核心功能。

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

• 如果项目功能等需要变更都会在开会的时候进行讨论。
• 在人员安排方面的变更一般是延迟任务截止的时间、减小工作量或者进行各模块人员调整。

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

• 部分员工可以。在提出其他工作请求的之后，一般都会先进行该工作请求。但是部分员工可能无法实现。

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

• 团队没有应急方案，只能在一次次开会时讨论。
• 应急方案要提前制定。

---

设计/实现

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

• 设计工作团队讨论的时候就开始了，在进行需求分析的时候完成的，是由团队所有成员一起讨论、由需求分析的同学和做界面原型设计的同学来实现。
• 时间应该是合适的。完成的设计也是所有成员认可的，所以人也是合适的。

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

• 有。在早期需求分析的时候，对一些功能是否需要存在有不同的意见。
• 采用少数服从多数解决。

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

• 没有

4. 什么功能产生的Bug最多，为什么？

• 服务器方面。因为比较难，所以在实现的时候经常会产生错误。

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

• 代码会由队长进行审核，发现个别队员没有规范，主要没有使用要求文档里规定的命名。

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

• 发布了要求文档之后，交上来的代码还是有些不规范。
• 对队员进行强调，不规范的代码退回整改。

---

测试/发布

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

• 只有一个大概的测试计划。在测试阶段会开会讨论具体计划（根据时间情况决定）。

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

• 没有

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

• 没有。

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

• 都是使用手动代码测试。将遇到的BUG进行改进。
• 作用很小，耗时耗力。改进：首先要对bug进行记录分类，其次要改进代码测试的方法。

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

• 虽然还未发布，但是在目前的app运行情况与理想还是有点不一样，因为一些操作都需要代码实现，但是惯性使然让我们觉得这个操作本来就有。

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

• 没有测试计划
• 制定测试计划，应该会使测试更方便

---

总结

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

• CMM

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

• 磨合

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

• 对队员进行督促，避免再次出现自觉性降低的情况。