设想和目标
1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们的软件需要解决的问题是当前高校学生征信系统建设薄弱的问题，我们试图建立一个征信系统，在完成之后推向高校试用。减少类似于“校园贷”之类的恶性事件的发生。
- 我们认为我们对于该软件的定义相对清楚，在项目需求报告中也给出了相对清晰的典型用户和典型和场景。
2 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？)
总体来说，基本达到预期目标，但是也还有些目标没有完成。在Alpha阶段，完成了系统的基础功能，在功能上还有一些数据的关联操作没有做到，在界面效果上，还有一些例如使用图表更直观的数据展现、界面UI的美化等细节还需要再学一些新的东西去做。
3 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
如果历史重来一遍的话：
- 细化目标
有时候对于目标的设定有点大，应从小目标抓起。 - 目标完成计划要更早制定
需要更早的制定计划，并对各自所需要做的模块所需的技术进行学习，以便在冲刺的时候节省时间
计划
1 是否有充足的时间来做计划?
做计划的时间整体来说是比较充分的，做完较为详细计划再去进行执行。
2 团队在计划阶段是如何解决同事们对于计划的不同意见的？
在团队计划阶段，对于计划的不同意见的处理上，主要是当事人提出，再进行协商，最后的解决方式，要么是听从团队中技术水平相对好的同学，要么是集体投票解决。
3 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
事实上，我们原计划的工作并没有做完。没有按时完成的任务包括：学生部分的网页UI设计；学生信用管理模块；事务管理员的奖助贷管理事务。没有完成的原因可以主要分为以下几点：
- 小组成员对Web开发不熟悉，所以在基础技能的学习和掌握上花费了大量时间。实际表明，掌握的结果也不是太理想。
- 低估了项目的难度。由于没有相关的项目经验，所以在任务计划上出现了偏差。另外，直接使用SSH和easyUI框架进行开发也无疑加大了学习成本和项目难度，这些都导致了项目进展缓慢。
- 冲刺期间，课程较多，学科作业需要耗费一定的时间。同时实验室老师的要求也需要大量时间来完成。
4 有没有发现你做了一些事后看来没必要或没多大价值的事?
说起来的话，对于前端知识和SSH框架的系统学习不仅没有给项目带来好的结果，而且大大拖慢了其进展。其实，我们后来发现，只要是先稍微掌握些基础知识就可以直接上手并在实际编程中发现问题并解决问题从而达到提高自身能力的良好循环。
5 是否每一项任务都有清楚定义和衡量的交付件?
我们对项目任务进行了简单的分块，并对这些模块任务进行了简单的规定。比如说：任务的简单定义，需要完成的一些功能，交付时间，工作量的估计时间等。但是对其缺乏一种合理的量化标准。
6 是否项目的整个过程都按照计划进行？
前期的学习任务超出了本来的工作计划，所以不得不进行调整。导致后面的编码实现任务不得不延后，进而导致了项目工作在冲刺结束时没有完全完成。
7 在计划中有没有留下缓冲区，缓冲区有作用么?
缓冲区？不存在的。冲刺时间本身有限，而且又有着其它事务需要我们去完成。所以当时我们并没有考虑所谓的缓冲区。有时间我们就抓紧时间进行项目工作，当然，每个人自己也会有适当的调整和放松时间。
8 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
由于这次的冲刺并没有如期完成目标，所以整个项目的任务必须要整体向后迁移。除了对之后的任务进行时间分配外，我们也要留出足够的时间来完成被延误的工作并对其进行测试。除此之外，我们要对针对成员个人制定合适的工作时间计划，灵活调整。缓冲区的话也要加上，留出一定的空余时间以备不时之需。
资源
1 我们有足够的资源来完成各项任务么?
排除干扰因素和一定的学习成本，我们是有足够的时间和能力来完成各项任务的。但是不合理的学习计划和对任务的单纯理解导致了我们未能按时完成。不过这段经历对我们接下来的工作提供了很好的帮助。
2 各项任务所需的时间和其他资源是如何估计的，精度如何?
我们将项目任务主要分为三大类：学习任务，开发任务和记录任务。学习任务是想通过一些网站进行查询来事先判断其大致的内容，然后分配一定的时间给改任务。开发任务主要是按照功能的数量来分配任务所需时间的。记录任务主要是包括每天的任务计划，任务总结、博客更新等。这里可以通过第一天的时间记录来对以下的记录任务进行时间分配。精度为小时(h)。
3 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
人力的话三个人刚好，分工合理且明确。软件/硬件资源的话都足够。由于先前的学习任务投入了过多的时间导致了任务的延后，所以最后留给测试的时间很不充裕，所以对其的投入时间是不合理的。
此外，我们对网页的设计低估了其难度。在套用SSH和easyUI框架后，网页的参数和前端的处理都变得很难处理。另外，网页布局也是花了不少时间。
4 你有没有感到你做的事情可以让别人来做（更有效率）?
小组成员都是第一次开发Web应用，都需要一定的学习成本。相比之下，目前的分工也算是合理。大家都觉得自己的工作有难度，但也是坚持做下去。或许目前的分工已经很合理了。
5 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
-
低估了项目的难度。由于没有相关的项目经验，所以在任务计划上出现了偏差。以后要对项目任务进行一定的了解后再制定计划。
-
要懂得主动求助大佬。 以前不知道有Web开发经验的同学所以是自己在摸索。以后遇到不懂的要多学多问，学以致用。
变更管理
1 每个相关的员工都及时知道了变更的消息?
在我们小组内信息的流通是非常顺畅的。由于大家都是室友，基本上晚上回去的时候可以就某一问题进行探讨。如果有信息变更的话成员间会第一时间共享。此外，我们使用了gitHub作为协同编程工具以及leangoo项目管理工具进行项目任务的管理。在每位成员变更项目信息时其他成员能第一时间接到通知。
2 我们采用了什么办法决定“推迟”和“必须实现”的功能?
首先我们就项目任务的重要性进行了分级，其中最重要的就是记录任务。我们坚持无论是否按时完成任务也要如实记录的原则，这一点无疑给我们的项目任务管理带来的极大的优势。就软件功能的重要性我们对编程任务的具体模块进行了不同的分级，当时间有限，我们会优先完成重要的任务，推迟其它任务。
3 项目的出口条件（Exit Criteria）是否得到清晰的定义?
我们的定义简单粗暴：项目完成事先定义好的基本功能，能通过设计好的测试用例。
4 对于可能的变更是否能制定应急计划?
这个倒是没有认真考虑过。说实在的，如果真的出现大的变更的话，现有的任务就要推倒重做了。。。
5 员工是否能够有效地处理意料之外的工作请求？
这个要看小组成员的个人能力和情况了。目前来说，我们三个人的能力都比较弱，只能够勉强完成项目的基本要求。如果是意料之外的请求的话就要具体问题具体对待了(导师的要求不能耽误啊)。
设计/实现
1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计的工作，主要是大家一起完成，大家一起讨论，比如界面整体的布局、展示数据的表单等等。设计工作主要是在Alpha冲刺阶段的早期完成，时间和人员应该都是相对合适的。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有是有一点的，比如在学生查看自己的信用活动记录的时候，是使用easy UI的表单还是使用图表等，解决方式一般都是查资料判断实现的难易程度来解决，比如使用表单展示相对简单，而图表则有更好的展示效果，所以，我们选择先在Alpha阶段做出表单的展示，之后再升级或扩展为图表。我们认为，再Alpha阶段，先完成最为基础、重要的功能，之后再进行展示效果的升级。
3. 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
存在一定的出入，因为在实现的过程中，发现初始的UML文档并没有将需求分析的很合理，比如某模块的功能与某模块其实应该分开，但是初始的UML文档并未区别。是需要更新UML文档的。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
在实现中，出现Bug最多的功能在于datagrid数据的展示功能。由于没有接触过，按照网络上的一些关于datagrid的操作，一直实现不了在内部重新去load一个url，也就导致了后台数据以json格式传到前台之后，仍然以json格式展示，不能进入datagrid进行适配填充。这个Bug卡了较长的时间。在Alpha阶段展示时，倒并没有出现特别重大的Bug。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
很可惜的是，我们并没有来得及进行代码复审。所有的代码都都是在开发某功能完成之后便未复审，时间的仓促，没有来得及，深感遗憾。由于事先没有约定好代码规范，所以三个人也不太一致。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 加快开发过程，争取有时间进行代码复审。
- 在冲刺一开始，其实就应该先定义统一的代码规范。
- 进行预学习所需技术，不至于因为某些属性的使用而耽误时间
测试/发布
1. 团队是否有一个测试计划？
团队有一个测试计划，但这个测试计划是在后期临时定义的，测试用例很难全方位的覆盖程序的各个部分，所以还是需要在使用过程中去发现。
2. 是否进行了正式的验收测试？
还没有，系统还处在开发阶段，部分功能还未完成，所以还没有进行验收测试。
3. 团队是否有测试工具来帮助测试？
没有
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
在测试过程中很多恶性BUG还是常有出现的，比如表单显示不正确，网页布局出问题等等。这些问题在通过测试找到并修正之后明显的提升了软件的使用体验，但在系统漏洞的追踪方面缺乏记录，导致很多问题发现后又难以追踪，这方面是值得花时间改进的。
5.在发布的过程中发现了哪些意外问题？
系统在设计阶段不够细化，导致后期实现时很多功能的细节上与预先的需求有所偏差，对开发工具与框架不够熟悉，导致很多实现不是由需求驱动的，而是由技术驱动的。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
角色的确定是通过自身技能的偏向决定的，但团队中整体对于SSH框架都不是很熟悉，都是属于边学边做的这么一个过程，所以也是属于人尽其才吧。
2.团队成员之间有互相帮助么？
作为一个团队项目，肯定是有互相帮助的，主要体现在技术方面的学习上和设计的交流上的，其中设计上主要是开会探讨，技术上主要是比彼此学习加帮扶。
3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
主要是通过开会交流，尝试找到问题的根源，然后化解矛盾或达成一定的妥协。
4.每个成员明确公开地表示对成员帮助的感谢：
我感谢 潘伟靖______对我的帮助， 因为某个具体的事情: 系统开发框架的使用__。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我认为我们的团队目前输入可重复级(Repeatable)这一档次，我们的管理存在一定的制度，管理也存在一定的规章制度，开发过程也存在一定的标准，存在一定的可重复性。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
应该属于磨合阶段，团队对部分问题的看法不一致，但也能在这种不一致下完成任务，对于彼此的看法也开始被公开出来，彼此对于这个项目的观点也在趋向统一，但还是有很多问题达不到一致。总之，项目问题存在但还在可调和的阶段。
你觉得目前最需要改进的一个方面是什么?
目前最需要改进的就是我们项目组成员的技术储备量，尤其是框架使用方面的技术储备。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
1.小组成员都为同宿舍的学生，交流时间充足，对彼此的看法与项目进度的把握都比较及时，不会产生过多的误解。
2.项目的测试工作有一定的计划，并对测试中存在的问题进行了记录并加以修改补正，这让项目的质量有了一定的保障。