“快易需求”第一次迭代总结

第一次迭代结束了，说明项目的第一阶段已经完成了。在第一次迭代过程中、完成了项目需求所定的alpha版本的所有需求已经部分beta版本的需求。但是革命尚未成功、同志仍需努力

设想和目标

• 我们要做什么

项目为“快易需求文档智能生成系统”。软件需求文档是软件开发与维护的重要基础，本项目希望通过建立一个专业的需求文档编辑系统，为软件开发人员提供一个便捷的协作文档编写工具，推动需求文档编写的规范与文档重用工作。同时，也为广大软件公司提供一个随时可以访问的平台，推广快易文档编写系统。

• 目标达到了吗

在alpha版本验收的时候，已经完成了所有alpha版本需求。

• 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

通过本次项目，几乎每个组员都实现了web开发从0-0.7的改变，就当前项目来讲，几乎每个人都可以独自修复 bug。

• 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

项目大致上来讲是比较成功的，需求大部分也完成了。但是在开发过程中组员交流并不是太多，由于是分工开发，所以有时候每个人遇到相同问题都是在卡壳，如果重新来，最好要记录开发过程中遇到问题记录日志。

计划

• 是否有 充足时间来做计划？

需求明确阶段时间比较长（比开发时间 要长），加上数据库设计大约商量了五六周的样子。其实在开发过程中，由于做中学、有很多东西不太会，每天晚上熬夜到两点，早上七点爬起来做。时间是一点点挤出来的；

• 团队在计划阶段是如何解决同事们对于计划的不同意见的？

开会，具体讨论，举实例，以理服人

• 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

alpha版本原定计划已做完
-有没有发现你做了一些事后看来没必要或没多大价值的事?
一开始不会做，就直接在jsp里面做。做完之后发现完全不满足松耦合、可维护、可复用等。又重构了整个后台

• 是否每一项任务都有清楚定义和衡量的交付件?

定义完需求之后就列出了每个功能点需要实现的需求

• 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

做项目的时候 发现数据库设计的有一点问题，导致程序无法继续执行下去。后面开会讨论，最终修改了数据库。这也是因为是第一次设计数据库，考虑的不够周到。

• 我们学到了什么，如果历史重来，我们会做什么改进。

学到的东西其实是非常多的，首先将以前的h5+css3+js+jq用于实际操作当中，在开发过程中学到了很多技术例如jsp\ajax\servlet\jstl\el表达式等等。但是 在这个过程中学习到的更多的是如何与队友去合作。如果历史会重来，那么一定更多的加强组员之间的沟通。

设计/实现

我们组采用的设计实现模式是每个人分块 进行实现，这样 能够确保每个人都能够在开发过程中学到足够多的东西。

测试/发布

在alpha版本验收的时候进行了“大规模”的测试，但是由于时间原因，测试数据量不够大、仍然有可能存在潜在bug

团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

    团队中每个成员都参加整个开发过程，这样确保每个人都学到相关技术。

2. 团队成员之间有互相帮助么？ 

   遇到不会的，有bug的，大家经常会商量，互相帮助

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

	开会，讨论需求，讨论下一步应该怎么做。
	感谢每个组员的辛苦付出、有一周几乎都是晚上两点多睡，七点起床做项目。

总结:

 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
 CMMI
  你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
  规范

	对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。 
	采用了mvc设计模式，代码松耦合、易维护、复用性强等。
	
	正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
	优化代码。程序=算法+代码，尽可能去优化算法