项目回顾
1.设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：“社团管理系统”是一个基于智慧北软APP的功能，我们的软件要解决的问题是为用户提供便于管理社团的工具。定位清晰，针对的是日常签到和场地申请。
是否有充足的时间来做计划?
答：我们组有充足的时间来做计划，在选题前后，我们根据组员的擅长点做出计划。以此提高工作效率，降低开发难度。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：我们有每日例会，当遇到不同的意见时，我们现场发表不同意见的理由，随后全体对不同的意见进行投票（投票的形势遵循少数服从多数的原则）。根据投票决定计划执行方式。
用户量、用户对重要功能的接受程度和我们事先的设想一致吗？我们离目标更近了吗？有什么经验教训？
答：当前用户量为0位，未达到我们事先设想的数量。我们当前的进度符合计划进程，实现了基本功能，所以我们现在离目标更近了。经验教训就是在开发过程中尽量有Plan B,以避免项目搁浅。
如果历史重来一遍，我们会做什么改进？
答：如果历史重来一遍，我们会在任务分配上做出改进，细化时间和人员分配。
2.计划
你原计划的工作是否最后都做完了?
答：我们的第二阶段工作已经全部完成。
有没有发现你做了一些事后看来没必要或没多大价值的事?
答：暂时没有发现没有必要的事，功能阶段做的所有事都很有必要，就算是走的弯路也是我们项目开发的经验积累，避免下次在同样的地方走弯路。
是否每一项任务都有清楚定义和衡量的交付件?
答：是的，我们每一项任务都会在例会上做出明确的说明，并在完成时检查是否符合要求。对可以公开的任务供大家参考和检查。
是否项目的整个过程都按照计划进行?
答：是的，我们的整个阶段都是按照计划有序的进行。
在计划中有没有留下缓冲区，缓冲区有作用么?
答：我们在计划中对无法预测的任务留下了缓冲区，当计划不能按计划完成时，我们会在缓冲区中努力完成任务。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：将来的计划我们会根据课程的变化和组员的变化动态的进行修改。如被更换组员的任务交接。
如果历史重来一遍，我们会做什么改进？
答：在任务遇到不可解决的困难时，我们应及时的在小组中做出说明，大家一起想办法解决。
3.资源
我们有足够的资源来完成各项任务么?
答：我们有专业的老师以及完善的资料来完成任务
各项任务所需的时间和其他资源是如何估计的，精度如何?
答：我们先在例会上预估任务所需的时间，然后留下缓冲时间。并且在任务分配时结合组员的实际情况分配，由于是预估所以精度并不是很准确。
用户测试的时间，人力和软件/硬件资源是否足够?
答：我们的各项资源都足够。
你有没有感到你做的事情可以让别人来做（更有效率）?
答：有，但是我也按时完成了任务。在任务分配时，我们已经询问了组员的实际情况和意见，当前分配已经是最优解，任务可以准时完成即可。
如果历史重来一遍，我们会做什么改进？
答：我们会为重要的任务留下更多的缓冲时间和人员分配，以保证任务的出色完成。
4.变更管理
每个相关的员工都及时知道了变更的消息?
答：及时的知道了，因为我们每天都有站立会并且有变更消息都会在群里通知大家。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：我们根据项目的定位和核心功能决定“推迟”和“必须实现”的功能，核心功能都是“必须实现”得功能。
项目的出口条件（ExitCriteria）有清晰的定义吗?
答：可以让用户做测试题并给出准确的测试结果项目的出口条件。
对于可能的变更是否能制定应急计划?
答：可以，我们组员可以通过视频会议对可能的b变更制定应急计划。
员工是否能够有效地处理意料之外的工作请求？
答：不可以，因为员工的工作经验有限。但是组员可以在站立会上对其他组员的请求进行力所能及的帮助。
如果历史重来一遍，我们会做什么改进？
答：我们将提高每个人的参与感，让每个组员都体会到项目的成长和自己的成长。
5.设计和实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：设计工作是在选题结束后立即进行的。由组长牵头，大家一起参与完成的。尽量服从有设计经验的组员的建议。是合适的时间，合适的人。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：有，对模棱两可的情况，让组员讨论并作出抉择（投票的形势遵循少数服从多数的原则）。
团队是否运用单元测试（unittest），测试驱动的开发（TDD）、UML,或者其他工具来帮助设计和实现？这些工具有效么？
答：没有
什么功能产生的Bug最多，为什么？
答：签到的Bug最多，因为这个功能涉及了很多不会的知识的，也是逻辑比较复杂的。
代码复审（CodeReview）是如何进行的，是否严格执行了代码规范？
答：在完成任务后，负责人先自己复查代码，然后我们将代码上传到代码托管平台后，所有组员复审代码。因为时间紧，没有严格执行代码规范。
如果历史重来一遍，我们会做什么改进？
答：如果历史重来一遍，我们将严格执行代码规范。
6.测试和发布
团队是否有一个测试计划？为什么没有？
答：有测试计划，由软件测评师进行独自规划
是否进行了正式的验收测试？
答：没有，时间有限。我们没有进行正式的验收测试。
团队是否有测试工具来帮助测试？
答：我们有模拟器来帮助测试。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：我们团队还没有涉及到效能测试。
在发布的过程中发现了哪些意外问题？
暂时没有。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
测试计划是比较重要的一部分，它可以减少发布后出现BUG的数量。应该提前制定测试计划。
总结
1.根据每个成员的兴趣和擅长的技能来确定，由于部分角色未接触过，需要进一步学习才行，所有没有人尽其才。
2.团队成员之间互相帮助
3.采取团队讨论、少数服从多数的解决方法
我感谢孙明山对我的帮助，我的UI都是由他提供的
我对软件工程有了深入的了解，明白了光靠个人能力是无法做出一个好软件的
我觉得目前团队处于量化管理级，我们处于规范的阶段
我们团队经历过这些里程碑后，明白了团队合作的重要性
我觉得目前团队最需要改进的就是提高工作经验，增加个人的实力
