设想和目标（2分）
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 解决的问题
我们软件初期旨在解决福大用户等车难，租车难的问题，用户可以通过Pickme平台选择顺风车，快车出行，还可以租用社会闲置车辆。在校园市场运营成熟后，我们会拓展城镇市场，为社会用户提供Pickme的出行方案。 - 定义是否清楚
经过我们前期的需求分析、问卷调查、组内决策等一系列审核后最终定义下的软件，我们认为这也是兼具完备定义以及强健性的一款软件。在我们看来，定义得十分清楚，欢迎有疑问的小伙伴提出你们的宝贵意见。 - 典型用户
- 校园中面向未购置电动车、自行车的用户。
- 城镇中依赖公共交通、摩托出行的用户。
- 典型场景
- 场景一：校园上学高峰期，学生等不到小白，找不到共享单车，而还有很多电动车用户后座闲置。
- 场景二：小王想去城镇中心赶集，但是位置相对偏僻，等公交车要很久，又没有摩的司机经过。
以上可以通过我们的平台快速打车，便捷出行。（图片）
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
- 原计划功能实现情况
- 基本实现。
- 前端实现界面精美，操作简单。
- 后端搭建数据库，服务器，不足之处是响应速度不够快。
- 是否按原计划交付时间交付
- 是，我们在答辩前天完成所有工作。
- 原计划预期的用户数量是否达到
- 原计划没有预期能够有用户使用，只是在我们团队内部进行测试。
3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 用户量与预期一致。
- 当最终产品出来的时候，我们团队队员还是对我们实现的功能十分满意。
- 我们距离我们的既定目标已经无限接近。
4、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 技术方面
- 非技术方面
- 时间安排还是不够合理，我们在alpha冲刺开始之前已经完成接近50%的工作量，但是在alpha冲刺阶段，大多数组员都有各种各样的考试，整个项目进展缓慢，都是集中在答辩前两天完成的。
- 任务分配相对合理，能够按照每个人的能力大小来分配。
- 贡献比例分配不够科学，人为主观因素明显。
1、是否有充足的时间来做计划?
- 前期我们已经分配好任务，时间上是充裕的，但是最后因为各种原因有所延误，总体上进展顺利。
2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 我们组任务分配相对合理，几乎没有不同意见，有的小分歧都能通过协商解决。
3、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 王耀鑫，林银河，陈志荣，许培荣，沈梓耀，林明镇，滕佳，何佳琳，陈湘怡，陈超颖。
4、有没有发现你做了一些事后看来没必要或没多大价值的事?
- 前端一开始的开发直接用h5,没有按照HBuilder的规范，走了弯路。
5、是否每一项任务都有清楚定义和衡量的交付件?
- 每项任务都有清楚的定义，暂无科学的衡量标准，主观因素占多。
6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 没有全都按照计划进行，项目一度出现瓶颈，搭建服务器，网络请求，我们都没有相关经验，放缓了项目进度。
7、在计划中有没有留下缓冲区，缓冲区有作用么?
- 没有，因为当时给每个任务都预估出充足的时间。
8、将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 增加集中打代码的时间。
9、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到h5,flask,js，SQL SERVER,网络请求，如果历史重来，我们会重新分配好每个人应有任务，充分调动组内的参与度，避免有人划水的现象发生。
资源（3分）
1、我们有足够的资源来完成各项任务么?
- 没有，我们的组员都没有项目开发的经验，是在边学边做中完成的。
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
- 各项任务所需的时间和其他资源是基于过往经验以及咨询前辈，精度一般。
3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 人力足够，软件/硬件资源不足，测试方法比较粗糙，基本靠纯手工。没有低估那些不需要编程的资源 (美工设计/文案)，分配了比较有经验的人完成。
4、你有没有感到你做的事情可以让别人来做（更有效率）?
- 没有，每个人都能发挥自己的特长。
5、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
前端任务繁重，预估不足，应加派人手。
变更管理（4分）
1、每个相关的员工都及时知道了变更的消息?
- 都能及时知道消息，我们有自己的交流群，能及时沟通，实在不行就会电话通知。
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 根据实际情况决定。
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 能够流畅运行，不出现明显bug，以后再逐步完善。
4、对于可能的变更是否能制定应急计划?
- 能，后端及时去支援前端。
5、员工是否能够有效地处理意料之外的工作请求？
- 时间宽裕的情况下，能很好解决。
6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
做好应急预案。
设计/实现（4分）
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 设计在分工结束后就由各小组组长完成，目前看来时间是合适的，人选合适的。
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 字体选择的时候出现分歧，通过投票解决。
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
- 大部分测试是在HBuilder上测试，工具功能很强大。
4、比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 主体部分与项目开始的UML文档一脉相承，一些小边幅的修改需要更新UML文档。
5、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 网络请求Bug最多，数据请求和数据处理给我们带来很大的麻烦。发布后未发现重要bug。这些问题都是未知的，对于我们这些缺乏开发经验是无法预见的。
6、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 时间紧任务重，未能进行代码复审，也未能严格执行代码规范。
7、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在代码拼接中，需要浪费较多时间去理解其他人的代码。制定相应的代码规范。
测试/发布（3分）
1、团队是否有一个测试计划？为什么没有？
- 有一个简单的计划，对各个模块功能进行测试。
2、是否进行了正式的验收测试？
- 由于经验不足，未能进行验收测试。
3、团队是否有测试工具来帮助测试？
- HBuilder内置的模拟器来测试。
4、团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 团队目前不具备这方面的能力。
5、在发布的过程中发现了哪些意外问题？
- 暂无意外。
6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
制定详细的测试计划，尽量做到事无巨细。
团队的角色，管理，合作（3分）
1、团队的每个角色是如何确定的，是不是人尽其才？
- 由组长分配，真正做到了人尽其才。
2、团队成员之间有互相帮助么？
- 这个是必须的，每个人都有自己的盲区的，我们通过互帮互助解决不少困难。
3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 不论什么类型的问题，我们团队的解决方法第一步都是团队讨论，然后进行集思广益解决问题。
4、每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢 _______
<姓名>
______对我的帮助， 因为某个具体的事情: _____________________。
5、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
-我们在团队合作方面，能够及时沟通解决，没有出现大的问题，在这一方面我们是比较优秀的。
总结:（3分）
1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 初始级。并非是通过健全的制度驱动项目推进，主要靠项目负责人跟进和分配任务。在开发的主要力量中，主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。
2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 磨合之上，规范之下，在距离规范化开发还是有一定的距离，我们整努力向规范化前进。
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 在团队的分工以及协作能力上大大提升。
4、你觉得目前最需要改进的一个方面是什么?
- 规定代码书写规范。
5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 遵循协作规则，在项目中取得更好的成功：团队成员通过讨论协作解决问题。
- 稳步工作，不应该有生产爆发：我们组提前做好任务安排和开发计划，给每个模块留出充足的时间。
- 以简洁为本，它是极力减少不必要工作量的艺术。：坚持简洁开发的原则，砍掉一些鸡肋的功能，轻文档，轻流程，重产出，重目标。