事后诸葛亮

前言

设想和目标

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

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

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

    • 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)  编辑  收藏  举报