第09组 Alpha事后诸葛亮

标签：平台   程序   字体   要求   艺术   针对   body   运行   事先   

组长博客链接

组长博客

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

设想和目标（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、每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

• 我感谢培荣对我的帮助， 因为他是大佬，我要牢牢抱住大佬的大腿，说实话是由于培荣完成了总体框架，我才能比较好的完成服务器与数据库的对接。

5、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 我们在团队合作方面，能够及时沟通解决，没有出现大的问题，在这一方面我们是比较优秀的。

总结:（3分）

1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

• 初始级。并非是通过健全的制度驱动项目推进，主要靠项目负责人跟进和分配任务。在开发的主要力量中，主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。

2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

• 磨合之上，规范之下，在距离规范化开发还是有一定的距离，我们整努力向规范化前进。

3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?

• 在团队的分工以及协作能力上大大提升。

4、你觉得目前最需要改进的一个方面是什么?

• 规定代码书写规范。

5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

• 遵循协作规则，在项目中取得更好的成功：团队成员通过讨论协作解决问题。
• 稳步工作，不应该有生产爆发：我们组提前做好任务安排和开发计划，给每个模块留出充足的时间。
• 以简洁为本，它是极力减少不必要工作量的艺术。：坚持简洁开发的原则，砍掉一些鸡肋的功能，轻文档，轻流程，重产出，重目标。

全组讨论的照片

答辩总结

团队贡献度

本组的现场答辩得分:52.6

其他组提出的问题

电动车违规驾驶责任归谁
对于这个问题，在前面的几次答辩中已经说过很多次。首先目前我们不会在明令禁止不能载人的地方去适用我们的软件；其次，我们初步只针对福大的校园市场，目前校园电动车载人的现象非常非常普遍；最后，如果实在担心这个问题，可以选择我们软件的短租车模块，可以自己单独使用，不用载人。

电动车是不能带人的，被交警抓了怎么办，罚款谁出
对于这个问题，在前面的几次答辩中已经说过很多次。首先目前我们不会在明令禁止不能载人的地方去适用我们的软件；其次，我们初步只针对福大的校园市场，目前校园电动车载人的现象非常非常普遍；最后，如果实在担心这个问题，可以选择我们软件的短租车模块，可以自己单独使用，不用载人。

界面可以在beta阶段继续完善，主打高级整洁
好的，非常感谢建议。

怎么保证电动车是否合规？
我们的司机认证模块，要求填写驾驶证的有效期，合规的电动车才会有驾驶证，我们后期如果时间允许，考虑增加上传驾驶证并进行核实的功能。

要怎么解决加载慢的问题?
我们将考虑优化算法。

你们如何与QQ任务群这样人数众多的平台抗衡
不断完善我们软件的自身功能，减少bug，以实力赢取顾客的选择和喜爱。

界面能不能好看一点，左边固定有点难看
首先每个人的审美不一样，我们目前确实会比较简陋，后期会综合考虑进行界面的美化。

单纯的限制身份证号的位数还是很难保证信息的真实有效，这个你们如何解决呢？
这次是因为时间紧，所以只能单纯限制身份证号的位数，后面将对此功能进行改进，提高安全性。

我自己血的教训必须说一下，用web框架做app的性能真的实在是太憨了，如果实在想用一种语法统一多端，更建议用小程序或者flutter
好的，谢谢建议。

界面那里地图加载比较慢，是否考虑把速度提高。
会的。

你们的应用似乎使用网页技术进行开发，请问采用什么解决方案打包成应用，与原生系统的互操作性如何？
采用web-vue组件，嵌入html,做成uni-app部分，然后打包成app，原生操作性还可以。

PSP与学习进度条
PSP

• 个人学习进度条

第09组 Alpha事后诸葛亮

标签：平台   程序   字体   要求   艺术   针对   body   运行   事先   

原文地址：https://www.cnblogs.com/lyhtsl/p/11923592.html