设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要服务于在校大学生，要解决的问题就是怎么样设计社团的需求关系，在校大学生和学校社团之间应该如何持续的使用我们的软件.
定义和对典型用户、典型场景有清晰描述，详见[需求规格说明](https://www.cnblogs.com/sbxb/p/13126705.html)；
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
我们达到了目标，按照原计划的时间交付了，原计划的没有考虑到使用者，因为没有做成一个美观的软件，用户还不会考虑我们的软件。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
质量提高了，团队协助和代码正确率有提高，团队从一开始的一盘散沙到现在的具有凝聚力，代码从开始的经常报错到现在的几乎没有报错。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
我们确实离目标越来越近了，功能也是非常齐全了，与我们预想的一样。
5.有什么经验教训? 如果历史重来一遍,我们会做什么改进?
团队应该开始就有凝聚力，这样每个人都会比较轻松一点，完成目标的效率也会更高；
计划
1. 是否有充足的时间来做计划?
由于经验不足，感觉时间总是不够。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
少数服从多数，提出的意见大家都会参考，然后考虑是否利大于弊，如果是就采纳，反之则不采纳。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
计划的工作都做完了，付出了很多心血；
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
下载了一些开始觉得有用后面根本没用的软件，费时费力。比如Microsoft word 10;
5. 是否每一项任务都有清楚定义和衡量的交付件?
每一个功能实现后都要经过测试才进行下一项功能的实现；
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
意外的话就是有次电脑过热重启导致两三个小时的努力白费了；风险的话还是高估了自己的能力，导致很晚都要抽时间继续赶进度；
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
缓冲区好像没有留下；
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
缓冲区可以应当突发事件，下一个项目我们应该会加一个缓冲区；我觉得加班的话还是少加，下次团队一起做项目肯定是要高效率一点，因为第二天的任务也会很多，每天都加班不可能有人能抗过来，所以不要养成加班的坏习惯；
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学习了用HTML和CSS等语言编写前端，用java和Python等语言来编写后端；学习了使用测试工具，java语言代码编写；
如果时光倒流，我们会将各个功能的界面做得更详细和更美观；
资源
1. 我们有足够的资源来完成各项任务么?
我们有的资源很少，大部分都是在网上学习到的。但是还是完成了各项任务；
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务的时间是靠推测来估计的，按照每个人的能力来估计所需时间；精度还可以，组员还是很诚实的；
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间足够，因为专门由一个人来负责，硬件资源有点不足，因为小组都没有测试工具，确实低估了美工的难度，导致界面美化这方面做得不足；
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
因为大家都对自己完成的方面感到满意，所以没有这样感觉；
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
测试工具资源大家都没有，导致测试前部分一直呆滞，这是一个教训；重来一次的话，我们小组应该都会提前下好测试工具；
变更管理
1. 每个相关的员工都及时知道了变更的消息?
我们创建了自己项目的群，变更的消息会第一时间发至群里供成员查阅；
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
通过成员投票方式，要是多数觉得应该推迟那就推迟，否则就选择“必须实现“；
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
在需求规格说明书里清晰的定义了什么叫”做好了“链接地址”https://www.cnblogs.com/sbxb/p/13126705.html“中的”验收验证标准“里；
4. 对于可能的变更是否能制定应急计划?
是；实际上我们也做到了，那就是熬夜加班的完成本天的任务，几乎每个人都加过班；
5. 员工是否能够有效地处理意料之外的工作请求？
这个有点困难，因为每天的任务本身就很多，再加其他的工作请求会有点不适应；
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了怎么适应有意外的情况发生，学会了怎么合理的安排自己的时间；如果时光倒流，我们会更早的适应吧；
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
| 工作 | 完成人 | 时间 | 是否是合适的时间 | 是否是合适的人 |
| 代码编写 | 何雪文 | 6.26~7.2 | 是 | 是 |
| 代码测试 | 彭振 | 6.26~7.2 | 是 | 是 |
| 代码优化 | 谭明水 | 6.26~7.2 | 是 | 是 |
| 美工处理 | 丁珺 | 6.26~7.2 | 是 | 是 |
| 博客园编写 | 朱泽琨 | 6.26~7.2 | 是 | 是 |
| github代码迁入 | 史钊宁 | 6.26~7.2 | 是 | 是 |
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
当有模棱两可的情况，团队会选择最优的来解决问题；
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
使用了（1）测试框架：delphidunit（2）javajunit来进行单元测试；这些工具效果还行；uml文档的视图部分改变了；这些改变是由于后期软件功能实现的过程中改良的；更新是要更新的，因为总会有更好的视图，特别是用例视图是强调从用户的角度看到的或需要的系统功能，所以用户有什么建议，我们都会考虑和采纳，并更改相关部分；
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
拿我们的功能来说的话就是修改社团是否通过管理员的验证部分出现的bug最多，因为有三个选项，可能相关性太强；有时候更改不了状态；因为开发的时候不觉得这个地方会有bug出现；
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
通过复查常规项、安全、文档、测试来进行，执行了代码是否可以测试、代码能够工作么、所有的代码是否简单易懂、是否存在多余的或是重复的代码、是否有注释，并且描述了代码的意图等这些方面来检查代码是否规范；
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学习了怎么样审查代码，例如常规项、安全、文档、测试方面；如果历史重来一遍，我们会重点审查管理员是否能修改社团是否通过验证部分，尽量少出bug；
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有测试计划，是用OpenSTA、DBMonster实现的；
2. 是否进行了正式的验收测试？
是，每个环节都通过了很多次测试和正式验收测试；
3. 团队是否有测试工具来帮助测试？
是，用的是OpenSTA、DBMonster；
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
后续会通过使用者的反馈和进一步的测试来测量软件效能；压力测试则通过编写压力测试计划、编写压力测试案例、多进程模拟多用户、设置并发点、运行测试程序并监测系统资源、分析结果、优化调整设置、提交测试报告等步骤来测量和跟踪；从软件实际运行结果来看，测试工作有用，可以使在计算机数量较少或系统资源匮乏的条件下可以运行测试；改进的方面就是使在计算机数量较少或系统资源匮乏的条件下可以运行测试还没有能完全的保证；
5. 在发布的过程中发现了哪些意外问题？
好多网站不知道怎么注册、上传。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
学会了怎么进行压力测试，如果重来一遍，我们会在怎么发布的方面做更多的努力；
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
每个角色都是组长通过组员擅长的部分来分工的，做到了人尽其才；
2. 团队成员之间有互相帮助么？
有的，成员之间有任何一个人有不懂的地方，其他人员都会慷慨的帮助与讲解；
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
当需要成员之间合作才能完成任务时，大家都会尽力的相互磨合，并全力的去解决问题；
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢 _______<姓名>______对我的帮助， 因为某个具体的事情: _____________________。
这个在我们各自的个人博客里；
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
已管理级。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合阶段。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
团队协作更好一些了，做出的成果也不负这段时间的付出；
你觉得目前最需要改进的一个方面是什么?
那一定是界面设计了！功能都还算完善，但界面比较简陋；
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
7-可用的软件是衡量进度的主要指标。
12-团队要定期反省如何能够做到更有效，并相应调整团队的行为。
4-项目过程中，业务人员与开发人员必须在一起。
6-无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7：我们把该有的功能都实现了；
12：我们两天对自己做一个总结，反思自己哪里可以做得更好，小组人员都可以借鉴失败经验；
4：我们小组人员都在学校，而且都在同一栋的5楼和6楼；
6：我们讨论问题都是面对面的交谈；
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
使用代码测试工具来提高；
2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
通过重构，重构可以改进设计，更快的修复bug，提高效率；使用state模式来重构，创建abstract类Price，abstract方法getChrage，衡量就是执行单元测试，绿条通过；
3. 其它软件工具的应用，应该如何提高？
经常到网上找资源，把不懂的地方弄懂；
4. 项目管理有哪些具体的提高？
组员更加的服从，工作效率也有所提高了；
5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
这个的话还没实现，应该说没考虑到，后期应该会考虑到并实现；
6. 项目文档的质量如何提高？
提高可理解性，使人们一看就知道是用来做什么的；
7. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
领导和管理，我们组缺少了点威信；
8. 对于软件工程的理论，规律有什么心得体会或不同意见？
理论知识很重要也很难懂，所以必须通过实践才能完全明白；
事后诸葛亮全组讨论照片。
因为放假大家都回去了，讨论和问题都是群电话联系解决的，所以没有合照；
