事后总结
NameNotFound 团队
| 项目 | 内容 |
|---|---|
| 北航-2020-软件工程（春季学期） | 班级博客 |
| 要求 | Beta事后分析 |
| 课程目标 | 通过团队合作完成一个软件项目的开发 |
会议截图
一、设想和目标
软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件要解决的是两个问题：
-
表单数据的生成
在各类表单识别和OCR服务的机器学习模型中，训练数据占据很重要的地位。而真实表单中数据往往涉及用户隐私，不能直接使用，因此需要花费大量的资金和人力伪造一些与真实表单各个字段值相近的“虚假”表单作为训练数据。我们希望能够设计一个表单数据自动化生成工具，它能根据用户提供的空白表单和表单中各个字段的生成要求，自动随机生成多个满足用户要求的标注好的高质量表单，作为训练数据以供各个表单识别项目开发者使用，从而节省花费在训练数据上的人力物力。
-
自动化处理大量表单
微软原项目Fott项目使用认知服务来识别表单。我们基于Alpha阶段的数据生成，进一步把模型训练和使用结合起来，使整个软件有一个完整的流程，即：上传->标注->数据生成->模型训练->表单处理。
基于以上的流程，我们的软件支持用户批量处理同类表单，解决手工处理的麻烦。同时，为了方便用户使用处理结果，我们对处理结果进行了整理，支持结果导出为Excel文件，并且设计了可视化展示的接口，方便用户直观的观察数据。
关于典型用户和典型场景的描述见Beta项目展示
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划的功能如下：
| 功能 | 详细描述 |
|---|---|
| introduction页面 | 增加项目描述和使用方法 |
| train页面 | 支持对生成好的页面进行一键训练；支持将训练得到的结果进行处理，生成Excel文件 |
| data页面 | 支持数据可视化查看 |
| tag页面 | 支持错误画出的框的删除 |
| model页面 | 支持历史模型的显示 |
| new project | 支持用户选择项目类型（空白训练；五张训练；根据Excel信息批量生成表单等） |
原计划的功能除了model页面没有实现，其他的功能均已实现。model页面是因为我们发现这一功能没有需求，所以放弃了这一功能。
我们按照计划交付了软件，并且进行了稳步的测试。
原计划的用户数量并没有达到，可能是以下几个原因：
- 我们的软件对于大家来说需求不是很明显，所以可能大家尝试的意愿不高
- 考虑到临近烤漆，大家都在复习，我们的软件对于复习没有帮助，所以不使用很正常
- 软件本身还是不够吸引人
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
和上一个阶段相比，我们认为团队的软件工程质量有所提高。
- 项目的计划：我们在Beta阶段进行了更详细的规划，冲刺的任务也提前明确
- 项目管理：将issue和commit关联起来，PM进行代码复审
- 成员任务分工：前后端分离，每日例会更新明天的任务
- 文档管理：将说明文档和技术文档都维护在GitHub的wiki页面
整个流程下来，我们的开发速度相比Alpha阶段有了很的提升，这一点在Beta阶段的燃尽图可以体现
燃尽图
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
从用户的反馈来看，用户对于功能的整体还是比较满意，主要的问题可能是软件的使用速度存在一定的问题。这一点在项目展示进行了解释。
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
如果重来，我们会选择自己构建后端服务器，而不是使用Azure的服务。因为Azure的服务在中国还是有一定的延迟。
二、计划
是否有充足的时间来做计划?
我们在Beta阶段是有比较充足的时间进行计划，包括功能以及项目管理等，也正是因为计划较为完善，所以开发速度有了很大的提升。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们会就目前的技术和资源来衡量不同的意见，如果资源和技术可以满足，且时间允许，那么我们会投票接受意见。
如果是成员之间的意见不同，我们也是综合所有人的意见来衡量是否采纳。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作基本都做完了，有一项 model页面 的计划并没有实现，这个是因为我们在开发阶段发现这一功能不视用于需求的，没有特别大的意义，所以没有实现。
有没有发现你做了一些事后看来没必要或没多大价值的事?
这个暂时没有，因为我们会在每日例会进行灵活的调整，没有做可能没有价值的任务。
是否每一项任务都有清楚定义和衡量的交付件?
是的，我们把所有的issue和commit都联合起来，在每日例会也详细描述了每个人每天的工作。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
整个过程基本都是按照计划来的，期间遇到过服务器无法正常使用，这个是因为微软的Azure服务存在一些小问题，是一开始没有预估到的。因为Alpha阶段没有遇到类似的问题，所以没有预估到这一问题。
在计划中有没有留下缓冲区，缓冲区有作用么?
计划中有留有一定的缓冲区。缓冲区是为了防止因为各种问题导致的项目进度推迟，实际的项目过程，缓冲区还是起到了一定的作用，我们本来计划的开发完成时间是早于冲刺结束时间的，结果是正好完成。这期间是服务器和技术都遇到了一些小问题。
将来的计划会做什么修改？
缓冲区确实应该在计划中考虑，以防出现意外情况导致项目进度被搁置；
如果按照当前计划无法在时间点完成，那么加班是有必要的。
我们学到了什么? 如果历史重来一遍，我们会做什么改进?
我们会在计划阶段进一步明确每个人的分工，并且让大家明白彼此工作之间的联系，结合结对开发的模式，两两组队开发。出现问题，PM尽快调控解决。
三、资源
我们有足够的资源来完成各项任务么?
资源方面，我们的服务器是zyc同学提供的，基本可以满足我们的项目需求；唯一的问题是账号资源，因为微软的Azure服务需要使用Visa卡才可以注册账号使用，我们只有一个账号，因此很多的功能其实都是进行了修改才能够让更多的人使用，尤其是认知服务的免费版本有次数限制，导致我们无法进行大规模的测试。
各项任务所需的时间和其他资源是如何估计的，精度如何?
任务的时间基本上是按照每个任务1-2天，然后在每日例会上进行调整；
除了几个维护的任务，开发任务基本上是在估计时间内的，还是比较准确。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间较为充足，因为我们按照预期完成了开发。
人力资源和硬件资源足够。
一定程度上低估了难度，尤其是文档和博客等，需要描述的很多，耗费的时间很大。
你有没有感到你做的事情可以让别人来做?
Beta阶段我是转为了PM，整个流程下来，感觉PM首先要对项目有一个整体的了解，以及明确项目的方向，合理的分工，推进项目进度。这一工作，其他成员应该也可以胜任，只是需要花费一些时间熟悉。
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
可能我们会选择采用自己搭建服务器的方式来构建前后端，这样消耗的资源也差不多，但是软件的整体性会更好，性能会有很大的改善。
四、变更管理
每个相关的员工都及时知道了变更的消息?
我们会在交流群及时通知各种消息，然后GitHub上也会对push等由邮件提醒。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
民主集中制？