Alpha阶段总结与反思
本部分的反思采取 Q&A 的形式，对中列举的问题进⾏了⼀⼀回答，从⽽对本团队在 Alpha 阶段所取得的成果以及不⾜进⾏系统的反思与梳理。
设想和⽬标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型⽤户和典型场景有清晰的描述？
我们的软件主要解决⽤户在短时间内需要⼤量背单词，且传统的背单词 APP ⽆法帮助其实现长久记忆，纸质书⼜显得过于笨重不够灵活的问题。
我们将以”记忆宫殿“为理论基础的 A4 纸背单词法在 PC 端进⾏了实现，创新式提出了『词图』概念，旨在赋予单词更丰富的环境信息，促进⽤户对单词的记忆，更多软件定位请见⽂档。
对于典型⽤户和⽤户场景的详细说明请见功能规格说明书的。区别于⽬前多种⼿机背单词软件的碎⽚化背词⽤户，我们的主要受众是需要在⼀段时间内专门背单词的⽤户体，如正在准备四六级、托福、雅思等英语考试的⽽需要专门背单词的⼈。
我们达到⽬标了么（原计划的功能做到了⼏个？按照原计划交付时间交付了么？原计划达到的⽤户数量达到了么?)
根据的⽤户典型场景满⾜情况分析，我们已经成功实现了 Alpha 阶段计划的全部功能，并且根据燃尽图，成功在原计划交付时间交付了产品。
对于⽤户数量，我们达到了计划阶段的保守总⽤户量和⽇活⽤户量，但是和理想情况差距较⼤，仍然具有很⼤的改进空间。具体反思请见下⽂。
⽤户量, ⽤户对重要功能的接受程度和我们事先的预想⼀致么? 我们离⽬标更近了么?
综合考虑本软件的性质以及 Alpha 阶段的宣传⼒度，⽤户量与预想基本⼀致。
根据的⽤户反馈部分，可以看出⽤户对⽬前基本功能的可⽤性和完成度基本持肯定态度。但是由于 A4 纸背单词法的理念普及度不够，教程的引导性不⾜，加之PC 端的使⽤和注册流程相对不便，因此⽤户对本软件核⼼功能的接受程度较低，⼤部分⽤户需要花费⼀定的时间才能上⼿。具体反思请见下⽂。
有什么经验教训? 如果历史重来⼀遍，我们会做什么改进?
可以说，⽤户量和⽤户的接受程度是本项⽬ Alpha 阶段最严重的问题。因此，团队在此进⾏详细的反思总结：
遇到的问题问题产⽣原因改进⽅案
⽤户注册总量较少PC 端操作不便、邮件注册不变争取⽀持更⾼效的注册⽅式
⽤户登录后迷茫不知所措1. 教程仅在主页呈现，没有在⽤户访问各页⾯提供更明确
的指导。
2. 新⽤户我的词图界⾯过于空⽩。
1. 优化教程的实现⽅式。
2. 丰富新⽤户的页⾯内容
单词认识程度选择后操作不符合⽤户认知我们采取了扇贝单词的跳转逻辑，但是从⽤户反馈看⼤部
分⽤户对此并不熟悉或较难适应。
Beta 阶段结合⼤部分⽤户的使⽤情况对单词
的记忆状态进⾏进⼀步改进
词图的部分操作不便。如单词重叠、仅在中间出现等1. Alpha 阶段主要⽬标为实现基础功能，对细节的要求较
低
Beta 阶段对单词的出现位置进⾏优化
对词图的部分操作不知所措⼯具栏缺少⽂字解释添加 tip 等提⽰引导⽤户操作
⽤户和 PC 的交互体现不够充分1. ⽬前暂未添加⽤户搜索单词并添加的功能。
2. ⽬前暂不⽀持⽤户上传头像、图⽚背景等对⽤户主动性操作进⾏补充和完善
仅 PC 端限制使⽤场景⽬前对平板端的适配存在⼀些问题Beta 阶段完善软件对平板的适配问题
以上问题总结了本项⽬截⽌到 Alpha 阶段接收到的来⾃众多⽤户的评价和建议与所有队员进⾏集体讨论反思后的成果。其中⼤部分和团队 Beta 阶段的计划重叠，这也使得我们对 Beta 阶段的开发⽅向更加明确。在此感谢对我们产品存在的问题所做出的全⾯透彻的剖析和评价。
计划
我们有⾜够的资源来完成各项任务么
⼈⼒资源：由于本项⽬的开发难度较⼤，预期实现的功能较多，并且市⾯上⽬前没有可以参考的类似软
件，因此总任务量较为繁重。但是，通过合理的分配团队成员的任务，我们充分发挥了所有队员的技术优势，成功完成了 Alpha 阶段的功能开发任务。但相对⽽⾔，在宣传上，我们仍处于⼒不从⼼的状态。
服务器资源：⽬前我们购买的服务器基本能满⾜ Alpha 阶段的需求。但是由于本软件未来将涉及多种图⽚的操作，对⽹络带宽的要求较⼤，因此⽬前服务器在此⽅⾯有⼀定的压⼒。在 Beta 阶段，我们将通过限制⽤户上传的图⽚体量等⽅式综合权衡⽤户体验和服务器负载能⼒。
宣传资源：由于本项⽬的⾯向的受众和北航校内的同学吻合度较低，因此需要能向社会宣传的渠道。但是，⽬前队员的⾃⾝资源不⾜以让我们获取更好的社会宣传平台。这也是 Beta 阶段我们希望能克服的问题之⼀。
各项任务所需的时间和其他资源是如何估计的，精度如何?
⾸先，我们根据预估的任务量⼤⼩和难度对每⼀个任务进⾏所需要的时间预期安排，并且在⽯墨⽂档中进⾏了详细的列举和记录。当队员开始做任务时，我们将根据任务的实际情况对预期时长进⾏微调。所有任务精度控制在⼯作时间 8h 以内。
测试的时间，⼈⼒和软件/硬件资源是否⾜够? 对于那些不需要编程的资源 (美⼯设计/⽂案)是否低估难度?
由于 Alpha 阶段的开发任务较⼤，时间较短，因此留给测试的时间和⼈⼒资源相对有限，此外我们的数据库本⾝较⼤，因此未进⾏充分的单元测试，这也是Alpha 阶段存在的不⾜之⼀。但在有限的资源下，我们仍进⾏了全⾯的压⼒测试、场景测试、 API 测试等，详见。对于前端主页、教程等美⼯设计，我们成功预期了其难度，并且分配专⼈攻克美⼯问题，最终取得了⽐较满意的 UI 效果。
你有没有感到你做的事情可以让别⼈来做（更有效率）?
在前期功能模块开发阶段，由于团队内部的充分沟通和合理的任务划分，每位队员都领到了⾃⼰擅长的任务，可以说将每个⼈的优势都发挥了出来。在后期集成部分，各任务之间具有⼀定的交叉，我们预期到类似问题的发⽣，并决定在后期采⽤集体线下开发的⽅式，遇到问题及时寻专⼈解决，因此开发效率较⾼。有什么经验教训?如果历史重来⼀遍, 我们会做什么改进?
经过 Alpha 阶段的磨合，我们发现本团队的成员都是闷头开发党，这导致我们的项⽬功能完成度较⾼，但是在宣传⼒度等⽅⾯存在较为明显的不⾜。因此，我们认为应当划分更多的精⼒在产品的宣传⽅向，并且及时获取⽤户反馈并及时修正现有错误。另外，对于测试的进⾏应当提上⽇程，防⽌后期时间较紧⽽没有时间进⾏完备的测试。
变更管理
每个相关的员⼯都及时知道了变更的消息?
由于我们所有的⼩组会议和后期开发冲刺阶段全部全员线下进⾏，因此每⼀个变更都能及时传达给团队成员。另外，我们使⽤了”看板法”对任务进⾏了列表和汇总，完成后即使划去，清晰且⾼效。
我们采⽤了什么办法决定“推迟”和“必须实现”的功能?
经过总结，本项⽬ Alpha 阶段实现的所有功能的分类和⼤体优先级如下：
涉及初次登陆⽤户的舒适度的功能为必须实现。
涉及⽼⽤户长期使⽤的舒适度的功能推迟实现
涉及词图核⼼功能的基本功能必须实现。
涉及词图核⼼功能的拓展和美化推迟实现
项⽬的出⼝条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
功能⽅⾯：
Alpha 计划阶段的所有任务基本完成是出⼝的底线。
被使⽤概率较⾼的核⼼功能要达到较⾼的完成度，保证⽆较⼤差错。
UI ⽅⾯：
主页⾜够美观和⼤⽓，能够抓住⽤户眼球。
具有详细的教程，并且教程⼊⼝伴随⽤户使⽤全过程。
前端测试和后端测试的区别
各页⾯整体衔接流畅、风格统⼀。
系统⽅⾯：
⽤户使⽤流畅，各请求不能有过长的等待时间。
能保证⽤户信息安全和数据库数据安全。
对于可能的变更是否能制定应急计划?
将最核⼼的功能放在优先级较⾼的位置实现。
对于功能实现要求的修改，集中在发布前⼀天及之前进⾏。发布临头时不对核⼼功能进⾏⼤幅度修改，防⽌翻车。
对于会议的流程进⾏详细记录，使⽤ 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）呢？从软件实际运⾏的结果来看，这些测试⼯作有⽤么？应该有哪些改进？在发布的过程中发现了哪些意外问题？
在发布当天晚上出现了服务器崩溃问题。后发现这是由于服务器短时间内突然连接数过⼤导致，和系统负载能⼒有关。之后通过重启服务解决了此问题。
我们学到了什么?如果重来⼀遍，我们会做什么改进?
测试⽅⾯是本团队 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
原则完成质量（1~10）欢迎对需求提出变更6
要不断交付可⽤的软件8
项⽬过程中，业务⼈员与开发⼈员必须在⼀起8
要善于激励项⽬⼈员9
最有效的沟通⽅法是⾯对⾯的交谈9
可⽤的软件是衡量进度的主要指标9
提倡可持续的开发8
对技术的精益求精以及对设计的不断完善将提升敏捷性7
要做到简洁，尽可能减少不必要的⼯作8
最佳的架构，需求和设计出⾃于⾃组织的团队7
团队要定期反省如何能够做到更有效，并相应调整团队的⾏为8
代码管理的质量具体应该如何提⾼？代码复审和代码规范的质量应该如何提⾼？
补充代码注释
进⼀步规范新建⽂件⽬录树
整个程序的架构如何具体提⾼？如何通过重构等⽅法提⾼质量，如何衡量质量的提⾼？
前端让每个组件的功能明确，可能多次出现的组件使⽤统⼀组件，提⾼前端的性能。
后端规范 API 的实现⽅式和报错代码的含义。
项⽬跟踪⽤户数据⽅⾯，计划要提⾼什么地⽅？例如你们是如何知道每⽇/周活跃⽤户等数据的？计划增加每个⽤户的停留时间和⽤户留存量的记录。
项⽬⽂档的质量如何提⾼？
3 名 PM 合作完成需要发布的⽂档，3 名组员帮忙准备展⽰视频、测试功能等素材。
对于⼈的领导和管理，有什么具体可以改进的地⽅
需要及时进⾏激励，并且拥有完备的激励机制
需要制定有规律的会议⽅式
队长记得请吃饭
对于软件⼯程的理论，规律有什么⼼得体会或不同意见？
在计划阶段进⾏完整的设计可以帮助推进后期开发⽅向
计划阶段对项⽬进展的规划和实际进展有⼀定偏差，需要及时进⾏调整
对于 API ⽂档、测试等计划需要提前进⾏规范，提前开始⼯作
最后附⼀张总结反思⼤会现场照⽚：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。