Beta 阶段总结与反思
本部分的反思采取Q&A的形式，在 alpha 阶段总结的基础上结合 beta 阶段的特点对这篇博客中列举的问题进行了一一回答，从而对本团队在 beta 阶段所取得的成果以及不足进行系统的反思与梳理。
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要解决用户在短时间内需要大量背单词，且传统的背单词APP无法帮助其实现长久记忆，纸质书又显得过于笨重不够灵活的问题。
我们将以”记忆宫殿“为理论基础的A4纸背单词法在PC端进行了实现，创新式提出了『词图』概念，旨在赋予单词更丰富的环境信息，促进用户对单词的记忆，更多软件定位请见NABCD文档。
对于典型用户和用户场景的详细说明请见功能规格说明书的用户和典型场景部分。区别于目前多种手机背单词软件的碎片化背词用户，我们的主要受众是需要在一段时间内专门背单词的用户群体，如正在准备四六级、托福、雅思等英语考试的而需要专门背单词的人群。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
根据 beta 阶段项目发布文档的用户典型场景满足情况分析，我们已经成功实现了计划的全部功能，并且根据燃尽图，成功在原计划交付时间交付了产品。
对于用户数量，截至6月24日，我们已达到了计划阶段功能目标的保守总用户量（300），而日活用户数虽然超过了 alpha 阶段的标准，但距原计划中 beta 阶段的日活数仍有一定差距，仍然具有很大的改进空间。具体反思请见下文。
用户量，用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
综合考虑本软件的性质以及 beta 阶段的宣传力度，用户量与预想基本一致。
根据项目发布文档的用户反馈部分，可以看出用户对目前基本功能的可用性和完成度基本持肯定态度。但是由于PC端的使用和注册流程相对不便，以及本软件整体上处于初创阶段，因此用户社区的活跃度距离预期目标还是有一定距离。具体反思请见下文。
有什么经验教训? 如果历史重来一遍,我们会做什么改进?
在 beta 阶段，我们加大了宣发的力度，扩大了宣传口径，除了在pyq等私人渠道进行宣传外，我们还通过b站对外进行公开推广，并取得了很理想的效果。
但另一方面，由于本项目的理念整体上比较新，并且与传统的背单词软件之间有较大的差别优势，因此对于普通用户而言可能需要一定的接受成本，这主要体现在A4纸背词法的理念还需进一步加以推广普及，以及用户对于使用PC背单词的接受程度等方面。
计划
我们有足够的资源来完成各项任务么
- 人力资源：由于本项目的开发难度较大，预期实现的功能较多，并且市面上目前没有可以参考的类似软件，因此总任务量较为繁重。但是，通过合理的分配团队成员的任务，我们充分发挥了所有队员的技术优势，尽最大可能完成了alpha、beta阶段的功能开发与宣传等任务。
- 服务器资源：目前我们购买的服务器能满足项目基本的需求，但是由于本软件还涉及多种图片上传加载的操作，对网络带宽和存储资源的要求较大。目前，本团队采用了折中的方案暂时地缓和了这一问题，但要想进一步进行优化，则在服务器上仍有较大的改进升级空间。
- 宣传资源：本项目通过 b站、校内学生微信群等渠道进行宣传，与专业的团队相比，仍有较大的差距，具体表现在目标受众地针对性可能还不够强等。
各项任务所需的时间和其他资源是如何估计的，精度如何?
我们根据预估的任务量大小和难度对每一个任务进行所需要的时间预期安排，并且在石墨文档中进行了详细的列举和记录。当队员开始做任务时，我们将根据任务的实际情况对预期时长进行微调。所有任务精度控制在工作时间8h以内。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
beta 阶段在力所能及的范围内进行了最充分的单元测试、用户场景测试和压力测试。对于前端主页、教程等美工设计，我们成功预期了其难度，并且分配专人攻克美工问题，最终取得了比较满意的 UI 效果。
你有没有感到你做的事情可以让别人来做（更有效率）?
在前期功能模块开发阶段，由于团队内部的充分沟通和合理的任务划分，每位队员都领到了自己擅长的任务，可以说将每个人的优势都发挥了出来。在后期集成部分，各任务之间具有一定的交叉，我们预期到类似问题的发生，并决定在后期采用集体线下开发的方式，遇到问题及时寻找专人解决，因此开发效率较高。
有什么经验教训?如果历史重来一遍, 我们会做什么改进?
与 alpha 阶段相比，我们团队在 beta 阶段的表现要更为成熟，成员之间的配合也更加默契，在宣发方面也尽最大程度做到了最好。如果要重来一遍的话，或许我们会在 beta 阶段前期制定更加明确的开发计划，对于一些当时不确定性较大的功能如微信登录、图片上传等进行尽早的攻关，从而使得整体的开发流程更加流畅顺利。
变更管理
每个相关的员工都及时知道了变更的消息?
由于我们所有的小组会议和后期开发冲刺阶段全部全员线下进行，因此每一个变更都能及时传达给团队成员。另外，我们使用了”看板法”对任务进行了列表和汇总，完成后划去，清晰且高效。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
对于必须实现的功能，我们通过收集 alpha 阶段的用户反馈，并结合我们对于 beta 阶段的预期计划，在力所能及的情况下均对其加以实现，如用户社区、词图克隆、词图自定义等。
对于需要推迟的功能，我们主要是基于当前团队总体的客观条件限制，如服务器资源、资金预算等，对于需要时间周期较长、且有额外资金投入的功能想尽办法予以替换，如微信登录、图片上传等。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 功能方面：
- 完成所有的预期任务，且所有功能均能通过测试，无明显bug
- 被使用概率较高的核心功能要达到较高的完成度，保证无较大差错。
- UI设计方面：
- 主页足够美观和大气，能够抓住用户眼球。
- 具有详细的教程，并且教程入口伴随用户使用全过程。
- 各页面整体衔接流畅、风格统一。
- 系统方面：
- 用户使用流畅，各请求不能有过长的等待时间。
- 能保证用户信息安全和数据库数据安全。
对于可能的变更是否能制定应急计划?
- 将最核心的功能放在优先级较高的位置实现。
- 对于功能实现要求的修改，集中在发布前1天及之前进行。发布临头时不对核心功能进行大幅度修改，防止翻车。
- 对于会议的流程进行详细记录，使用 GitLab、石墨文档等对进展进行记录，规范编码的格式和注释等，预备人员变更问题。
员工是否能够有效地处理意料之外的工作请求？
首先，本团队队员具有较强的学习能力和责任心，对于意料之外的需求，大多能够及时进行技术栈的补充并尽快完成。另外，本团队具有较强的机动性，两名后端和四名前端之间对接密切，当某一队员出现特殊情况时，其他队员能做到接手其工作并继续开发。
我们学到了什么，如果历史重来一遍，我们会做什么改进？
首先，我们意识到了良好的代码风格和规范的注释的重要性，它能帮助其他人尽快了解模块的功能和实现机制，方便进行人员调整时的快速上手，这是我们存在欠缺并且需要改进的关键之一。另外，线下面对面的交流是十分必要的，能够具有更高效的开发效率和更充分的交流。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
总体的设计工作和大方面的把控在 beta 阶段开始前的集体大会上，由组内成员通过充分讨论、并由PM进行最终确定。
各功能进一步的细节设计则交由相关的开发人员实现。
结果证明，这一任务分配方案是最为合理的。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在开发的前期情况较少，由于时间充分，队员都对功能或界面的实现给予最高要求。但是到开发后期，由于时间紧迫且任务较重，对于部分优先级较低的任务，团队商讨后允许对某些任务的完成质量要求暂时放低，并且对改任务的预期质量进行了完整的记录，待后期补全。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
后端使用了单元测试，但并非是TDD开发模式。同时后端也构造了相应的数据模型图，但并非UML。
除此之外，项目整体对于某些用户场景绘制了相应的时序图，以及项目整体的功能架构图。
与项目开始相比，最终的设计结构未出现根本的变化，但在某些细节上略有不同。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
出现bug相对较多的是在适配的时候。由于我们希望我们的软件能够和PC、平板上的不同浏览器环境均能较好地进行适配，因此需要对不同的分辨率、屏幕尺寸均进行相应的考量。但由于我们手头上不存在所有的用户场景对应的基本参数，因此相对而言比较难以进行充分解决。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们在对功能进行测试时对在实现过程中具有一定混乱情况的代码进行了整理，并且前端和后端都使用官方代码规范和代码规整方式。前后端的代码规范要求详见项目发布博客的软件工程。
测试/发布
团队是否有一个测试计划？为什么没有？
有。
是否进行了正式的验收测试？
是。
团队是否有测试工具来帮助测试？
很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
我们在测试时使用了postman、siege等工具进行api和压力测试，并使用django自带单元测试模块进行单元测试。今后计划从以下方面进行自动化改进：
- postman记录请求，方便今后进行自动回归测试
- 继续使用siege进行压力测试，但该软件无法使用自动化实现
- 结合CI/CD实现单元测试的自动化
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们对于服务器的各项负载能力进行了全面的分析和压力测试。我们在gitlab中对api进行了数量级分析，并选取了有代表性的api进行压测。除此之外，我们还对Nginx的最大连接数和负载均衡进行了测试，详细测试记录详见测试报告。
在发布的过程中发现了哪些意外问题？
由于 beta 阶段加入了缓存功能，因此发布时有时会因为缓存未及时更新导致用户侧数据不同步，后已修复。
我们学到了什么?如果重来一遍,我们会做什么改进?
- 将测试的开始时间进一步提前，在关键功能上尝试使用测试驱动开发的方式进行。
- 进一步完善单元测试，并使用CI/CD进行自动化测试。
- 继续使用postman，siege等进行api测试和压力测试。
- 邀请内测人员提前进行功能测试，模拟用户使用情况。
团队的角色，管理，合作
本部分与 alpha 阶段内容基本一致。
团队的每个角色是如何确定的，是不是人尽其才？
本团队采用3名PM统筹方式，其中2名后端PM，1名前端PM，每一项目大型模块都有PM进行规划和管理，以减少PM的工作量和工作粒度。
团队伊始，共有4名后端和2名前端。但是在分析完团队目标需求后，我们认为前端工作量较大，因此其中两名后端人员选择转型为前端，并且在后续的开发中迅速熟悉了前端技术栈且完成了前端的开发工作。
在团队合作方面，本团队始终坚持线下会议，并且在冲刺阶段持续进行线下集体开发方式，组员之间配合默契，关系融洽，为开发营造了愉快的氛围。
团队成员之间有互相帮助么？
由于不同的团队成员都有自己的开发特点，例如：
- 擅长攻克难题
- 擅长做精某个特定功能
- 擅长快速实现基本功能
结合不同组员的特点，我们在开发中不乏互相帮助，并且对帮助的情况进行了记录。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
由于本团队合作氛围较好，大家基本按照预期的计划和PM的规划完成任务，在项目管理方面比较顺利。在合作中，有时会出现部分功能实现不匹配等问题，前后端进展不一致相互等待等问题，例如api文档确定时间较晚等问题。
针对以上问题的解决，我们在统一线下开发时对冲突部分进行了融合，并且使用特定issue关联api文档的问题集中汇总api文档的改动，从而化解合作上的不一致问题。
总结
本部分与 alpha 阶段内容基本一致。
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
目前团队正在丰富软件功能并完善已完成功能，处于CMM的已管理级(Managed)阶段和CMMl三级，明确级。
你觉得团队目前处于萌芽/磨合/规范/创造 阶段的哪一个阶段?
目前团队处于创造阶段。
你觉得目前最需要改进的一个方面是什么?
目前最需要改进的方面是宣传力度和测试力度。具体改进方案前文已经叙述。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
| 原则 | 完成质量（1~10） |
|---|---|
| 尽早和持续第交付有价值的软件来满足客户 | 8 |
| 欢迎对需求提出变更 | 6 |
| 要不断交付可用的软件 | 8 |
| 项目过程中，业务人员与开发人员必须在一起 | 8 |
| 要善于激励项目人员 | 9 |
| 最有效的沟通方法是面对面的交谈 | 9 |
| 可用的软件是衡量进度的主要指标 | 9 |
| 提倡可持续的开发 | 8 |
| 对技术的精益求精以及对设计的不断完善将提升敏捷性 | 7 |
| 要做到简洁，尽可能减少不必要的工作 | 8 |
| 最佳的架构，需求和设计出自于自组织的团队 | 7 |
| 团队要定期反省如何能够做到更有效，并相应调整团队的行为 | 8 |
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
- 补充代码注释
- 进一步规范新建文件目录树
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
前端让每个组件的功能明确，可能多次出现的组件使用统一组件，提高前端的性能。
后端规范api的实现方式和报错代码的含义。
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
计划增加每个用户的停留时间和用户留存量的记录。
项目文档的质量如何提高？
3名PM合作完成需要发布的文档，3名组员帮忙准备展示视频、测试功能等素材。
对于人的领导和管理， 有什么具体可以改进的地方
- 需要及时进行激励，并且拥有完备的激励机制
- 需要制定有规律的会议方式
- 队长记得以后继续请吃饭
对于软件工程的理论，规律有什么心得体会或不同意见？
- 在计划阶段进行完整的设计可以帮助推进后期开发方向
- 计划阶段对项目进展的规划和实际进展有一定偏差，需要及时进行调整
- 对于api文档、测试等计划需要提前进行规范，提前开始工作
最后附上本团队 beta 阶段最后一次（也是唯一一次线上）的会议截图一张：
