Alpha 阶段总结与反思

本部分的反思采取 Q&A 的形式，对这篇博客中列举的问题进行了一一回答，从而对本团队在 Alpha 阶段所取得的成果以及不足进行系统的反思与梳理。

设想和目标

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

我们的软件主要解决用户在短时间内需要大量背单词，且传统的背单词 APP 无法帮助其实现长久记忆，纸质书又显得过于笨重不够灵活的问题。

我们将以”记忆宫殿“为理论基础的 A4 纸背单词法在 PC 端进行了实现，创新式提出了『词图』概念，旨在赋予单词更丰富的环境信息，促进用户对单词的记忆，更多软件定位请见 NABCD 文档。

对于典型用户和用户场景的详细说明请见功能规格说明书的用户和典型场景部分。区别于目前多种手机背单词软件的碎片化背词用户，我们的主要受众是需要在一段时间内专门背单词的用户群体，如正在准备四六级、托福、雅思等英语考试的而需要专门背单词的人群。

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

根据项目发布文档的用户典型场景满足情况分析，我们已经成功实现了 Alpha 阶段计划的全部功能，并且根据燃尽图，成功在原计划交付时间交付了产品。

对于用户数量，我们达到了计划阶段功能目标的保守总用户量和日活用户量，但是和理想情况差距较大，仍然具有很大的改进空间。具体反思请见下文。

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

综合考虑本软件的性质以及 Alpha 阶段的宣传力度，用户量与预想基本一致。

根据项目发布文档的用户反馈部分，可以看出用户对目前基本功能的可用性和完成度基本持肯定态度。但是由于 A4 纸背单词法的理念普及度不够，教程的引导性不足，加之 PC 端的使用和注册流程相对不便，因此用户对本软件核心功能的接受程度较低，大部分用户需要花费一定的时间才能上手。具体反思请见下文。

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

可以说，用户量和用户的接受程度是本项目 Alpha 阶段最严重的问题。因此，团队在此进行详细的反思总结：

遇到的问题	问题产生原因	改进方案
用户注册总量较少	PC 端操作不便、邮件注册不变	争取支持更高效的注册方式
用户登录后迷茫不知所措	1. 教程仅在主页呈现，没有在用户访问各页面提供更明确的指导。 2. 新用户我的词图界面过于空白。	1. 优化教程的实现方式。 2. 丰富新用户的页面内容
单词认识程度选择后操作不符合用户认知	我们采取了扇贝单词的跳转逻辑，但是从用户反馈看大部分用户对此并不熟悉或较难适应。	Beta 阶段结合大部分用户的使用情况对单词的记忆状态进行进一步改进
词图的部分操作不便。如单词重叠、仅在中间出现等	1. Alpha 阶段主要目标为实现基础功能，对细节的要求较低	Beta 阶段对单词的出现位置进行优化
对词图的部分操作不知所措	工具栏缺少文字解释	添加 tip 等提示引导用户操作
用户和 PC 的交互体现不够充分	1. 目前暂未添加用户搜索单词并添加的功能。 2. 目前暂不支持用户上传头像、图片背景等	对用户主动性操作进行补充和完善
仅 PC 端限制使用场景	目前对平板端的适配存在一些问题	Beta 阶段完善软件对平板的适配问题

以上问题总结了本项目截止到 Alpha 阶段接收到的来自众多用户的评价和建议与所有队员进行集体讨论反思后的成果。其中大部分和团队 Beta 阶段的计划重叠，这也使得我们对 Beta 阶段的开发方向更加明确。在此感谢张少昂助教对我们产品存在的问题所做出的全面透彻的剖析和评价。

计划

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

1. 人力资源：由于本项目的开发难度较大，预期实现的功能较多，并且市面上目前没有可以参考的类似软件，因此总任务量较为繁重。但是，通过合理的分配团队成员的任务，我们充分发挥了所有队员的技术优势，成功完成了 Alpha 阶段的功能开发任务。但相对而言，在宣传上，我们仍处于力不从心的状态。
2. 服务器资源：目前我们购买的服务器基本能满足 Alpha 阶段的需求。但是由于本软件未来将涉及多种图片的操作，对网络带宽的要求较大，因此目前服务器在此方面有一定的压力。在 Beta 阶段，我们将通过限制用户上传的图片体量等方式综合权衡用户体验和服务器负载能力。
3. 宣传资源：由于本项目的面向的受众和北航校内的同学吻合度较低，因此需要能向社会宣传的渠道。但是，目前队员的自身资源不足以让我们获取更好的社会宣传平台。这也是 Beta 阶段我们希望能克服的问题之一。

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

首先，我们根据预估的任务量大小和难度对每一个任务进行所需要的时间预期安排，并且在石墨文档中进行了详细的列举和记录。当队员开始做任务时，我们将根据任务的实际情况对预期时长进行微调。所有任务精度控制在工作时间 8h 以内。

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

由于 Alpha 阶段的开发任务较大，时间较短，因此留给测试的时间和人力资源相对有限，此外我们的数据库本身较大，因此未进行充分的单元测试，这也是 Alpha 阶段存在的不足之一。但在有限的资源下，我们仍进行了全面的压力测试、场景测试、 API 测试等，详见测试文档。对于前端主页、教程等美工设计，我们成功预期了其难度，并且分配专人攻克美工问题，最终取得了比较满意的 UI 效果。

你有没有感到你做的事情可以让别人来做（更有效率）?

在前期功能模块开发阶段，由于团队内部的充分沟通和合理的任务划分，每位队员都领到了自己擅长的任务，可以说将每个人的优势都发挥了出来。在后期集成部分，各任务之间具有一定的交叉，我们预期到类似问题的发生，并决定在后期采用集体线下开发的方式，遇到问题及时寻找专人解决，因此开发效率较高。

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

经过 Alpha 阶段的磨合，我们发现本团队的成员都是闷头开发党，这导致我们的项目功能完成度较高，但是在宣传力度等方面存在较为明显的不足。因此，我们认为应当划分更多的精力在产品的宣传方向，并且及时获取用户反馈并及时修正现有错误。另外，对于测试的进行应当提上日程，防止后期时间较紧而没有时间进行完备的测试。

变更管理

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

由于我们所有的小组会议和后期开发冲刺阶段全部全员线下进行，因此每一个变更都能及时传达给团队成员。另外，我们使用了”看板法”对任务进行了列表和汇总，完成后即使划去，清晰且高效。

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

经过总结，本项目 Alpha 阶段实现的所有功能的分类和大体优先级如下：

1. 涉及初次登陆用户的舒适度的功能为必须实现。
2. 涉及老用户长期使用的舒适度的功能推迟实现
3. 涉及词图核心功能的基本功能必须实现。
4. 涉及词图核心功能的拓展和美化推迟实现

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

• 功能方面：
  • Alpha 计划阶段的所有任务基本完成是出口的底线。
  • 被使用概率较高的核心功能要达到较高的完成度，保证无较大差错。
• UI 方面：
• 主页足够美观和大气，能够抓住用户眼球。
• 具有详细的教程，并且教程入口伴随用户使用全过程。
• 各页面整体衔接流畅、风格统一。
• 系统方面：
  • 用户使用流畅，各请求不能有过长的等待时间。
  • 能保证用户信息安全和数据库数据安全。

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

1. 将最核心的功能放在优先级较高的位置实现。
2. 对于功能实现要求的修改，集中在发布前一天及之前进行。发布临头时不对核心功能进行大幅度修改，防止翻车。
3. 对于会议的流程进行详细记录，使用 Gitlab、石墨文档等对进展进行记录，规范编码的格式和注释等，预备人员变更问题。

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

首先，本团队队员具有较强的学习能力和责任心，对于意料之外的需求，大多能够及时进行技术栈的补充并尽快完成。另外，本团队具有较强的机动性，两名后端和四名前端之间对接密切，当某一队员出现特殊情况时，其他队员能做到接手其工作并继续开发。

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

首先，我们意识到了良好的代码风格和规范的注释的重要性，它能帮助其他人尽快了解模块的功能和实现机制，方便进行人员调整时的快速上手，这是我们存在欠缺并且需要改进的关键之一。另外，线下面对面的交流是十分必要的，能够具有更高效的开发效率和更充分的交流。

设计/实现

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

设计工作在 Alpha 阶段计划阶段系统功能设计已经完成，由本团队的 3 名 PM 领导，全替成员参与设计完成。

从 Alpha 阶段开发结果来看，目前顺利完成了 Alpha 阶段的与其功能，且前端 UI 和原型图设计基本一致，充分证明了前期计划的有效性和准确性。

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

在开发的前期情况较少，由于时间充分，队员都对功能或界面的实现给予最高要求。但是到开发后期，由于时间紧迫且任务较重，对于部分优先级较低的任务，团队商讨后允许对某些任务的完成质量要求暂时放低，并且对改任务的预期质量进行了完整的记录，待后期补全。

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

由于 Alpha 阶段开发时间短，任务重，因此本项目未能进行完备的单元测试和 TDD，而是以功能为单位进行驱动开发。在开发阶段，我们主要使用了 Gitlab 的 milestone、issues 进行任务分配，并且使用石墨文档进行任务记录。在 Alpha 阶段的初期，对 issues 的利用比较生硬，因此效果不佳。后来在团队成员的发掘和助教的提点下，我们采用将 commit 和 issue 进行关联的方式，极大的提高了 issues 的意义和操作的关联度。

至于前后端之间的交流，我们采用 wiki 书写 API 文档和固定 issues 的关联的方式进行交互，效果较好。

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

由于本项目在功能方面要求较高，完成度较高，因此发布后没有出现严重的 bug。目前出现的所有 bug 都集中在前端 UI 界面显示上，其中包括不同浏览器的适配、平板端的适配、分遍率的适配等。详见项目发布的 bug 汇总部分。

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

我们在对功能进行测试时对在实现过程中具有一定混乱情况的代码进行了整理，并且前端和后端都使用官方代码规范和代码规整方式。前后端的代码规范要求详见项目发布博客的软件工程质量部分。

测试/发布

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

团队在 Alpha 阶段有测试计划，但综合考虑时间和人力问题，最终计划进行了简化并进行了初步完成。

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

由于测试几乎在发布前夕统一完成，因此验收测试和软件功能基本测试重合。

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

很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

我们在测试时使用了 postman、siege 等工具进行 API 和压力测试，并使用 Django 自带单元测试模块进行单元测试。今后计划从以下方面进行自动化改进：

• postman记录请求，方便今后进行自动回归测试
• 继续使用siege进行压力测试，但该软件无法使用自动化实现
• 结合CI/CD实现单元测试的自动化

团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

我们对于服务器的各项负载能力进行了全面的分析和压力测试。我们在 [Gitlab](https://gitlab.buaaoo.top/2021_alige_homeworks/group_projects/mei_zi_zi_tian_xi_xi_d UI /backend/wikis/API%E5%8E%8B%E6%B5%8B%E5%88%86%E6%9E%90) 中对 API 进行了数量级分析，并选取了有代表性的 API 进行压测。除此之外，我们还对 Nginx 的最大连接数和负载均衡进行了测试，详细测试记录详见测试报告。

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

在发布当天晚上出现了服务器崩溃问题。后发现这是由于服务器短时间内突然连接数过大导致，和系统负载能力有关。之后通过重启服务解决了此问题。

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

测试方面是本团队 Alpha 阶段相对不够完善的方面，因此我们提出以下改进方案：

• 将测试的开始时间提前，在关键功能上使用测试驱动开发的方式进行。
• 前后端完善单元测试，并使用 CI/CD 进行自动化测试。
• 继续使用 postman，siege 等进行 API 测试和压力测试。
• 邀请内测人员提前进行功能测试，模拟用户使用情况。

团队的角色，管理，合作

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

本团队采用 3 名 PM 统筹方式，其中 2 名后端 PM，1 名前端 PM，每一项目大型模块都有 PM 进行规划和管理，以减少 PM 的工作量和工作粒度。

团队伊始，共有 4 名后端和 2 名前端。但是在分析完团队目标需求后，我们认为前端工作量较大，因此其中两名后端人员选择转型为前端，并且在后续的开发中迅速熟悉了前端技术栈且完成了前端的开发工作。

在团队合作方面，本团队始终坚持线下会议，并且在冲刺阶段持续进行线下集体开发方式，组员之间配合默契，关系融洽，为开发营造了愉快的氛围。

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

由于不同的团队成员都有自己的开发特点，例如：

• 擅长攻克难题
• 擅长做精某个特定功能
• 擅长快速实现基本功能

结合不同组员的特点，我们在开发中不乏互相帮助，并且对帮助的情况进行了记录。

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

由于本团队合作氛围较好，大家基本按照预期的计划和 PM 的规划完成任务，在项目管理方面比较顺利。在合作中，有时会出现部分功能实现不匹配等问题，前后端进展不一致相互等待等问题，例如 API 文档确定时间较晚等问题。

针对以上问题的解决，我们在统一线下开发时对冲突部分进行了融合，并且使用特定 issue 关联 API 文档的问题集中汇总 API 文档的改动，从而化解合作上的不一致问题。

总结

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

目前团队正在丰富软件功能并完善已完成功能，处于 CMM 的已管理级（Managed）阶段和 CMMl 三级，明确级。

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

目前团队处于创造阶段。

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

目前最需要改进的方面是宣传力度和测试力度。具体改进方案前文已经叙述。

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

原则	完成质量（1~10）
尽早和持续第交付有价值的软件来满足客户	8
欢迎对需求提出变更	6
要不断交付可用的软件	8
项目过程中，业务人员与开发人员必须在一起	8
要善于激励项目人员	9
最有效的沟通方法是面对面的交谈	9
可用的软件是衡量进度的主要指标	9
提倡可持续的开发	8
对技术的精益求精以及对设计的不断完善将提升敏捷性	7
要做到简洁，尽可能减少不必要的工作	8
最佳的架构，需求和设计出自于自组织的团队	7
团队要定期反省如何能够做到更有效，并相应调整团队的行为	8

代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

1. 补充代码注释
2. 进一步规范新建文件目录树

整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

前端让每个组件的功能明确，可能多次出现的组件使用统一组件，提高前端的性能。

后端规范 API 的实现方式和报错代码的含义。

项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

计划增加每个用户的停留时间和用户留存量的记录。

项目文档的质量如何提高？

3 名 PM 合作完成需要发布的文档，3 名组员帮忙准备展示视频、测试功能等素材。

对于人的领导和管理， 有什么具体可以改进的地方

1. 需要及时进行激励，并且拥有完备的激励机制
2. 需要制定有规律的会议方式
3. 队长记得请吃饭

对于软件工程的理论，规律有什么心得体会或不同意见？

1. 在计划阶段进行完整的设计可以帮助推进后期开发方向
2. 计划阶段对项目进展的规划和实际进展有一定偏差，需要及时进行调整
3. 对于 API 文档、测试等计划需要提前进行规范，提前开始工作

最后附一张总结反思大会现场照片：