项目名：食物链教学工具
组名：奋斗吧兄弟
组长：黄兴
组员：李俞寰、杜桥、栾骄阳、王东涵
Final Review会议
时间：2016.12.2 13:00——15:00
地点：冬华楼一楼大厅
会议内容：
食物链教学工具Final Review结果
设想和目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
本软件主要是用来辅助教师课堂讲授食物链相关知识。定义的很清楚。典型用户是教师，典型场景是课堂。
2、是否有充足的时间来做计划?
有充足的时间来做计划，但计划在项目进行过程中不断地完善。
3、团队在计划阶段是如何解决同事们对于计划的不同意见的？
采取少数服从多数的原则。
计划
1、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
已全部完成。
2、有没有发现你做了一些事后看来没必要或没多大价值的事?
有，比如说：改变选中状态的表现形式，改后发现效果不如从前，主要是因为技术原因。
3、是否每一项任务都有清楚定义和衡量的交付件?
大部分没有，任务安排好后，看实现的效果是否满意，不满意则会进行修改。
4、是否项目的整个过程都按照计划进行?
是的，按照原定计划，功能依次实现。
5、在计划中有没有留下缓冲区，缓冲区有作用么?
有缓冲区，缓冲区的存在给大家一个调节的机会，更有利于大家的互相配合。
6、将来的计划会做什么修改？（例如：缓冲区的定义，加班）
本项目已经结束了。
资源
1、我们有足够的资源来完成各项任务么?
资源足够，但因为技术原因部分改进的地方选择放弃。
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
先是粗略估计，然后随着项目的进行会调整这个估计值，精确度会有所提高 。
3、用户测试的时间，人力和软件/硬件资源是否足够?
足够。
4、你有没有感到你做的事情可以让别人来做（更有效率）?
没有，每天都会根据每个人的能力情况分配相应的任务。
变更管理
1、每个相关的员工都及时知道了变更的消息?
是的，每次消息都会及时传达，并且确保每个人都收到消息。
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
进行投票，民主表决。
3、项目的出口条件（Exit Criteria）是否得到清晰的定义?
没有。
4、对于可能的变更是否能制定应急计划?
能。
5、员工是否能够有效地处理意料之外的工作请求？
能。
设计/实现
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作由多人合作完成，并且在项目的进行过程中，不断做出改进。是合适的时间，合适的人。
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有。进行投票，采取少数服从多数的原则。
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
没有。
4、什么功能产生的Bug最多，为什么？
添加自定义生物功能的Bug最多。因为我们开始的时候对这个功能的考虑过于复杂。
5、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由同伴对已实现的功能进行审查，查看代码是否错误或者是否能进行改进，但没有严格执行代码规范。
测试/发布
1、团队是否有一个测试计划？为什么没有？
有，仅仅是测试功能是否实现。
2、是否进行了正式的验收测试？
没有。
3、团队是否有测试工具来帮助测试？
没有。
4、团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
没有进行效能测试。
5、在发布的过程中发现了哪些意外问题？
鼠标不太好用、主讲人和操作员的配合不够默契。