第09组 Alpha事后诸葛亮
Posted lyhtsl
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了第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、每个成员明确公开地表示对成员帮助的感谢 (并且写在各自的博客里):
- 我感谢培荣对我的帮助, 因为他是大佬,我要牢牢抱住大佬的大腿,说实话是由于培荣完成了总体框架,我才能比较好的完成服务器与数据库的对接。
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 | 计划 | 10 | 10 |
·Estimate | ·估计这个任务需要多少时间 | 10 | 10 |
Development | 开发 | 720 | 900 |
·Analysis | ·需求分析 (包括学习新技术) | 130 | 160 |
·Design Spec | ·生成设计文档 | -- | -- |
·Design Review | ·设计复审 | -- | -- |
·Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | -- | -- |
·Coding | ·具体编码 | 550 | 700 |
·Code Review | ·代码复审 | 30 | 30 |
·Test | ·测试(自我测试,修改代码,提交修改) | 10 | 10 |
Reporting | 报告 | 15 | 15 |
·Test Repor | ·测试报告 | 5 | 5 |
·Size Measurement | · 计算工作量 | 5 | 5 |
·Postmortem & Process Improvement Plan | ·事后总结, 并提出过程改进计划 | 5 | 5 |
合计 | 745 | 925 |
- 个人学习进度条
第N周 | 新增代码(行) | 累计代码(行 | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
---|---|---|---|---|---|
1 | 5 | 5 | 学会了简单的java和墨刀的使用 | ||
2 | 400 | 400 | 10 | 15 | 再次学习了python的使用 |
3 | 500 | 900 | 12 | 27 | 继续学习python,开始学习HTML |
4 | 800 | 1700 | 8 | 35 | 加深对python的学习 |
5 | 0 | 1700 | 1 | 36 | 学会了对一些作图工具的简单使用 |
6 | 200 | 1900 | 3 | 39 | 学习了js和SDN |
7 | 200 | 2100 | 5 | 44 | 学习了如何使用SQL创建数据库和使用python调用数据库 |
8 | 700 | 2800 | 8 | 52 | 学习了网络接口的调用,使用网络接口 |
以上是关于第09组 Alpha事后诸葛亮的主要内容,如果未能解决你的问题,请参考以下文章