前言
- 为什么我们要事后诸葛？戳这里告诉你答案！
-
队名：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++吧
-
海辉
- 如果给我一次可以重新选择的机会，老师你可能就看不到我了
-
资源
-
我们有足够的资源来完成各项任务么?
-
时间
- 显然不够
-
算法、论文与代码
- 网上有较多的相关资源，部分资源通过翻墙也可获得
-
-
各项任务所需的时间和其他资源是如何估计的，精度如何?
- 一项任务所需时间参照模块实现难度、已有资源多寡、需要重新学习的内容多寡来估计
- 精度上存在较大误差，有一些难以排除的bug和其他人为因素会对之产生干扰
-
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 测试的主要问题在于资源，我们的产品需要大量视频资源才能验证准确率和识别速度，但网上获得的视频大多只能适应初期调试，进入认真的测试阶段后就需要我们自行采集视频，并进行实地测试
-
你有没有感到你做的事情可以让别人来做（更有效率）?
-
雨勤
- 之前在校园内兜了一圈找场景拍视频，后来发现我的是渣手机并不能对焦到足够测试的画面，拍进来无数无效内容，手抖的也厉害，这方面应该交给专业人士 @俊
-
旭
- 没有，舍我其谁，我**无所不能。
-
俊
- 没有，舍我其谁，我**无所不能。
-
元
- 没有，舍我其谁，我**无所不能。
-
海辉
- 没有，舍我其谁，我**无所不能。（组长没有队形）
-
-
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
-
雨勤
- 永远要把下一秒当成Deadline来对待才能让自己在真正的Deadline到来时更加从容
-
旭
- 一定要尝试在国外的网站去找资料，才能比较有效率。
-
俊
- UI的知识应该从一开始就学，不应该到时间了开始，比较难。
-
元
- Python改c++
-
海辉
- 一定要参加会议，不能再缺席了。
-
变更管理
-
每个相关的员工都及时知道了变更的消息?
- 每晚有站立会议，群内交流也比较及时
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 必须实现：核心功能
- 推迟实现：锦上添花的功能、因为种种原因无法在计划内完成的功能
-
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- Alpha版验收标准
- 人车检测与追踪：简单监控场景下，非密集无遮蔽的情形，准确率大于90%；密集有遮蔽的情形，准确率大于70%
- 视频摘要：错误率（漏检、错检）低于10%
- 热力显示：弥补在人流量、车流量大的情况下的准确率。
- 图形界面：具备与原型相似的UI
- Alpha版验收标准
-
对于可能的变更是否能制定应急计划?
- 可以
-
组员是否能够有效地处理意料之外的工作请求？
- 能
设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 所有组员共同参与，所有集思广益，一人操刀规整
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 没有。我们的模块分工明确，模块之间耦合较小
-
团队是否运用单元测试（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）每隔一段时间，团队会反省如何才能更好的进行工作，并相应做出调整。我们团队在初期遇到很大的问题，进度很慢，我们在咨询了导师，自我沟通后做出了调整，使项目能正常进行。
照片君
