Alpha事后分析

设想和目标

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

我们的软件的功能主要是让一些基于表单识别的项目（如微软智能表单识别项目）减少在数据生成方面上浪费的时间。定义的比较清楚，对于典型用户和典型场景的描述较为清晰。
具体来说，当一个项目需要用大量的人力来完成数据生成工作的时候，就可以用到我们的项目，不仅方便快捷，还能减少人力财力的浪费。具体见功能规格说明书

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

alpha阶段我们的目标是实现一个最小可用版本，即支持简单的表单生成。经过两周的学习和代码编写、一周的测试和稳定，我们基本完成了原计划的功能。
按照原定计划进行交付，用户数量基本上差不太多。

反思：由于我们的项目的主要受众并不是学生群体，而我们在短时间内也只能在学生群体内进行宣传，所以宣传效果并不是很好。

3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

无上一阶段。

4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

预计的用户数量是100左右，生成的表单数量约在400个左右。
由于我们的项目受众并不是学生群体，而我们目前在短期时间内只能向同学们推广，因此软件的预期下载量很可能并不能达到相应的标准。
但值得欣慰的是，截止5月5日21：15，我们的项目创建数量达到了94个，generate的次数达到了339，除去我们的测试数据，也比较可观，这说明我们基本上完成了预期。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

本阶段做的还算不错，改进的话大概是再早一点明确目标吧，这样会留下不少时间的缓冲期。

计划

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

有充足的时间来做计划，并在开发过程中微调。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

计划的产生本身是由全体团队成员一起讨论得出的，每次的例会上大家都会商讨接下来的方向，由于实现功能较简单，目前并没有不同意见。

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

基本上完成了，在某些方面可能并不是做的尽善尽美，但基本上达到了alpha阶段的原定计划目标。

4. 有没有发现你做了一些事后看来没必要或没多大价值的事?

姓名的生成部分在起初统计了近年来的新生儿数据，比较繁琐还没太大的用处，后期舍弃了。

5. 是否每一项任务都有清楚定义和衡量的交付件?

交付件：

• PM：博客、issue
• 后端：可以提供给前端的接口
• 前端：可以提供给用户的界面

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

基本上按照计划进行。
小意外：
由于我们的项目受众并不是普通学生，因此在宣传发布时出现了一些意外，即用户量比较少。但我们随即加大了推广的力度，推（强）荐（迫）身边的朋友使用了我们的软件，收到的反响还是不错的。

7. 在计划中有没有留下缓冲区，缓冲区有作用么?

Alpha阶段的计划中没有明确的缓冲区。但开发按部就班的进行，没有出现延期的情况。

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

beta阶段会完善alpha阶段的交互速度，并进行新功能的扩展。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

model页面没用到，这应该算是在计划方面比较大的问题，值得重新考虑一下alpha阶段的最初预期。其次，由于我们比较信任微软的代码质量，忽略了我们接手的是一个还在开发和完善中的项目，因此没有计划修复和细致测试原项目中已经存在的bug，干扰了后期测试时对bug的定位和修复。

资源

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

暂时足够，但由于今年的课程比较特殊，线上联系并没有线下联系效率高。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

各项所需时间估计基本准确。数据生成上花费的时间比较多，由于服务器起初是在国外，导致访问速度非常慢，也对我们的用户造成了影响。

3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试的时间，人力和软硬件资源足够，美工方面并不需要大费周折，但还是出现了一点点小的插曲。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

如果重来一遍我们会仔细思考在数据生成方面所使用的方法，另外也会尽早地布置好服务器。

变更管理

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

是。当有重大变化会及时通过微信进行通知，即使没有及时查看微信，至少每天的例会上也会当面讲清楚。但其实变更并不多。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

基本可使用功能最小集为“必须实现”功能，其余都归类在“推迟”功能里。

3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

有，完成最小可用版本即为出口条件，详见发布声明

4. 对于可能的变更是否能制定应急计划?

当一个比较复杂的功能无法立即实现，且不属于最小可用版本的必要功能时，在例会上就会将其作为可推迟的功能，将该功能优先级降低。

5. 员工是否能够有效地处理意料之外的工作请求？

能。最初并没有计划增加上传空白PDF的功能，随着测试的进行发现了这一问题，最终也顺利的解决了。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

model页面的推迟方面，我们可能在一开始就将其放入beta阶段；生成的字体方面，由于最初出现了莫名其妙的bug，导致暂时推迟了手写字体的生成，改成了打印字体，但是后期bug又消失了，又改了回来，浪费了一些时间，如果重来，我们可能会先不考虑手写字体，将打印字体做好后在实现手写字体。

设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作在项目冲刺开始前，由大家自由选择的，是合适的时间。开发主要分成了前端和后端两个方向，相关技术基本上大家都没接触过，因此难以评价是否是合适的人。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有。因为在任务发布时只是将任务的名称发出，具体实现方法和内容并没有明确，此时会在团队例会上解决或由PM协调。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

数据生成方面产生了很多bug，例如生成的文字是反的等等，后期进行了分类讨论，做出了修改。
因为我们在开发的时候真的就没有想到这些情况

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

利用github复审，当前端某一个页面的代码写完时，会push到github上，然后由负责merge的同学进行复审。代码规范也是严格遵守pylint的规定进行编写。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

在tag页面标注方面，我们现在实现的时点一次按键传一次请求，效果并不是很好，重来的话会做成一次传递多个请求的方式。

测试/发布

1. 团队是否有一个测试计划？为什么没有？

有，见测试分析

2. 是否进行了正式的验收测试？

是，（功能规格说明书、整体测试、测试计划）

3. 团队是否有测试工具来帮助测试？

postman测试驱动开发

开发环境：使用VS Code和Azure Functions开发http响应函数，构建后端http服务器。
测试工具：Postman。
开发过程前端的请求由Postman模拟，对后端进行测试，整体上采用测试驱动开发的方式，根据Postman的测试请求来开发完善http服务器功能。

举个例子

生成请求：是GET请求，没必要是POST，参数需要携带项目路径信息。

后端基于此请求开发生成模块，接受请求后解析路径，将路径中对应的项目文件取出来，运行数据生成模块，将生成的文件存放回对应的路径。

4. 团队是如何测量并跟踪软件的效能的？

自己先做使用测试、压力测试等。然后通过用户的反馈不断地进行完善。

5. 在发布的过程中发现了哪些意外问题？

由于服务器问题引发的访问慢，让用户体验较差并进行了反馈。

我们学到了什么? 如果重来一遍, 我们会做什么改进?

完善测试计划、并设计好缓冲区

团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

是在开会的时候自由选择的，现在来看还是可以称得上是人尽其才的。

2. 团队成员之间有互相帮助么？

有

成员	感谢信
ly	在本次团队作业中，合作很愉快。为了制作展示视频，我写了初稿，tzj和dxy帮助进行了修改和润色。llj帮助进行了视频录制和配音小伙伴邀请等。在测试对接后的前后端时，tzj多次帮助我测试整体项目，反馈错误和体验效果，帮助我修改了很多Bug。整合后端代码的时候，dxy同学辅助我更改代码，变更需求，不断迭代后端代码。技术上，整体思路是zyc同学提供，是我们小组的希望之花！最后感谢一下PM wyk的辛苦付出！
llj	感谢tzj同学对我的帮助，在开发前期帮助我厘清前端源代码结构，详略得当，在具体的功能实现中也提出了很有参考价值的建议；感谢zyc同学对我的帮助，为我提供了很多技术上的指导，总是很耐心地帮助我解决问题，也让我学习到了很多；感谢ly同学，活跃度up up！在后端部署和前后端对接的时候积极严谨，效率也超高！感谢dxy同学，项目的核心功能代码实现👍，后期功能不断迭代改进和修改bug高效认真，从不敷衍；感谢wyk同学，每天尽职的组织例会发布博客，灵活管理工作内容，保证项目按进度推进，确保工作中问题的及时解决以及团队的有效沟通，在答辩中也很赞！给大家撒花！！！
dxy	感谢wyk，尽职尽责当pm，感谢ly，为项目调度操心，感谢zyc，为项目解决重大难题，感谢tzj，在前端尽职尽责，感谢llj，生病依然坚持
wyk	感谢zyc同学在前期帮我搞定了github上的issue问题，ly、tzj同学在发布期间对软件的不断测试与完善，llj、dxy同学的代码编写及视频制作……感谢大家的积极性
tzj	感谢zyc对我的帮助，因为前端用到的一些代码规范化工具、单元测试工具等等都是他介绍给我的，让我省去了很多查找相关内容的时间，还有一些技术难题也都是他指导解决的；感谢ly对我的帮助， 因为端对端测试的时候，他帮助我测出了很多bug，让我能尽快的修改，而且团队交流中也经常和我一起讨论问题和前后端交接情况；感谢llj对我的帮助，因为在实现前端图标的时候，她帮助我梳理清了原项目中有关图标使用的代码结构，并且一起讨论了一些功能设计相关的问题；感谢wyk对我的帮助，因为他为我们团队组织会议，记录我们的工作进度，及时让团队中的问题得到讨论和交流。我感谢dxy对我的帮助，因为他为我解释了后端是相应的功能比如生成pdf的实现，让我更好的理解整个项目的工作流程。
zyc	感谢ly的帮助，在前后端对接中做了许多工作。

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

每日例会上大家都会进行交流，基本上当天出现的问题很快就能够得到解决。

总结:

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

我觉得团队目前处于管理级。我们对各自的分工十分明确，又统一清楚的认识；任务issues管理、每日例会以及燃尽图的管理，相对来说也比较细致。

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

介于磨合和规范之间，即将进入规范阶段。

你觉得目前最需要改进的一个方面是什么?

在签入代码方面做好约定；尽早明确alpha阶段目标，以留出缓冲期。

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

尽早并持续地交付有价值的软件以满足顾客需求，我们在alpha阶段预期的实现较为困难时，我们做出了取舍，完成了最小可用版本的开发。

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

代码要保质保量，定期进行代码复审。
加大测试力度，减少bug出现的可能性。

讨论截图