事后诸葛亮

前言

思考总结

设想和目标

  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组
1、微信支付的资质问题在beta阶段有机会解决吗?

答：emmm，如果做得完，考虑注册个公司试试？（手动狗头）

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

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

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

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

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

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

2、倘若扫描不出食品，是否能够进行自主选择？

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

3、商家端具有哪些具体的功能？

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

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

答：价钱计算并没有错误，价格是在标注数据集时我们自己标注的，并没有严格按照实际情况去标注，所以现场演示出现了价格高于实际情况的问题，之后会去实际落实价格更改数据库

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

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

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

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

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

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

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

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

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

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

第5组
1、如果识别错误而导致少付了钱，过后有没有可能发现？

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

2、如果识别错误或响应较慢，是否反而降低了结账效率？

答：识别速度会在之后有资金的情况下更换服务器，可以大幅提高结算速率。

3、请问你们会从哪些方面改进你们的算法？

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

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

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

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

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

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

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

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

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

2、现场演示出现了未识别出的情况，但是仍直接进入结算界面，这样是不是会对卖家造成损失，有没有考虑识别精确度

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

3、手动标注的工作量巨大，是否考虑其他有效的办法？

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

第9组
1、如果出现扫描出错的情况，导致商家少收入和学生多付钱的情况该怎么办？

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

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

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

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

答：使用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 代码规范(为目前的开发制定合适的规范) 20 20
Design 具体设计 30 30
Coding 具体编码 0 0
Code Review 代码复审 0 0
Test 测试（自我测试，修改代码，提交修改） 30 50
Reporting 报告 0 0
Test Repor 测试报告 0 0
Size Measurement 计算工作量 20 30
Postmortem & Process Improvement Plan 事后总结, 并提出过程改进计划 30 15
合计 180 260

学习进度条

第N周 新增代码（行） 累计代码（行） 本周学习耗时(h) 累计学习耗时(h) 重要成长
2 400 400 15 15 单元测试，性能分析
3 0 400 12 27 Balsamiq Mockups 3的运用
4，5 200 600 20 47 python爬虫、正则表达式、html
6 0 0 15 62 yolo模型训练
7 300 900 20 82 学习了python的部分
8，9 0 900 20 102 yolo模型优化
10，11 500 1400 20 122 yolo运用化代码修改，随机抽奖算法
12 200 1600 12 134 php学习
13 200 1800 12 136 写了一部分接口
posted @ 2018-12-02 22:33  路明  阅读(176)  评论(0)  编辑  收藏  举报