事后诸葛亮

前言


设想和目标

  • 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?

    • 软件开发旨在解决简单监控场景下,人工监测人车流量费时费力且效率低下的问题
    • 典型用户:校方、园区管理者等
    • 典型场景:校园、园区、商场等
  • 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?

    • Alpha阶段核心部分完成,但最终目标未能圆满达成
    • | | 原计划完成 | 实际完成 | 未完成的原因 |
      |-------|-------------------------------------------|-------------------------------------------------------------------------------------------------------|--------------------|
      | √ | 简单场景下,车辆检测与追踪 | 非密集无遮蔽场景下,准确率98.05%;密集有遮蔽场景下,准确率66.67% | |
      | √ | 简单场景下,行人检测与追踪 | 非密集无遮蔽场景下,准确率95.45%;密集有遮蔽场景下,准确率70% | |
      | √ | 热力显示 | 单一颜色叠加的表示区域流量密度 | |
      | | PC端桌面界面,及与模块对接 | 具备基本跳转、能够调用视频 | 了解全新的界面知识,不明确 |
      | | 视频摘要 | 背景分离、视频切割 | 时间问题未完成后半部分,不利于展示 |
  • 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

    • 教训:设计阶段没有做好文档工作,导致后期对接工作难做
    • 改进:重视设计,做好文档

计划

  • 是否有充足的时间来做计划?

    • 由于教学计划变动,原项目整体计划受到较大影响,前期框架尚未确定的情况下进入Alpha冲刺,总体上十分匆忙,经历实际短促但内心煎熬的算法确立阶段后,为赶进度盲目地进入代码阶段,很多文档借口问题没有妥善计划,导致最终整合收尾阶段出现较大问题
  • 团队在计划阶段是如何解决同事们对于计划的不同意见的?

    • 众志成城,没有意见
  • 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?

    • 工作计划完成度见上文表格,未能完成的原因如下:
    • 时间

      • 冲刺阶段提前,很多前期准备还没做好
      • 其他课程安排、电工实习、期末考试等等因素,横向看每个小组都面临着同样的问题,但纵向看确确实实的影响着项目进度与质量
    • 算法

      • 我们的项目以算法为驱动,在算法方案确定前我们的项目推进都是停滞的
    • 语言

      • 组内大佬速成QT、Python
      • 不同语言的对接是另一阻塞项目进度的重要原因
    • 设计

      • 一开始突然进入alpha冲刺,受到核心算法未成型的瓶颈制约,而后急急忙忙进入编码阶段,对于接口、文档没有认真的考量,导致最终进入对接阶段部分代码需要重构
  • 有没有发现你做了一些事后看来没必要或没多大价值的事?

    • 雨勤

      • 人车模块最终使用了相同的架构去实现,两模块工作内容重合大,其实可以进行模块合并
      • 冲刺到凌晨发疯打游戏——死神VS火影
      • 在MFC与QT之间纠结,浪费了很多时间
      • 和 @旭 一起肝到凌晨发疯,对打游戏
  • 是否每一项任务都有清楚定义和衡量的交付件?

    • 没有
    • 这一项确实疏忽了,由于每个成员所负责的模块都相对独立,所以计划上只要求当前事项完成后能够交付可对接的完整模块,而没有对每一项细节任务都做出交付件要求
  • 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?

    • 并非完全按照计划进行
    • 原计划Alpha冲刺就是单纯的编码实现,其他任务应在此之前完成,但受教学计划变更,包括框架搭建、算法设计的内容也纳入到Alpha冲刺阶段中,时间上比较紧张。由于项目主要依靠算法驱动,冲刺头几天算法未成型,进度完全停滞
    • 上述问题即技术开发风险
    • 因为接口文档没有设计好,使得对接时,出现了很大的问题,到现在还存在一定的困难。
  • 在计划中有没有留下缓冲区,缓冲区有作用么?

    • 没有缓冲区,前期进展缓慢,后期百米冲刺。
  • 将来的计划会做什么修改?(例如:缓冲区的定义,加班)

    • 将数据形成输出报告
    • 从监控场景中提取其他交通参数,如:速率等
  • 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

    • 雨勤

      • 学会了基于Blob框架的运动目标的提取检测与追踪
      • 改进:训练分类器,更加明确行人、汽车、电动、自行车的分类
      • 如果能重来,我们就不会选实验班,如果不选实验班,就不用选软工实践,如果要在这个选择上加一个期限,我希望是一辈子
      • 如果能从来,你将看不到这篇博客里关于我的内容。
      • 把Python改成C++吧
    • 海辉

      • 如果给我一次可以重新选择的机会,老师你可能就看不到我了

资源

  • 我们有足够的资源来完成各项任务么?

    • 时间

      • 显然不够
    • 算法、论文与代码

      • 网上有较多的相关资源,部分资源通过FQ也可获得
  • 各项任务所需的时间和其他资源是如何估计的,精度如何?

    • 一项任务所需时间参照模块实现难度、已有资源多寡、需要重新学习的内容多寡来估计
    • 精度上存在较大误差,有一些难以排除的bug和其他人为因素会对之产生干扰
  • 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

    • 测试的主要问题在于资源,我们的产品需要大量视频资源才能验证准确率和识别速度,但网上获得的视频大多只能适应初期调试,进入认真的测试阶段后就需要我们自行采集视频,并进行实地测试
  • 你有没有感到你做的事情可以让别人来做(更有效率)?

    • 雨勤

      • 之前在校园内兜了一圈找场景拍视频,后来发现我的是渣手机并不能对焦到足够测试的画面,拍进来无数无效内容,手抖的也厉害,这方面应该交给专业人士 @俊
      • 没有,舍我其谁,我**无所不能。
      • 没有,舍我其谁,我**无所不能。
      • 没有,舍我其谁,我**无所不能。
    • 海辉

      • 没有,舍我其谁,我**无所不能。(组长没有队形)
  • 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

    • 雨勤

      • 永远要把下一秒当成Deadline来对待才能让自己在真正的Deadline到来时更加从容
      • 一定要尝试在国外的网站去找资料,才能比较有效率。
      • UI的知识应该从开始就学,不应该到时间了开始,比较难。
      • Python改c++
    • 海辉

      • 一定要参加会议,不能再缺席了。

变更管理

  • 每个相关的员工都及时知道了变更的消息?

    • 每晚有站立会议,群内交流也比较及时
  • 我们采用了什么办法决定“推迟”和“必须实现”的功能?

    • 必须实现:核心功能
    • 推迟实现:锦上添花的功能、因为种种原因无法在计划内完成的功能
  • 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?

    • Alpha版验收标准
      • 人车检测与追踪:简单监控场景下,非密集无遮蔽的情形,准确率大于90%;密集有遮蔽的情形,准确率大于70%
      • 视频摘要:错误率(漏检、错检)低于10%
      • 热力显示:弥补在人流量、车流量大的情况下的准确率。
      • 图形界面:具备与原型相似的UI
  • 对于可能的变更是否能制定应急计划?

    • 可以
  • 组员是否能够有效地处理意料之外的工作请求?


设计/实现

  • 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?

    • 所有组员共同参与,所有集思广益,一人操刀规整
  • 设计工作有没有碰到模棱两可的情况,团队是如何解决的?

    • 没有。我们的模块分工明确,模块之间耦合较小
  • 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么? 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?

    • 使用了UML来辅助设计实现
    • 因为UML,使得我们对代码编写时的模块有更加清晰的认识。
    • UML文档相对发生改变,由于视频摘要和热力显示使用了OpenCV内嵌的检测算法,消除了对人车检测模块的依赖,准确率相对下降,但大幅提高了检测速度,而小幅影响此模块的效果
  • 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

    • 界面对接Bug
    • 对人车的分类方法还不完善
    • 由于大家都是DoingByLearning,很多问题在前期不能预见
  • 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

    • Alpha阶段以最小可用为实现目标,未进行代码复审
    • 没有做好文档工作,代码规范不存在的

测试/发布

  • 团队是否有一个测试计划?为什么没有?

    • 人工+程序的测试方案
    • 测试数据集来自组内成员到各场景人工采集
  • 是否进行了正式的验收测试?

    • 已经进行,但测试数据量较小,还需进一步测试
  • 团队是否有测试工具来帮助测试?

    • 为了对比人工和程序检测的效果差别,采用人工检验每个视频数据的正确率
  • 在发布的过程中发现了哪些意外问题?

    • 没有完成界面对接,Alpha版发布的仍是控制台程序

团队的角色,管理,合作

  • 团队的每个角色是如何确定的,是不是人尽其才?

    • @俊负责一切面子工程
    • 由假期已接触OpenCV @勤 @旭 @辉 完成核心功能
    • 由 @元 完成热力图显示功能
    • 在功能分配上,每个人都负责自己比较擅长的功能,算是人尽其才。
  • 团队成员之间有互相帮助么?

    • 有,大家在项目的进展中,无论是在技术还是生活中都互相帮助,相亲相爱。
  • 当出现项目管理、合作方面的问题时,团队成员如何解决问题?

    • 听组长的。
  • 每个成员明确公开地表示对成员帮助的感谢 (并且写在各自的博客里):

    • 我感谢 @大家 对我的帮助, 因为他们没有因为我不在而嫌弃我。

总结:

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

    • 首先我们查了查什么是CMM/CMMI,根据我们的理解我们达不到CMM的层次,我们应该整处于CMMI的低级层次。
  • 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

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

    • 相较于之前的团队创立之初的迷茫,现如今大家都趋于对技术、团队合作的熟悉,更加遵守团队计划。
  • 你觉得目前最需要改进的一个方面是什么?

    • 时间利用,我们团队在时间利用上存在较大的问题,每次都会在趋于deadline时还有一部分工作没有完成,希望能在今后改进!
  • 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

    • (1)围绕有积极性的个人构建项目,给予他所需的环境和支持。在针对Alpha版本的对接工作中,小组成员尽力帮助 @俊 完成界面与程序的对接,包括学习QT等
    • (2)最富有效率的是,面对面交谈。我们小组每天晚上都会进行面对面的站立式会议,并在平常经常面对面沟通项目的进展等。、
    • (3)每隔一段时间,团队会反省如何才能更好的进行工作,并相应做出调整。我们团队在初期遇到很大的问题,进度很慢,我们在咨询了导师,自我沟通后做出了调整,使项目能正常进行。

照片君

posted @ 2017-11-19 21:02  辉哥110  阅读(219)  评论(2编辑  收藏  举报