事后诸葛亮会议总结

事后诸葛亮会议总结
1.设想和目标
我们的软件为设备管理子系统，主要是对设备的从采购到报废的整个业务流程进行实时监控的一个管理系统，当时我们花费了大量的时间进行讨论此套系统在实际应用中的场景，他到底在实际生活中是如何使用的？究竟我们在设计的时候该如何实现呢？我们做了大量的假设和讨论，最终制定了初级的项目目标。当然，在计划阶段我们每个人都有自己的项目设计思路，我们首先都是尽其所言，之后我们进行讨论在实际中是否可行之后进行取舍。
经验教训当然也是有的：比如我们在第一阶段验收的时候出现了测试的问题，是因为前后端数据不匹配以及业务逻辑与预先设计的不符，导致测试有问题，在第二阶段的时候，我们就充分规定了前后端数据的类型，进行匹配。
2.计划
原计划的工作并没有全部做完，我们将一些简单的重复的逻辑进行了优化舍去，减少了我们的工作量，因为那些重复些没有意义，只会单独的增加工作量。
当然，每一项任务都有清楚地定义，我们团队是在整个任务进行规划完毕之后进行代码的编写和逻辑的处理实现的。
项目的整个过程并没有顺利地按照计划来进行，比如我们对这个工作量的初步判断进行了失误，低估了他的工作量和逻辑关系，导致我们留下了缓冲区。
如果重来一遍，我们对任务的规定计划会更加准确具体，将主动权更多的掌握在自己的手中。
3.资源
AI当然是可以使用的，但是前提是需要对项目的整个业务逻辑有了清晰的认识，这当然是可以来提升效率的。
我们如果按照正常的时间是不够的，我们当然舍弃的空余时间和休息时间来进行完成任务，我们在所有的任务进行结束之后进行统一的测试，我认为可以进行一项测试一项，这样可以大大节省我们团队的时间。
4.变更管理
对于“变更”，我们当然也遇到了一些问题，比如我们开发过程中是进行前后端分离的，这就会导致一个问题，虽然在之前前后端已经完成了数据的规定统一，但是这也会在前端设计好了或者后端设计好了，造成最后并没有达成“好了”这一效果，出现了数据不匹配的问题。
对于可能的变更我们并没有做出应急的计划，只是进行了花费时间修改直至匹配。
当然我们是能够有效的处理意料之外的请求的，这是没有问题的。
如果重来一次，我们一定会规定好整个前后端。
5.设计和实现
我们项目的整个设计使我们整个团队在进行讨论分析设计的，是合适的时间进行的。
遇到模棱两可的数据我们首先是进行初步分析是否可以确定下来，如果不可以我们会进行先丢弃，之后再次进行讨论。
我们利用了swagger文档接口进行了测试和Postman进行测试。
我们项目在实现整个项目逻辑的时候是最复杂的，因为里面的逻辑你需要根据实际来进行操作的，还有前后端进行合并的时候bug是最多的。
代码复审，我们进行整个业务流程的进行测试，以及项目的结构整理，分层解耦设计。
6.测试和发布
我们团队在最后收尾时进行了测试计划，实现整个的业务流程，但是还未进行正式的验收测试，我们利用模拟器进行测试。

总结：
我们团队是属于CMMI式的，整体以集成化模型支持多领域过程优化，帮助组织实现系统化、可持续的能力提升，比较灵活，能够根据实际需求进行及时止损，进行变更。
我们呢团队我们感觉属于一个磨合和规范之间，我们较好于磨合，但又达不到规范，我们仍需进行磨炼和规范。
我觉得我们团队对于项目的整体有了一个清晰的认识，之间的合作更加有默契，配合更加好了，但是还需要对于技术和基础进行加强，这样我们的效率会更加高的。