组长博客链接###
参考邹欣老师的问题模板进行总结思考###
设想和目标（2分）####
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 解决的问题
我们软件初期旨在解决福大用户等车难，租车难的问题，用户可以通过Pickme平台选择顺风车，快车出行，还可以租用社会闲置车辆。在校园市场运营成熟后，我们会拓展城镇市场，为社会用户提供Pickme的出行方案。 - 定义是否清楚
经过我们前期的需求分析、问卷调查、组内决策等一系列审核后最终定义下的软件，我们认为这也是兼具完备定义以及强健性的一款软件。在我们看来，定义得十分清楚，欢迎有疑问的小伙伴提出你们的宝贵意见。 - 典型用户
- 校园中面向未购置电动车、自行车的用户。
- 城镇中依赖公共交通、摩托出行的用户。
- 典型场景
- 场景一：校园上学高峰期，学生等不到小白，找不到共享单车，而还有很多电动车用户后座闲置。
- 场景二：小王想去城镇中心赶集，但是位置相对偏僻，等公交车要很久，又没有摩的司机经过。
以上可以通过我们的平台快速打车，便捷出行。（图片）
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
- 原计划功能实现情况
- 部分实现，顺风车，快车实现，短租车未完成。
- 前端实现界面精美，操作简单。
- 后端搭建数据库，服务器，不足之处是响应速度不够快。
- 是否按原计划交付时间交付
- 是，我们在答辩前天完成相应工作。
- 原计划预期的用户数量是否达到
- 原计划没有预期能够有用户使用，只是在我们团队内部进行测试。
3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 用户量与预期一致。
- 当最终产品出来的时候，我们团队队员还是对我们实现的功能十分满意。
- 我们距离我们的既定目标已经无限接近。
4、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 技术方面
- 一开始前后端的接口定义不够规范，导致整合困难
- 最初前端没有使用uni-app项目开发，前端代码都是html文件，导致没办法使用uni打包到其他平台上，做出了的都是网页。
- 非技术方面
- 时间安排还是不够合理，我们在alpha冲刺开始之前已经完成接近50%的工作量，但是在alpha冲刺阶段，大多数组员都有各种各样的考试，整个项目进展缓慢，都是集中在答辩前两天完成的。
- 任务分配相对合理，能够按照每个人的能力大小来分配。
- 贡献比例分配不够科学，人为主观因素明显。
计划（5分）####
1、是否有充足的时间来做计划?
- 前期我们已经分配好任务，时间上是充裕的，但是最后因为各种原因有所延误，总体上进展顺利。
2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 我们组任务分配相对合理，几乎没有不同意见，有的小分歧都能通过协商解决。
3、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 做完了，因为俺太菜了，所以俺只是做个界面的
4、有没有发现你做了一些事后看来没必要或没多大价值的事?
- 前端一开始的开发直接用h5,没有按照HBuilder的规范，走了弯路。
5、是否每一项任务都有清楚定义和衡量的交付件?
- 每项任务都有清楚的定义，暂无科学的衡量标准，主观因素占多。
6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 没有全都按照计划进行，项目一度出现瓶颈，搭建服务器，网络请求，地图嵌入，我们都没有相关经验，放缓了项目进度。
7、在计划中有没有留下缓冲区，缓冲区有作用么?
- 没有，因为当时给每个任务都预估出充足的时间。
8、将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 定期集中敲代码。
9、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到h5,vue，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、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 我感谢许培荣（许老板）对我的帮助，因为前端也不简单，还是做APP，安卓开发挺难的对于我这种菜鸡，他就帮我们尽量不用JAVA做APP,而是套web，可能很呆，但是对我来说很有帮助，至少不自闭了。
4、每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
- 我感谢培荣对我的帮助， 因为我负责短租车的一个接口，我不会写，他会耐心讲解，教我，还有API文档，我不是很会写，他也都会很耐心地教，问问题也很乐于解答。
5、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 我们在团队合作方面，能够及时沟通解决，没有出现大的问题，在这一方面我们是比较优秀的。
总结:（3分）
1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 初始级。并非是通过健全的制度驱动项目推进，主要靠项目负责人跟进和分配任务。在开发的主要力量中，主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。
2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 磨合之上，规范之下，在距离规范化开发还是有一定的距离，我们整努力向规范化前进。
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 在团队的分工以及协作能力上大大提升。
4、你觉得目前最需要改进的一个方面是什么?
- 规定代码书写规范。
5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 遵循协作规则，在项目中取得更好的成功：团队成员通过讨论协作解决问题。
- 稳步工作，不应该有生产爆发：我们组提前做好任务安排和开发计划，给每个模块留出充足的时间。
- 以简洁为本，它是极力减少不必要工作量的艺术。：坚持简洁开发的原则，砍掉一些鸡肋的功能，轻文档，轻流程，重产出，重目标。
全组讨论的照片####
答辩总结###
团队贡献度
| 成员 | 贡献比例（%） | 分工 |
|---|---|---|
| 王耀鑫 | 3 | 小组规划、博客撰写 |
| 陈超颖 | 3 | ppt、答辩、博客撰写 |
| 陈湘怡 | 20 | 前端 |
| 许培荣 | 30 | 后端、整合 |
| 滕佳 | 7 | 前端 |
| 何佳琳 | 7 | 前端 |
| 沈梓耀 | 3 | 需求报告，ppt |
| 陈志荣 | 7 | 前端、ppt |
| 林银河 | 11 | 后端、数据库 |
| 林明镇 | 7 | 后端 |
| 黄恒杰 | 2 | 后端 |
本组的现场答辩得分:52.6
其他组提出的问题
电动车违规驾驶责任归谁
对于这个问题，在前面的几次答辩中已经说过很多次。首先目前我们不会在明令禁止不能载人的地方去适用我们的软件；其次，我们初步只针对福大的校园市场，目前校园电动车载人的现象非常非常普遍；最后，如果实在担心这个问题，可以选择我们软件的短租车模块，可以自己单独使用，不用载人。
电动车是不能带人的，被交警抓了怎么办，罚款谁出
对于这个问题，在前面的几次答辩中已经说过很多次。首先目前我们不会在明令禁止不能载人的地方去适用我们的软件；其次，我们初步只针对福大的校园市场，目前校园电动车载人的现象非常非常普遍；最后，如果实在担心这个问题，可以选择我们软件的短租车模块，可以自己单独使用，不用载人。
界面可以在beta阶段继续完善，主打高级整洁
好的，非常感谢建议。
怎么保证电动车是否合规？
我们的司机认证模块，要求填写驾驶证的有效期，合规的电动车才会有驾驶证，我们后期如果时间允许，考虑增加上传驾驶证并进行核实的功能。
要怎么解决加载慢的问题?
我们将考虑优化算法。
你们如何与QQ任务群这样人数众多的平台抗衡
不断完善我们软件的自身功能，减少bug，以实力赢取顾客的选择和喜爱。
界面能不能好看一点，左边固定有点难看
首先每个人的审美不一样，我们目前确实会比较简陋，后期会综合考虑进行界面的美化。
单纯的限制身份证号的位数还是很难保证信息的真实有效，这个你们如何解决呢？
这次是因为时间紧，所以只能单纯限制身份证号的位数，后面将对此功能进行改进，提高安全性。
我自己血的教训必须说一下，用web框架做app的性能真的实在是太憨了，如果实在想用一种语法统一多端，更建议用小程序或者flutter
好的，谢谢建议。
界面那里地图加载比较慢，是否考虑把速度提高。
会的。
你们的应用似乎使用网页技术进行开发，请问采用什么解决方案打包成应用，与原生系统的互操作性如何？
采用web-vue组件，嵌入html,做成uni-app部分，然后打包成app，原生操作性还可以。
PSP与学习进度条
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟) | 实际耗时（分钟) |
|---|---|---|---|
| Planning | 计划 | 30 | 30 |
| ·Estimate | ·估计这个任务需要多少时间 | 720 | 1090 |
| Development | 开发 | 120 | 240 |
| ·Analysis | ·需求分析 (包括学习新技术) | 120 | 300 |
| ·Design Spec | ·生成设计文档 | 60 | 60 |
| ·Design Review | ·设计复审 | 30 | 40 |
| ·Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| ·Coding | ·具体编码 | 240 | 300 |
| ·Code Review | ·代码复审 | 30 | 30 |
| ·Test | ·测试（自我测试，修改代码，提交修改） | -- | -- |
| Reporting | 报告 | 30 | 30 |
| ·Test Repor | ·测试报告 | -- | -- |
| ·Size Measurement | · 计算工作量 | 20 | 20 |
| ·Postmortem & Process Improvement Plan | ·事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 720 | 1090 |
学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 8 | 8 | 对前端语言有所掌握 |
| 2 | 0 | 0 | 10 | 18 | 前端语言基础掌握 |
| 3 | 780+ | 780+ | 17 | 35 | 界面交互完成的差不多了，接下来就是算法设计 |
| 4 | 900+ | 1700+ | 15 | 50 | 十三水代码运行差不多实现了（唉 |
| 5 | 0 | 1700+ | 15 | 65 | 学习移动端界面设计 |
| 6 | 0 | 1700+ | 15 | 80 | 学习移动端界面设计 |
| 7 | 1300+ | 3100+ | 30 | 110 | 部分界面开发 |
| 8 | 700+ | 3800+ | 10 | 120 | 部分界面完善 |