事后诸葛亮总结会议
事后诸葛亮分析
一、设想与目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决的问题就是针对目前医学文献检索的痛点进行优化，打造一个医学文献检索平台，通过这个平台大大提高医务人员的工作效率；我们对项目的定义还是很清楚的；详细的定义和描述
2、我们达到目标了么?
达到第一阶段目标，完成第一阶段计划的所有功能，已按原计划交付之间交付
3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?我们离目标更近了么?有什么经验教训? 如果历史重来一遍,我们会做什么改进?
用户量还没有，因为我们的项目还没有上线，所以没有用户量，现在只是内测版本，因此没有用户地数据；
教训：前后端交流不够充分，导致对接接口和商量具体需求时消耗较多时间；队员未能定期交付任务，导致进度延后；因为本学期作业比较多，所以在测试阶段，进度比较慢，发现bug不能及时修改。
改进：每周必须制定作业任务安排表，及时按时完成任务，才不会拖进度，如果因为一些不必要的原因没能按时提交任务，得重新分配任务；必须开会议，前后端和测试人员充分交流，和pm充分讨论，及时解决问题。
二、计划
1、是否有充足的时间来做计划?
有，我们在准备阶段通过会议方式充分讨论了，因此有充分的时间做计划
2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
在准备阶段我们通过组内会议来讨论，如果出现分歧，我们会对不同意见进行分析并权衡其中的利弊，
做到组内观点的统一
3、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
目前计划都做完了，不过还存在一个bug，还需要改进，因为后期课程任务占用大量的时间，也到了考试月。
4、有没有发现你做了一些事后看来没必要或没多大价值的事?
有，那就是在线下进行讨论，因为线上讨论的效率不高，在前期阶段，我们有问题再线上讨论，但是效果不好，所以我们进行了线下讨论。
5、是否每一项任务都有清楚定义和衡量的交付件?
没有
6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
我们项目基本按照计划进行，未出现大意外。时间不足够，因为到了后期很多课设，所以会占用很多时间，大家有的备考，有的参加竞赛，能找出时间来具体讨论问题的时间比较少，但是最后还是能够完成Alpha阶段。
7、在计划中有没有留下缓冲区，缓冲区有作用么?
有，在第一阶段的计划中设置了三天的缓冲区，有一定的作用。
8、我们学到了什么? 如果历史重来一遍,我们会做什么改进?
教训：前后端交流不够充分，导致对接接口和商量具体需求时消耗较多时间；队员未能定期交付任务，导致进度延后；因为本学期作业比较多，所以在测试阶段，进度比较慢，发现bug不能及时修改。
改进：每周必须制定作业任务安排表，及时按时完成任务，才不会拖进度，如果因为一些不必要的原因没能按时提交任务，得重新分配任务；必须开会议，前后端和测试人员充分交流，和pm充分讨论，及时解决问题。
三、资源
1、我们有足够的资源来完成各项任务么?
有，但是没有服务器，所以项目还没有上线。
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
任务所需时间主要是根据任务量估计的，精确到天数
3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试时间和人力和软件/硬件资源足够，美工设计没有低估难度，我们项目没有什么文案。
4、你有没有感到你做的事情可以让别人来做（更有效率）?
我做的事就是后台的部分功能开发和分配任务，撰写博客，有作用，以每个人不同的能力分配合适的工作，提高工作效率。
5、有什么经验教训? 如果历史重来一遍,我们会做什么改进?
教训：前后端交流不够充分，导致对接接口和商量具体需求时消耗较多时间；队员未能定期交付任务，导致进度延后；因为本学期作业比较多，所以在测试阶段，进度比较慢，发现bug不能及时修改。
改进：每周必须制定作业任务安排表，及时按时完成任务，才不会拖进度，如果因为一些不必要的原因没能按时提交任务，得重新分配任务；必须开会议，前后端和测试人员充分交流，和pm充分讨论，及时解决问题，在项目准备阶段，做好准备，比如服务器的配置，让项目能够上线。
四、变更管理
1、每个相关的员工都及时知道了变更的消息?
是，有变更信息我会第一时间通知相关员工
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们从系统的核心功能出发来看这个问题，如果它是核心功能，则它属于必须实现的功能，如果是外围扩展的功能，则在时间紧迫的情况下我们做了推迟处理。
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
实现基本功能，用户体验良好，没有较大的安全漏洞
4、对于可能的变更是否能制定应急计划?
能，出现变更情况，我们立刻制定应急计划快速通知到相关人员，进行计划变更
5、员工是否能够有效地处理意料之外的工作请求？
基本可以做到，我们会通过队内交流学习
五、设计/实现
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是在需求确定之后，石团队中有做过项目的前端后台人制定的，是合适的时间和合适的人
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，负责设计的同学在遇到这种情况，会向大家提出来，然后团队讨论之后做出决定
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
我们没使用单元测试
4、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
在用户交互的过程中产生的Bug最多，要考虑到不同用户的需求，每个用户有着不同的操作，控制复杂，项目经验不足，考虑得不够全面
5、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
在提交代码时安排复审人进行代码复审，保证了基本的代码规范。
6、如果历史重来一遍,我们会做什么改进?
改进：每周必须制定作业任务安排表，及时按时完成任务，才不会拖进度，如果因为一些不必要的原因没能按时提交任务，得重新分配任务；必须开会议，前后端和测试人员充分交流，和pm充分讨论，及时解决问题，在项目准备阶段，做好准备，比如服务器的配置，让项目能够上线。
六、测试/发布
1、团队是否有一个测试计划？为什么没有？
有，没有在测试之前，有测试人员进行项目测试计划的安排、
2、是否进行了正式的验收测试？
暂时还没有
3、团队是否有测试工具来帮助测试？
有，我们团队用了JMeter、IDEA、Burpsuite、AWS以及项目管理工具等来帮助测试。
4、团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
测量效能主要有软件是否正常运行，运行速度是否高效率，运行效果是否令人满意等。使用腾讯的WeTest来进行压力测试。从结果上看，由于网站使用的服务器配置太低，导致无法大量的用户同时使用，这些测试工作让我们对我们服务器搭建的网站容纳量有了一个大概的认识。
项目改进主要分为两点：
- 加钱买更高的服务器，提高性能。
- 优化网站后台处理逻辑，减少内存花销
5、在发布的过程中发现了哪些意外问题？
目前尚未上线，只有内测版本。
七、总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
达到CMMI中的三级，定义级别。
2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合阶段
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?
相比前一个里程碑，团队这这个里程碑中分工更加明确，大家的集体意识和责任感都变强，代码的管理和编程能力有了提高。
4、你觉得目前最需要改进的一个方面是什么?
编程能力。
八、会议照片:
