Alpha事后分析
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 团队项目-事后分析 |
零、说明
博客模板中涉及到不同阶段对比的问题没有进行讨论，如
设想和目标——和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
总结——团队在这个里程碑相比前一个里程碑有什么改进?
总结——项目管理有哪些具体的提高？
一、设想与目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们期望针对学生考试刷题、学习交流等需求，开发一款集刷题、题目讨论、错题整理、社区资料分享等功能为一体的刷题软件。
软件的所有功能都是基于具体的需求分析和实际潜在使用对象的调研进行确定，按照功能的重要程度确定在Alpha版本或Beta版本进行开发，所有实现目标和期望表现都有明确定义，具体可以参考：功能定义。
关于典型用户和典型场景的分析我们也有清晰的调研和分析，具体可以参考：典型用户和典型场景。
2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?）
就产品实现整体而言，在Alpha版本阶段，我们基本达到了我们的预期目标。
Alpha版本计划开发功能：用户注册与登录，个人信息，多种做题模式，题目推荐，关键词搜索，题目收藏，错题收集，题目评论。以上功能均已在Alpha版本实现，并按照原计划交付时间交付。
原计划用户数量：在注册用户上，微信小程序平台总注册人数达到了162，安卓客户端总注册人数达到了28，基本达到了产品Alpha版本的注册量预期，但是与最终预期的总注册量为550人，还有一定距离，预期进入期末，产品注册人数将会大幅增加；在累积访问量上，微信小程序累积访问量达到了254，在安卓客户端累积访问量达到了123；微信小程序发布8天日活量达到了31.75，安卓客户端发布8天日活量为15.375，达到了预期的学期中使用频率较少，日活为20人的预期。
3.用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？
用户量和用户对于重要功能的接收程度与我们事先预想的一致。
同时因为微信小程序对于IOS客户端的支持以及其自身的便捷使用，我们在用户量上和日活用户量上超过了Alpha版本的预期，离最终目标更近了，但是还存在一定距离，最终的总注册量预期为550人，考期期间日活量预期达到400人，期待在Beta版本中，我们能够更进一步。
4.有什么经验教训? 如果历史重来一遍，我们会做什么改进？
总体来看，我们在调研，需求分析，产品功能设计与实现上，我们都做得较为不错。
唯一与预期有着较大出入的是关于微信小程序和安卓客户端的用户偏好，微信小程序的设计目标最初是为了弥补IOS客户端用户无法下载和使用题士，开发的重点为安卓客户端的开发，最终用户使用统计反馈是：不论是IOS客户端还是安卓客户端，都对微信小程序有着更强的偏好；同时在产品更新和BUG修复上，微信小程序更容易进行产品迭代，而安卓客户端每次更新都需要用户重新安装软件，在未来计划上，我们将会把开发重点慢慢转移到微信小程序端的开发上。
二、计划
1.是否有充足的时间来做计划？
没有，在选题和Alpha版本正式开发之间的时间是十分紧凑的，在确定完选题后，我们需要在三天之内完成需要调研，功能设计，场景设计，典型用户分析等，最后虽然是完成了所有的内容要求，但是在具体工作上并没有非常明确，具体的工作还是在Alpha版本开发阶段一边明确，一边具体开发。
2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
团队将不同的任务按照模块划分给具体的前端和后端，对于具体的任务模块，由具体负责的前端后端进行商讨确定；对于不同模块之间的交互等问题，通过团队讨论，统一确定。
3.你原计划的工作是否最后都做完了？如果有没做完的，为什么？
在Alpha阶段，我们成功完成了Alpha版本阶段制定的所有任务。
4.有没有发现你做了一些事后看来没必要或没多大价值的事？
在前端开发过程中，因为缺乏关于uniapp的开发经验，直接上手开发，没有对于插件市场进行具体的调研，因此在开发初始阶段选择了uniapp插件市场中的比较小众的插件产品，结果存在很多使用隐患，浪费了很多时间。
5.是否每一项任务都有清楚定义和衡量的交付件？
是的，针对开发需求的每一项任务，我们都在Gitlab的Issue分配区进行了明确的任务指定，并在功能规格说明部分进行了明确的交付指标的定义。
6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
整个项目基本是按照计划进行的，没有存在较大的开发时间冲突或意外；关于项目风险，在微信小程序端的发布上，我们在正式发布的前一天才通过了微信小程序的审核，获得了小程序发布资格，差点没有赶上产品发布。
在事后分析中，我们进行了反思总结，因为之前没有过微信小程序的开发经验，所以关于审批流程，审批标准和可能需要的时间上没有概念，导致过晚提交小程序审核，并且在审核过程中因为不符合规范一直被打回，在Beta阶段的开发中，我们会着重注意这个问题。
7.在计划中有没有留下缓冲区，缓冲区有作用么？
在开发计划中，我们有留下缓冲区供开发人员进行任务开发缓冲。
因为在实际开发过程中，计划中对于开发任务的难度预估和实际开发难度预估中会存在偏差，可能不能够及时按照预期进行交付，也可能存在不可抗力问题，导致开发中断，所以缓冲区的存在是必要的，它能够给开发者更多的时间自主调整开发任务，并应对可能发生的不可抗力问题。
8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
在Alpha阶段，我们基本按照计划安排进行了开发和测试，整体表现和计划安排都符合各成员的期望，并且最后产品开发和表现也都超出了预期；在Beta阶段开发，我们计划总体按照Alpha阶段进行安排，并且计划尽早完成Beta阶段的开发任务，花更多时间在测试和用户使用反馈调研上。
9.我们学到了什么？如果历史重来一遍，我们会做什么改进？
在Alpha阶段的开发中，我们主要采用面对面的线下开发模式，同时将具体任务进行模块化，将具体的需求分配给指定的前后端人员，具体模块负责的前后端人员自主联系完成开发任务；前端和后端人员分别进行各自的代码风格规定，测试分配。
这一套开发流程与我们团队现有的开发能力相匹配，并且模块化任务，前后端分离的开发模式极大地解开了前后端之间的束缚，双方约定好接口后，能够更自主地进行各自的开发；线下面对面交流的开发模式，能够更快，更及时地获得开发过程中的团队反馈；同时，我们也在任务模块化分配中也存在不足，颗粒度过大的任务分配，很难预期开发难度和需要的开发时间。
在未来开发计划中，我们计划将Beta阶段的任务更细粒度地进行划分，同时加快开发阶段，留更多时间给产品测试和用户使用反馈的修正上。
三、资源
1.我们有足够的资源来完成各项任务么?
团队目前共有六人，具体职责与项目功能一一对应，详见Alpha项目展示-团队分工，所以人力资源尚且可以支撑团队完成开发任务。
两阶段开发时间均在2-3周左右，充分体现敏捷二字，以敏捷的模式进行两阶段开发，尚且可以保证在预定时间内实现阶段计划。
当然如果可以有更多的资金支持是更好的。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
团队在阶段初始时，会充分划分任务并以issue的形式分配给团队成员，详见Alpha初始任务分配和Beta阶段初始任务分配。
尽可能将每个issue的完成时间控制在1-2小时之间，所以最后取完成每个任务的平均值为1.5小时，再乘以任务总数，得到团队整体时间的预估。
目前服务器、邮件发送等服务均采用按量计费的方式，从而较好地把控团队的开发资金。
各项任务完成时间预估主要结合过往开发经验以及客观开发难度决定，在Alpha阶段大部分任务的完成时间在1-2小时之间，符合预期，同时也存在少量任务估计不准确（低估任务难度）的现象，Beta阶段中将进一步改进，提高精度。
3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
开发与单元测试、功能测试同步进行，产品发布之前会进一步进行后端压力测试和前端兼容性测试，目前题士团队缺少前端单元测试人员，已经在招聘环节发布前端单元测试人员的招聘公告，希望可以有优秀的前端测试人员加入我们的团队！
产品UI与产品宣传文案等由团队内LS和QSY设计制作，从Alpha开发过程来看，团队成员并未低估其难度，而是对每一个页面的设计，每一份文案的制作都抱有充分的准备和充足的信心。
4.你有没有感到你做的事情可以让别人来做（更有效率）?
团队目前分工较为明确且合理，所以团队成员并无此感。
5.有什么经验教训? 如果历史重来一遍,我们会做什么改进?
服务器配置略显仓促，如果历史重来一遍，我们会选择通过学生认证的方式，申请六台服务器的配置，利用nginx进行负载均衡，而非当前的一台在有限的资金支持下配置相对较高的服务器。
四、变更管理
1.每个相关的员工都及时知道了变更的消息?
团队以线下开发为主，每次变更都能及时地通知每一位团队成员。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
按照需求的重要程度，并结合团队具体的开发进度，决定“推迟”和“必须实现”的功能，详情可见Alpha阶段性总结-需求存在，功能存在部分。
3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
通过Alpha-测试报告中的兼容性测试、前端测试和压力测试的结果，以及微信公众平台对小程序审核通过的结果，可以认为题士达到出口条件。
4.对于可能的变更是否能制定应急计划?
可以制定应急计划，比如在Alpha初始任务分配时并未考虑后端管理平台这一项任务，在开题答辩时有幸得到HansBug关于后端管理平台的建议，团队及时针对这一建议进行调整，团队成员QSY由原有的题士开发工作转向后端管理平台的开发工作，同时将QSY原有的题士开发工作再分配至其余两位前端开发人员，因此可见题士团队对可能的变更可以及时制定应急计划，当然这离不开团队成员优异的个人开发能力。
5.员工是否能够有效地处理意料之外的工作请求？
在对QSY原有题士开发任务再分配后，其余两位前端开发人员迅速调整开发计划，及时处理新的工作请求，从而保证题士可以完成Alpha阶段原定开发任务。
6.我们学到了什么? 如果历史重来一遍,我们会做什么改进?
在需求分析阶段，不仅要考虑目标用户的需求，还要考虑项目开发管理人员的需求，即需要方便开发管理人员便捷地导入题库，并对社区、资源等进行统一管理。
五、设计与实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
我们的设计工作主要在开发前期完成，所有成员一同参与。Alpha事后来看，设计工作是在合适的时间、合适的人完成的，因为在实际开发过程中，除去少数情况需要小规模调整接口文档外，所有开发人员在大部分时间只需要“按部就班”就可以了。
- 设计工作在Alpha阶段计划期间开始，在Alpha阶段开始的第一周Scrum Meeting 0425大体完成。
- Alpha阶段计划期间主要是粗粒度的框架设计，所有成员讨论出需要实现的功能，前端人员负责设计静态页面布局。
- Alpha阶段开始第一周则是细粒度的接口设计。我们把需要实现的功能划为几大块，每一块分配一个一级路由，一个前端搭配一个后端在这个路由下进一步设计下级路由以及完成具体实现和对接。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
设计工作出现过许多模棱两可的情况，大部分是在纠结到底是数据库新建表冗余存储，接口直接一条查询语句得出结果还是不新建表，接口使用现有表进行嵌套/连接查询，两种情况都能实现功能，但是前一种情况性能较高但是更新时需要保证所有冗余数据不出错，且需要修改数据库文档，后一种情况数据库的结构更加合理，但是嵌套/连接查询性能较低。
解决办法很简单，经过所有人讨论后，我们一致认为等到出现性能问题再考虑优化，冲刺阶段只需考虑如何实现能更加简单快速。秉承着这种思想，我们选择了后一种方式，不修改数据库文档，同时也保证了数据库的表不会过分多。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
我们使用了单元测试、UML、CI/CD工具辅助开发。
单元测试使用nodejs的第三方模块mocha+nyc+supertest框架进行，然后使用GitLab CI/CD工具进行持续集成，这使得我们每次开发完都能保证回归测试的正确。
我们在数据库设计阶段使用了UML图进行描述，这样有助于我们理清表之间的关系。
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
抛开前端的玄学bug暂且不提。后端注册登录产生的bug最多，原因是这一块需要实现微信小程序以及安卓APP两部分的注册登录，涉及的逻辑较为复杂，当然，这些bug并没有带到发布之后。
发布之后的bug都收录到此博客的5.6部分。重要的bug有两个，一个是ios系统查看题目评论闪出问题，还有一个是小程序游客模式下点击登录不能自动拉取微信头像的问题。第一个bug主要是由于在ios下测试不充分，第二个bug主要是由于小程序上架需要满足用户能在不登录的情况下能体验小程序的要求，所以我们在发布前仓促开发了游客模式，导致一些不兼容问题。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们的代码复审包括三个阶段：
- 首先是自我评审：代码书写者自己对照事先约定的代码规范进行审查
- 其次是同行评审：同样负责前端/后端的几个开发者之前互相评审对方的代码。
- 最后是桌面评审：开发者当着其他成员的面，对着代码阐述功能、逻辑等，其他成员进行评审。
我们的代码严格执行了代码规范。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
我们的收获包括：设计要有条理的、尽早的进行；发布在即时，有可能会遇到很多意外情况，意外情况的处理也需要重视，否则可能会造成发布后bug。
如果再来一遍，我们一定会调研好微信小程序发布的流程以及注意事项，避免发布在即却屡屡被拒。
六、测试与发布
1.团队是否有一个测试计划？为什么没有？
有测试计划，开发时开发人员撰写单元测试，开发完成后由测试人员进行综合测试、场景测试、兼容性测试和压力测试等。并且团队在整个alpha阶段均严格正常执行了该测试计划。在发布和展示阶段并未出现大型Bug。
2.是否进行了正式的验收测试？
进行了正式的测试验收，具体测试验收情况请参考博客题士-Alpha阶段测试报告。
3.团队是否有测试工具来帮助测试？ 很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
有。团队借助Gitlab的CI/CD配置，结合JavaScripts的Mocha测试框架来完成自动化的代码测试。同时对于邮箱验证、微信登录等无法进行自动化测试的功能和代码，团队借助postman进行人工手动测试，以保证测试的完整性。同时也使用weTest平台进行兼容性测试、使用postjson工具进行压力测试。严格执行团队测试计划。
4.团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
团队主要通过记录分析请求时间、功能测试和场景测试来测量软件的效能。压力测试情况请参考博客题士-Alpha阶段测试报告中压力测试一节。从软件实际运行结果来看，这些测试工作有用。保证用户请求的高效性，以优化用户的使用体验，防止用户的流失。同时也给最终目标用户数量部分奠定了使用基础。
可改进之处在于：压力测试部分由于测试开始较晚，因此存在极少数接口的压力测试效果未达预期，优化不足的情况。在beta阶段，我们将会优化该部分接口，同时尽早开始压力测试，预期所有接口的压力测试达到理想结果。
5.在发布的过程中发现了哪些意外问题？
ios系统查看题目评论闪出问题，和小程序游客模式下点击登录不能自动拉取微信头像。团队对此部分问题进行了及时的修复，并未显著的影响软件的发布和用户的体验。
6.我们学到了什么？如果历史重来一遍，我们会做什么改进？
提前制定测试计划，并在开发测试过程中，严格执行测试计划，一定程度上能够保证软件的按时以及高质量的交付与发布。整体来看，团队在测试部分，计划与执行阶段均完成较好，将会在beta阶段继续保持。
七、团队角色管理与合作
1.团队的每个角色是如何确定的，是不是人尽其才？
团队角色由各自的开发经验确定。
团队一共六人，其中
-
QSY具有较多的学生工作、团队开发和宣传推广的经验，故在团队中同时担任PM的角色
从Alpha实现结果来看，前后端开发进度稳步推进，设定功能基本实现，团队成员贡献度均较高，所以可以认为人尽其才。
2.团队成员之间有互相帮助么？
团队成员彼此熟识，配合默契，在开发过程中互相帮助，以此保证了进度的正常推进。
具体帮助内容可见项目展示-额外工作说明。
3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
Alpha开发阶段团队每两天进行一次线下例会，每次例会总结个人开发进度，讨论开发成果，制定开发计划，并进行集中高效开发。
PM完善并推进主体开发计划，如Alpha阶段需要实现安卓APP和微信小程序的联合开发，产品主页和后台管理系统的联合开发等，前后端具体开发内容在每次线下例会讨论时确定，团队成员可以及时沟通，及时调整。
八、总结
1.团队目前的状态属于 CMM/CMMI 中的哪个档次?
根据CMM定义，结合Alpha开发过程得出团队目前的状态为优化级(Optimizing)。
2.团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
团队目前符合博客中描述的创造阶段的若干特征与现象，故处于创造阶段。
3.目前最需要改进的一个方面是什么?
改进内容详见Alpha阶段性总结-任务划分和项目质量。
4.对照敏捷开发的原则,小组做得最好的是哪几个原则? 请列出具体的事例。
根据《构建之法》中敏捷开发12条原则的定义与描述，小组Alpha阶段做的最好的原则包括
- 尽早并持续地交付有价值的软件以满足顾客需求：在设定时间内实现题士Alpha版本预期的所有功能，功能和用户需求可以做到一一对应，结合用户反馈，用户使用Alpha版本的题士较为满意，题士团队也将根据用户反馈进一步改进，提升用户体验，持续交付
- 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短：每次迭代开发的版本会直接申请小程序的审核，审核通过后用户即可使用，发布间隔较短
- 无论团队内外，面对面的交流始终是最有效的沟通方式：团队每两天集中开发，面对面沟通交流，及时调整，效率较高
- 只有能自我管理的团队才能创造优秀的架构、需求和设计：团队成员均对项目抱有认同感，可以主动提升团队开发任务相较于个人任务的优先级，优先保证项目进度正常推进，团队可以做到自我管理，项目整体完成度较高
5.代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
项目采用gitlab的Milestone+issue+Merge Request的方式进行代码管理、版本控制等，通过进一步规范项目管理过程，比如指定分支作为测试分支，不同开发分支有效隔离，阶段性成果及时merge等，提升项目整体的代码质量。
代码复审时需尽可能地保证同行评审（负责前端/后端的几个开发者之间互相评审对方代码）和桌面评审（开发者当着其他成员的面讲解代码功能），开发人员在开发过程中需遵守标准的代码规范，从而提高代码复审和代码规范的质量。
6.整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
从技术角度来看，题士项目的架构为
可以通过设定规范完整的API，尽量降低前后端耦合性，从而提高质量。
从功能角度来看，题士项目的架构为
可以通过降低功能划分的颗粒度，保证功能开发的可追责性，从而保证每一部分功能的质量，提高整体架构的质量。
衡量质量的提高的方法具体包括系统bug数量的减少量，修复bug耗时的减少量，整体功能完成时间的减少量等。
7.其它软件工具的应用，应该如何提高？
充分利用gitlab的Milestone+issue+Merge Reques的管理方式，如降低issue的粒度，及时创建/关闭issue，及时merge成果。
8.项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
通过搭建后台管理系统，统计每日/每周活跃用户等数据，如图：
9.项目文档的质量如何提高？
通过在开发阶段及时补充、完善和规范项目文档，统一文档格式等方式提高项目文档的质量。
10.对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
-
让团队中每个人的长板变得更长：既然组成一个团队，那么就要充分利用每个人的长板，比如团队中的成员相较于文字，更喜欢也更善于写代码，那么他应当承担更多的代码工作，而非博客作业的撰写
-
对团队中的每个人抱有足够的信任：既然把某项任务分配给团队中的某个人，说明相信他可以完成此任务，即对他抱有足够的信任，当然，及时的push和进度把控也是必要的
11.对于软件工程的理论，规律有什么心得体会或不同意见？什么是在下个阶段要改进的地方？越具体越好。
详见Alpha阶段性总结。
十、讨论会
