第09组 Alpha事后诸葛亮

组长博客链接###

组长博客

参考邹欣老师的问题模板进行总结思考###

设想和目标（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、当出现项目管理、合作方面的问题时，团队成员如何解决问题？

• 不论什么类型的问题，我们团队的解决方法第一步都是团队讨论，然后进行集思广益解决问题。

4、每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

• 感谢大腿培荣对我的帮助，前后端全能型选手，因为前端组全部都是小白，培荣经常会帮助我们解决bug，在我们不知道怎么继续的时候给我们指路，甚至还会给我们先探一段，是我们前端组的明灯！（不是狗头的那个hhh
  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	·估计这个任务需要多少时间	1000	1200
Development	开发	60	70
·Analysis	·需求分析 (包括学习新技术)	300	420
·Design Spec	·生成设计文档	15	20
·Design Review	·设计复审	10	8
·Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	10	5
·Coding	·具体编码	420	450
·Code Review	·代码复审	30	45
·Test	·测试（自我测试，修改代码，提交修改）	60	65
Reporting	报告	--	--
·Test Repor	·测试报告	--	--
·Size Measurement	· 计算工作量	10	10
·Postmortem & Process Improvement Plan	·事后总结, 并提出过程改进计划	20	20
	合计	965	1143

个人学习进度条

第N周	新增代码（行）	累计代码（行）	本周学习耗时(小时)	累计学习耗时（小时）	重要成长
1	0	0	8	8	学习使用原型工具
2	0	0	8	16	学习pyqt和pycharm的使用
3	162	162	20	36	学习链接服务器等
4	270	432	34	70	学习各种槽函数等交互，UI实现
5	0	0	20	90	原型设计等
6	156	588	10	100	学习html+css
7	993	1581	19	119	初步完成前端页面
8	358	1439	10	129	完善页面，学习uni-app