设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
（1）我们的软件要做到的是使高血压患者通过我们的APP可以记录自己的血压值变化，与医生进行绑定、交互，并且这个APP具有提醒患者定期服药、定期访问医生的作用；我们的后台管理系统具有可以对数据库中的所有数据增删改查的功能。
（2）定义的很清楚。
（3）典型用户：高血压患者、专业医生、后台管理人员；
典型场景：高血压患者在我们的APP上注册账号后，上传自己测量的血压值，我们的数据库会将其保存起来，患者同时可以选择医生与自己绑定，并与其进行聊天、交流，医生会给出包括服药、作息等方面的建议；医生同样可以在APP上注册，上传相关证件（并通过审查）后可以接收来自患者的消息，与患者进行交互；而后台管理人员可以在后台管理系统网站上查看到所有的数据，并具有对其增删改查的权限。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
我们还没有达到目标；
已实现：原计划的功能中患者端的一些基本功能，像登录注册、上传数据、记录自己一定时间段内血压的变化并以折线图的形式呈现出来；后台管理系统的增删改查的基本功能已经实现；
功能还有很大的欠缺，还不能交付给用户使用。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
和刚开始的团队状态相比，团队软件工程的质量提高了很多：
组内交流更多：刚开始由于队友之间不熟悉，队友之间没有过多的交流，每周只有一次会议；现在每周至少会有两次会议，队友之间沟通、交流遇到的技术以及对接的问题。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
由于实现功能较少，我们的APP还不能交付给用户使用，但在第一次迭代时，助教有跟我们说很多细节我们做的不够完善、细致，用户体验并不是很好，这也是我们第一次迭代扣分的地方；
但是，知道了不足的地方，我们也能针对性地改进我们的项目，不断向目标迈进。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
教训：我觉得迭代还是应该抓紧时间开始，因为我们的数据库是比较简单的，我们在第一次迭代正式开始前其实是有一些时间的，但是我们没有充分利用好这部分时间，导致迭代开始的时候有些手足无措；
如果再来一遍，我们会尽快加强队友之间的交流，尽快熟悉彼此，尽早开始着手代码部分（学习交流部分）。
计划
1. 是否有充足的时间来做计划?
时间相对充足。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
仔细探讨每个人意见的好的地方，再结合我们的实际情况，和项目每一部分的重要性，有针对地探讨，共同决定。（我们组还是挺和谐的。。）
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
有一部分没有做完--美化界面的部分；我们对于迭代计划认识不够清晰，本来把后台管理系统放在了第二次迭代中，但是，其实这是不合理的，所以在第一次迭代验收之际，把之前写的代码进行了改进，但是没来得及美化。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有。。。感觉自己还是需要不断学习。
5. 是否每一项任务都有清楚定义和衡量的交付件?
没有，从代码规范这方面来说，大家的代码风格都不尽相同，并没有一个严格的要求。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
基本上是按照计划进行的，意外是编写代码以及对接的过程中遇到了很多奇奇怪怪的bug，并且耽误了我们相当长的时间，而且还在验收时出现了我们没有预料到的bug；
没有估计到（本地）服务器有时候会崩盘。。当时一直在赶进度，没有考虑到这方面的问题。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
有，后台管理平台部分，即使APP的部分出了问题，后台管理平台只要连接了服务器，依然能够按计划进行。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
把每周的任务加多一些，使得我们的项目尽早完成，留出时间用于测试，避免熬夜与赶工。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我学到了很多前端的知识，以及通过对JAVAEE课堂知识实践得到了更深的体会。
如果再来一遍，我们会加强队友之间的合作，尽早对接，修复bug。
资源
1. 我们有足够的资源来完成各项任务么?
有，比如我负责的后台管理系统，与我们的JAVAEE课上讲解的知识相关，把课堂上的知识用于实践，一举两得。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
时间主要是根据任务量的多少进行分配；精度适当。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
不够，由于进度比较赶，导致我们完成的部分其实都是由我们自己来测试的，导致最后的成果不尽如意；
确实低估了美工的难度，作为一个钢铁直女，审美堪忧，自己做出的成果自己都有点看不下去。。orz
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
感到了。。。毕竟组里还是有大佬的，自己还是可以被替代的。。。T-T
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
一定要多和大佬交流技术问题，能学到很多自己单靠查资料查不出来的东西。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
是的
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
商讨并结合需求确定必须实现的功能以及可以推迟的功能。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
满足客户的需求，按照需求文档实现功能（有条件的话，进行适当改进）。
4. 对于可能的变更是否能制定应急计划?
没有计划，但是可以及时调整。
5. 员工是否能够有效地处理意料之外的工作请求？
能，我们是一个小组，小组内会互相学习与交流。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
对于变更要有一定的心理准备和应变能力；
我们会尽量提前商量、讨论好可能的需求变更，并留出后路。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是在迭代开始之前小组成员讨论共同设计的。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，确定几种可能的情况，延申设想，根据实际需求确定哪种更好。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
有用到UML，有效，对于项目的功能需求更明了，更细致、全面，不断的学习，已更新。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
我负责 的部分中使用了MVC框架，在这个框架的使用中bug最多；原因是对MVC框架不熟练；有些jar包版本不匹配或冲突会导致程序报错；使用MVC框架不熟练，连找bug都花费了很长时间。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
小组之间交叉评审；基本上严格执行了代码规范，但是有部分还是很难改变自己的编码习惯。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计工作在最开始的时候就应该考虑到各种可能出现的情况，并提前做好规划。
比如，代码规范这方面，小组内最好也在一开始就确定使用同一种规范，这样能在一定程度上提高代码的可读性，最后集成的时候也会更方便。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
前其主要是自己测试自己负责部分的代码，后期，会安排专人负责测试。
2. 是否进行了正式的验收测试？
通过了第一次迭代的验收。
3. 团队是否有测试工具来帮助测试？
没有。。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
软件的实现还不够完善，还没有跟踪软件的效能。
5. 在发布的过程中发现了哪些意外问题？
还未发布。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
迭代过程中需要不断的测试；
尽可能留出一些时间用于软件测试。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
组内成员商讨、确定的。
2. 团队成员之间有互相帮助么？
有。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
互相协助完成。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
团队需要加强交流与沟通，这样既可以在早期及时发现并解决问题。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMM 一级。
你觉得团队目前处于 阶段的哪一个阶段?规范。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?队友之间磨合得比上一个阶段较好。
你觉得目前最需要改进的一个方面是什么?完善功能，美化界面。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
1.以个人为中心构建项目；我们小组是把三个主要的功能分给三个组内小团体来完成，小团体内又有一个人是核心，完成主要的功能，其他人配合、信任。
2.面对面交谈；每周至少两次的小组内讨论、聚在一起写代码，每周至少一次与助教沟通、讨论进度与遇到的问题。