事后诸葛亮

前言

• 为什么我们要事后诸葛？戳这里告诉你答案！

• 队名：PMS

• | 组长|成员 |

  |-------|-------------|

  | ★ | 530 雨勤 |

  | | 311 旭 |

  | | 403 俊 |

  | | 223 元 |

  | | 437 海辉 |

设想和目标

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

  • 软件开发旨在解决简单监控场景下，人工监测人车流量费时费力且效率低下的问题
  • 典型用户：校方、园区管理者等
  • 典型场景：校园、园区、商场等

• 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?

  • 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）每隔一段时间，团队会反省如何才能更好的进行工作，并相应做出调整。我们团队在初期遇到很大的问题，进度很慢，我们在咨询了导师，自我沟通后做出了调整，使项目能正常进行。

照片君