设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要是想要提供一个简便的交易平台给学生进行二手书交易，但是没有定义得很清楚，也没有对典型用户和典型场景有清晰的描述
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
我们并没有达到目标，原计划的功能也只做到了50%左右，也没有按原计划时间进行交付。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高？
和上衣阶段相比，团队软件工程质量有些许提高，比方说在一些代码的运行速度上。
4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训：我们的项目选得太大了，我们并没有能力去完成这个项目，实际上，我们预想的功能即便全部实现，这个项目也是不完整的，它还缺少很多的实际功能；如果历史能重来一遍，我们会重新审视自己的能力，选择一个更加符合我们的状况的项目。
计划
1. 是否有充足的时间来做计划?
我们有充足的使时间来做计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们实行少数服从多数的原则。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我们原计划的工作没有做完，因为我们团队5个人中有4个新手，是基本没有学习课外知识的，我们很多时间都用来学习新知识，而且我们全部人没有团队项目经验，对时间的估算出入很大。
4. 是否项目的整个过程都按照计划进行，项目出了什么意外？
整个项目的过程没有按计划进行，项目实际上只完成了50%。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
我们没有留下缓冲区；缓冲区能够让我们在项目出意外时有时间进行弥补过错。
6. 我们学到了什么?如果历史重来一遍, 我们会做什么改进?
我们要量力而为，要结合自身实际来选择项目；如果历史能重来一遍，我们选择一个更加适合自己项目，并且对计划进行更加细致的划分，并且留有一定的缓冲时间，以防项目出意外时可以进行补救。
资源
1. 我们有足够的资源来完成各项任务么?
时间：上面也说过了，我们大多数人是新手，很多时间都用来学习新知识了，时间并不充足。
人力：我们组有五个人，是有足够的人来做项目的。
经验：我们没有人有过团队项目经验。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
我们是分组进行估算的，前端的只负责前端的估算，后台只负责后台的估算，精度很小。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间足够
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
没有，因为一个人的任务要求别人来做会增加他人负担，而且实际上我们前端的人基本上对后台没有什么认知。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
是。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
因为我们的软件的功能模块之间的关系比较紧密，团队成员们都比较及时地完成了任务，没有出现“推迟”的情况。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有定义，能拥有想淘宝一样的基础功能。
4. 对于可能的变更是否能制定应急计划?
没有，我们第一次做这种较为大型的团队计划，我们并不知道要制作应急计划。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作实际在计划阶段完成，由成员讨论，然后再由队长决定。我觉得是合适的时间，但不是合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
我们团队中并没有出现
**3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ **
有效
4. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码写完后，由同组的其他成员进行复审，我们较为严格地执行了代码规范。
测试/发布
1. 团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？
有，由于我们地项目并没由完成，我们只是测试了一部分。
2. 团队是否有测试工具来帮助测试？
没有。
3. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
每个模块由对应的人员进行测试，从软件实际运行的结果来看，这些测试工作是有用的。
4. 在发布的过程中发现了哪些意外问题？
我们的项目实际上没有完成，所以还没有发布。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMMI一级--初始级
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
萌芽阶段
你觉得目前最需要改进的一个方面是什么?
我们的开发文档实际上很糟糕，需要提高文档的质量，而且我们团队中的沟通并没有想象中那样，我们需要更多的交流。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 我们主张简单，我们对删除了暂不需要的功能
项目文档的质量如何提高？
一开始就应该采用模板，同时应当再文档中给出负责人，每完成一个任务就进行签名。
团队成员在Alpha阶段的角色和具体贡献
| 成员 | 角色 | 团队贡献分 | 可验证的贡献 |
| 冯荣新 | 前端 | 20 | 博客撰写，页面实现 |
| 陈泽佳 | 前端 | 19 | 页面实现 |
| 徐伟浩 | 后台 | 19 | 搜索算法的实现 |
| 邓帆涛 | 后台 | 19 | 意反馈实现 |
| 谢佳余 | 后台 | 18 | 搜索算法的实现 |