Alpha 过后诸葛亮

前言

• 过后诸葛亮？做业名真的很差听，下一届还要沿用吗？

• 队名：小白吃

• 通向hjj博客的任意门

---

思考总结

设想和目标

1. 咱们的软件要解决什么问题？是否认义得很清楚？是否对典型用户和典型场景有清晰的描述？
   • 咱们软件很明确的定义为，解决食堂用餐结算点单效率低下的问题
   • 典型用户：在校大学生
   • 典型场景：大学食堂
2. 咱们达到目标了么（原计划的功能作到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
   • 原计划功能：自选菜品自主结算，非自选菜品在线点单，用餐数据分析反馈
   • 实现状况：
     • 自主结算和在线点单功能已基本实现，除支付环节由于资质问题暂时难以实现
     • 数据分析功能，已实现“猜你喜欢”菜品推荐模块
   • 交付和用户：软件功能基本实现，但实际投入使用存在困难，暂时没法投入使用
3. 用户量, 用户对重要功能的接受程度和咱们事先的预想一致么? 咱们离目标更近了么?
   • 暂未投入使用，用户实际接受成度未知
   • 产品完成度好，固然离目标更近了
4. 有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?
   • 总体实现难度大，若是重来一遍，会考虑换个项目

计划

1. 是否有充足的时间来作计划?
   • 计划老是赶不上变化，最开始的计划根据进度不断调整，到最后就抛弃了计划，赶+肝
2. 团队在计划阶段是如何解决同事们对于计划的不一样意见的？
   • 计划阶段讨论都很顺利，没有太多不一样的意见，可能这也是不足的地方。
3. 你原计划的工做是否最后都作完了? 若是有没作完的，为何?
   • 团队总体项目推动很顺利，alpha版本的计划都作完了
4. 有没有发现你作了一些过后看来不必或没多大价值的事?
   • 后敬甲：在alpha答辩里，作了现场演示环节，但出了bug评估下来反而成了减分项
   • 刘浩：额外作了数据集，花费大量时间，后期并无用到
   • 泽明：训练了多批数据集，最后只用到一个权重，利用率很低
   • 葛亮：不少界面没有一块儿讨论，最后没有对接到项目中
   • 黄泽：了解了后端的知识，没有实际应用（由于被大佬搞完了）
   • 静茹：找了不少图标和设计的一些界面，没有所有用到
   • 文斌：最开始使用的编程语言没有选择好，花了一些时间学习其余的知识
5. 是否每一项任务都有清楚定义和衡量的交付件?
   • 没有，你们都在一块儿作，沟通都很及时，没有绝对标准，标准随时沟通调整，你们都以为ok就直接整合对接
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为何没有估计到?
   • 没有彻底按照计划进行，计划老是调整中
   • 前端界面在一开始的设计不够规范，后期实施中不少界面不得不推翻重作
   • 风险主要是熬夜+时间，固然也估计到了
7. 在计划中有没有留下缓冲区，缓冲区有做用么?
   • 有缓冲区：睡眠+翘课
   • 有用，deadline前的效率都至关高，有时间就有产出
8. 未来的计划会作什么修改？（例如：缓冲区的定义，加班）
   • 在团队合做方面，仍是继续和之前同样，团队在一块儿工做是最重要的，基本一周七天会有五天晚上都在一块儿
9. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?
   • 后敬甲：
     • 在团队的合做中，收获了不少课程之外的东西，很重要但很差描述
     • 若是能重来，要参与到项目的编码工做中去，才能更好跟进进度
   • 刘浩：
     • 基本了解并参与了整个小程序的开发流程（全栈工程师了解一下）
     • 若是能重来，要提升效率和沟通，避免没必要要的熬夜
   • 泽明：
     • 学习到以项目进程和做业deadline，来驱动本身学习。
     • 若是能重来，我要作前端
   • 葛亮：
     • 了解了小程序的开发流程，前端开发的知识。
     • 若是能重来，会选择不买书，去百度
   • 黄泽：
     • 学到了不少前端语言和知识。
     • 若是能重来，会全面、有条理、计划地学习小程序开发
   • 婧茹：
     • 学到了前端的界面制做知识和认识到本身和大佬的差距
     • 若是能重来，会选择专一前端制做，好好学习
   • 文斌：
     • 学到了推荐算法和加深了对python的使用
     • 若是能重来，我必定拉个队友，不想一我的刚了，同时也会提升本身的学习效率

资源

1. 咱们有足够的资源来完成各项任务么?
   • 咱们完成了任务，但时间和资金的资源限制，没有作到完美
2. 各项任务所需的时间和其余资源是如何估计的，精度如何?
   • 时间主要是按任务量估计，时间按各自的安排估计
   • 精度很差，不能老是保持高效且时间安排总会有意外的冲突
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不须要编程的资源 (美工设计/文案)是否低估难度?
   • 测试没有系统、详细的安排，在最终整合以后，有作了简单的测试，没有花费不少时间
   • 人力资源足够（即使咱们组人数最少），硬件缺一个好的GPU服务器来提升算法的速度
   • 美工是作的很很差的一点，在后期实施上出了不少问题，低估了难度
4. 你有没有感到你作的事情可让别人来作（更有效率）?
   • 这个问题很挑事儿，没有问你们
5. 有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?
   • 后敬甲：
     • 分工不够仔细、明确，对你们配合效率有必定影响
     • 若是能重来，要把分工作的更加明确，有调整要及时通知到你们
   • 刘浩：
     • 选题会要从新考虑，考虑到本身的时间和精力支配
     • 若是能重来，好好考虑选题
   • 泽明：
     • 代码命名很差，给编程带了不少额外的麻烦
     • 若是能重来，会作好代码规范，培养好的编程习惯
   • 葛亮：
     • 原型设计时，没有参考开发文档，设计界面不够规范，后期有不少界面须要返工重作，浪费了不少时间
     • 若是能重来，会在一开始学习好开发文档，遵守贵伐开发界面
   • 黄泽：
     • 没有规范好界面，不少界面在后期都作了大面积调整甚至重作
     • 若是能重来，会在一开始沟通并肯定好界面，避免后期的大幅度调整甚至重作
   • 婧茹：
     • UI设计不够规范，开始的时候用手稿代替工具设计，在后期形成了许多麻烦
     • 若是能重来，会好好学习UI设计，作好界面的设计
   • 文斌：
     • 对python的使用不够熟练，致使使用的时候常常得查找资料
     • 若是能重来，会好好的，系统的学习python，熟练对python的使用

变动管理

1. 每一个相关的员工都及时知道了变动的消息?
   • 咱们队在团队编程这点作的很好，基本天天都会在双创一块儿工做，因此有变动你们都会及时知道
2. 咱们采用了什么办法决定“推迟”和“必须实现”的功能?
   • 一开始就决定了主体功能，主体功能没有调整过，附加功能都属于可推迟（但并无推迟）
3. 项目的出口条件（Exit Criteria – 什么叫“作好了”）有清晰的定义么?
   • 能作到实现除支付功能外的其它功能就好
4. 对于可能的变动是否能制定应急计划?
   • 没有提早制定应急计划，但有变动时会及时作出反应和调整
5. 员工是否可以有效地处理意料以外的工做请求？
   • 你们的及时调整都很棒，对于意外的发生也能作出迅速的反应
6. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?
   • 一块儿工做真的很重要！！！

设计/实现

1. 设计工做在何时，由谁来完成的？是合适的时间，合适的人么？
   • 整个模式的设计是在项目初期，由pm和老师沟通商定的
2. 设计工做有没有碰到模棱两可的状况，团队是如何解决的？
   • 没有
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其余工具来帮助设计和实现？这些工具备效么？
   • 有UML图来帮助设计，也有不少的设计素材网站为咱们提供了不少tu'pian'su'cai图片素材
4. 比较项目开始的 UML 文档和如今的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
   • 文档更加丰富了，会在项目推动中，不断完善、更新文档
5. 什么功能产生的Bug最多，为何？在发布以后发现了什么重要的bug? 为何咱们在设计/开发的时候没有想到这些状况?
   • 支付功能整个就是个bug，由于资质不够没法申请微信支付
   • 尚未发布
   • 有想到，但确实没法申请，但在软工角度来说，这只是其中一个模块，不能由于这个模块放弃整个项目
6. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
   • 现阶段没有执行代码复审，也没有严格的代码规范

测试/发布

1. 团队是否有一个测试计划？为何没有？
   • 有制定详细的验收标准，但没有详细的测试计划
   • “完成，比完美更重要”，现阶段已完成项目为主
2. 是否进行了正式的验收测试？
   • 否
3. 团队是否有测试工具来帮助测试？
   • 暂未考虑
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工做有用么？应该有哪些改进？
   • 暂未考虑
5. 在发布的过程当中发现了哪些意外问题？
   • 支付功能未解决，暂时不考虑发布
6. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?
   • 仍是以完成项目功能为首要任务，测试方面暂时没有精力、时间考虑

团队的角色，管理，合做

1. 团队的每一个角色是如何肯定的，是否是人尽其才？
   • 团队角色肯定，以尊重我的意愿为首要因素，再根据实际状况协商肯定角色
2. 团队成员之间有互相帮助么？
   • 固然，天天的工做都是和谐友爱、互帮互助的~
3. 当出现项目管理、合做方面的问题时，团队成员如何解决问题？
   • 我要感谢团队中的每个人，感谢你们的努力和付出，感谢你们的互相帮助和配合，每一个人个性、能力都不一样，但咱们都在求同存异，互相配合，每一个人都很nice！

总结

1. 你以为团队目前的状态属于 CMM/CMMI 中的哪一个档次?
   • 属于CMMI一级，完成级
2. 你以为团队目前处于 萌芽/磨合/规范/创造 阶段的哪个阶段?
   • 磨合基本完成，接下来是规范
3. 你以为团队在这个里程碑相比前一个里程碑有什么改进?
   • 你们彼此更加熟悉，互相的配合会比以前更有效率
4. 你以为目前最须要改进的一个方面是什么?
   • 任务验收的规范化作的很差，在alpha阶段美工方面出了很大问题，没有沟通好界面的设计，以后会增强沟通、明确目标
     5.对照敏捷开发的原则, 你以为大家小组作得最好的是哪几个原则? 请列出具体的事例。
   • 围绕有积极性的我的构建项目，给予他所需的环境和支持。咱们在alpha阶段，刘浩同窗在除了完成我的的后端部分之外，对团队其它成员及其负责的部分，都有很大的帮助。
   • 在团队内部，最具备效果而且富有效率的传递信息的方法，就是面对面的交谈。团队在双创有实验室，因此咱们基本天天都会在双创一块儿工做，在此特别感谢卢哥哥为团队申请的场地

上照片！

（欢迎在alpha阶段后加入的新同窗：安哥和小白! PS:后敬甲的头真的放不进去了）

---

答辩总结

团队贡献比

成员	alpha冲刺	alpha答辩	贡献比
敬甲	机动+UI设计	ppt修改+任务分配+演示视频拍摄+博客整理	14
葛亮	自选模块界面制做	休息	13
黄泽	首页+非自选模块制做+接口对接	界面功能临时优化、调整	16
靖茹	我的信息界面制做+数据周报界面制做	答辩演练+现场记录	13
泽明	视觉识别算法训练及优化	答辩演练+ppt修改	13
文斌	猜你喜欢算法	ppt制做及演讲	13
刘浩	后端服务器配置及部署+先后端对接+任务分配	界面功能临时优化、调整	18

本组现场答辩分数

组号	对本组的评分
1	76
2	79
3	77
4	70
5	75
6	82
7	81
8	81
9	76

平均分：77.86

提问及回答

• 问题收集与回答

第1组
一、微信支付的资质问题在beta阶段有机会解决吗?

答：emmm，若是作得完，考虑注册个公司试试？（手动狗头）

二、是否考虑用本身的主机进行内网穿透运行相应算法弥补云服务器算力不足的缺点?

答：目前以完善功能模块为主，服务器性能问题暂时先不考虑。

三、在高并发场景下,服务器如何保证运行效率,是否会出现识别时排队等待识别结果的现象?

答：使用gunicorn辅助flask框架实现并发功能，实现并行检测，因为服务器条件比较简陋因此效果不是很明显

第2组
一、在商家店铺界面购买的食品到店自取吗，根据什么凭证来取食品？

答：在商家店铺界面购买的食品由顾客去档口自取，会设计排号码

二、假若扫描不出食品，是否可以进行自主选择？

答：能够，识别不出菜品属于低几率问题，如若出现，用户能够进入店铺勾选所选菜品后继续支付，而且提供反馈报错机制。

三、商家端具备哪些具体的功能？

答：商家端主要包括：在线店铺管理功能和流水管理功能

第3组
一、好像价钱计算有误，有一份图是17块，是个人错觉吗，有这么贵吗？

答：价钱计算并无错误，价格是在标注数据集时咱们本身标注的，并无严格按照实际状况去标注，因此现场演示出现了价格高于实际状况的问题，以后会去实际落实价格更改数据库

二、如何解决错误识别致使的用餐延误问题，是否变相的使得本来快捷的目的失去了意义？

答：识别错误已经控制在极小几率（现场演示有瑕疵，是由于拍手机上的图片会有摩尔纹影响），以后会继续完善、下降错误率

三、对于高并发状态下，响应速度会乐观吗？

答：使用gunicorn辅助flask框架实现并发功能，实现并行检测，因为服务器条件比较简陋因此效果不是很明显

第4组
一、识别上仍然存在必定的误判率，误判的结果导向偏严重，是否存在大量扩充数据集相似的改进方式？

答：误判率已经控制在较低几率，后期会继续扩充数据集、训练算法，以进一步下降误判率

二、是否考虑了响应时间？

答：服务器的性能对响应时间影响较大，后期若是资金足够会更换响应时间

三、价钱计算貌似存误，是否考虑从新计算？

答：价格计算不存在问题，只是在数据集标注时未按实际状况标注，后期会实际落实更改数据库

第5组
一、若是识别错误而致使少付了钱，事后有没有可能发现？

答：咱们会为商家和学生均提供反馈申诉机制

二、若是识别错误或响应较慢，是否反而下降告终帐效率？

答：识别速度会在以后有资金的状况下更换服务器，能够大幅提升结算速率。

三、请问大家会从哪些方面改进大家的算法？

答： 主要是两个方向：提升识别速率和扩大识别范围

第6组
一、您好，菜品识别出错，支付完成以后，是否有设计申诉反馈的功能？

答：会在后期设计申诉反馈机制

二、您好，单核的服务器难以支持软件开发，考虑怎么解决吗？

答：后期在有资金支持状况下，会更换服务器

三、您好，怎么进一步提升图片识别的精确度?

答：会继续拍摄数据集，训练算法，提升识别精度和识别种类

第7组
一、服务器问题可否找出较为合理的解决办法？

答：但愿后期能有机会使用更好的服务器。

二、现场演示出现了未识别出的状况，可是仍直接进入结算界面，这样是否是会对卖家形成损失，有没有考虑识别精确度

答：现场演示的照片是在手机上拍的，摩尔纹对识别结果影响很大，实际状况在已有菜品种类中，识别精度很高，错误几率很低

三、手动标注的工做量巨大，是否考虑其余有效的办法？

答：目前是没有其它有效的办法，只能靠队员本身来完成

第9组
一、若是出现扫描出错的状况，致使商家少收入和学生多付钱的状况该怎么办？

答：识别出错，咱们会提供给商家和学生端双向的申诉反馈机制。

二、对于不是碟装的菜品可否也能很好的识别？

答：咱们的识别计算功能目前值针对，自选的碟装菜品

三、食堂就餐时间时对该程序的使用是高并发的，那么如何解决高并发问题？

答：使用gunicorn辅助flask框架实现并发功能，实现并行检测

---

PSP与学习进度条

PSP表格

PSP	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	30	45
•Estimate	•估计这个任务须要多少时间	30	45
Development	开发	0	0
•Analysis	•需求分析 (包括学习新技术)	20	30
•Design Spec	•生成设计文档	0	0
•Design Review	•设计复审	0	0
•Coding Standard	•代码规范(为目前的开发制定合适的规范)	0	0
•Design	•具体设计	30	30
•Coding	•具体编码	0	0
•Code Review	•代码复审	0	0
•Test	•测试（自我测试，修改代码，提交修改）	0	0
Reporting	报告	0	0
•Test Repor	•测试报告	0	0
•Size Measurement	•计算工做量	20	30
•Postmortem & Process Improvement Plan	•过后总结, 并提出过程改进计划	30	45
	合计	160	225

学习进度条

第N周	新增代码（行）	累计代码（行）	本周学习耗时（小时）	累计学习耗时（小时）	重要成长
4	0	340	5	25	Leangoo工具学习
5	300	640	15	40	哈希算法、优先队列、结构体等c++内容复习
8	0	640	10	50	d代码方面暂无
10	0	640	5	55	Github代码管理学习、leangoo工具完善
12	100	740	5	60	了解了些python，写博客能力++
13	200	940	10	70	写博客继续++、ppt制做++、录屏++、头发--、睡眠------