考前自救题库——Alpha阶段事后分析
Alpha阶段事后分析
一、设想和目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决问题是：帮助同学们高效的进行包括但不限于航概课程的背题，日常高效的进行学习。定义的较为清楚，有清晰的描述，详见功能规格说明。
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
达到目标了，原计划alpha阶段的功能已经全部完成上线，按照原计划时间交付了，注册用户数量达到了50，日活用户达到10人以上，达到了原计划的用户数量。
3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么?
实际上不是很一致，用户高频使用我们的核心基本功能，但是对我们的一些特色功能使用频率并不高。
4、有什么经验教训? 如果历史重来一遍,我们会做什么改进?
我们缺乏前期进行需求调研，导致我们的特色功能使用频率较低，并且缺少安全性设计。
二、计划
1. 是否有充足的时间来做计划?
实际上我们觉得计划的时间略少，课程组给予的时间太少，并且我们也缺乏相关经验。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
共同商议，pm(组长)拍板。
3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
都做完了。
4.有没有发现你做了一些事后看来没必要或没多大价值的事?
在项目前期，前端人员试图本地运行后端进行测试，花了一些时间折腾后端环境，但是实际上后端马上就部署到了服务器上，并不需要前端人员本地部署。
5. 是否每一项任务都有清楚定义和衡量的交付件?
开始时划分的任务颗粒度太大，很难确定具体的交付件。后面开发阶段对任务进行不断细化之后，就有一些明确的交付件，例如按钮功能是否正常，页面是否完善，跳转是否正常。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
基本按照计划，没有出现什么意外。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
留下缓冲区了，有作用，因为工作安排留了缓冲区，调整了工作进度和工作节奏，课程组给了一周的 时间进行测试与发布，我们再这个阶段也进行了前端一个页面的开发工作。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
调整任务划分细粒度，组会的时候每个人要展示成果，让每次组会都给人以ddl的压力。
9.我们学到了什么? 如果历史重来一遍,我们会做什么改进?
我们希望对任务进行更严格的ddl要求以达到提高开发效率的效果，有一组的方法非常好——线下集中开发，但这个方法并不适用于我们组这样的复杂情况，每个人的时间安排都很紧，难以协调统一时间。
三、资源
1. 我们有足够的资源来完成各项任务么?
服务器资源充足，但是人力*技术资源与时间资源不是很充足。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
佛系开发，估计的精度较差。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时候硬件资源与人力资源足够。我们低估了美工难度，我们没有专门留出专门的界面设计人员。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
有，如果cy承担更多的后端功能细节开发可能效率更高，但是cy同时承担了pm的工作，所以在考虑下一阶段更换pm，进行工作调整。
5.有什么经验教训? 如果历史重来一遍,我们会做什么改进?
前端美工，界面设计，beta阶段尽量均衡工作，均衡任务颗粒度。
四、变更管理
1. 每个相关的员工都及时知道了变更的消息?
知道，会在群里或者是开会时发布。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
技术难度学习成本过高的功能且非核心功能的可以推迟，核心功能与特色功能必须实现。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
基本条件就是可以正常使用，无明显bug，前端页面可以正常跳转，可以给后端发送正确的消息，后端处理请求不报异常，返回正确的信息。
4. 对于可能的变更是否能制定应急计划?
可以
5. 员工是否能够有效地处理意料之外的工作请求？
能，alpha由于时间紧，经常设计和开发一起进行，在需求和功能有所改变或者增加时，开发人员往往都可以快速进行修改与增加。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在进行的一些规范或者接口文档修改时，以及一些私聊决定的事情要在群里再发一遍，通知到每个人。
五、设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
功能设计在开发之前，接口设计与功能细节实在开发过程中设计的，有pm完成，是合适的时间合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，讨论解决。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没有使用单元测试，用postman进行后端的测试，没有使用uml。alpha阶段功能简单时间紧急，所以就没有采用单元测试以及uml。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
设计时间的功能出bug比较多，因为当时有两个data类，本地获取的data类和从数据库中读写的data类使用较为混乱，时间之间的比较也容易出问题，由于对java时间比较的理解不是很到位。发布之后没有重要的bug。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
复审：前后端负责人检查其他人写的代码，前端执行单文件组件规范，接口调用与vuex的使用都有相应的规范文档，缩进格式按照编译器标准格式。
6.我们学到了什么?如果历史重来一遍,我们会做什么改进？
在开发过程中遇到的不确定的问题一定要及时测试及时解决，拖到最后解决会越发困难。
六、测试/发布
1. 团队是否有一个测试计划？为什么没有？
对于简单的场景有基本的测试计划，我们的代码功能比较简单，每个人都会对自己写的部分进行单独的测试。
2. 是否进行了正式的验收测试？
在上线之前的每次打包我们都一起进行了测试，每个人都尽量对所有功能以及情况都使用了一遍。
3. 团队是否有测试工具来帮助测试？很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
后端使用postman进行测试。团队暂未使用自动化测试，预计beta阶段的改进：使用cicd进行自动化单元测试。
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
主要是通过服务器的响应速度来评判软件的效能，压力测试相关信息已经包含在测试文档里，测试工作有用，通过测试工作我们发现对于我们的目标用户量，我们的服务器完全可以经受得住考验，在不配置负载均衡的情况下也不会有很大问题。
5. 在发布的过程中发现了哪些意外问题？
没有
6.我们学到了什么?如果重来一遍, 我们会做什么改进
测试上我们做的还不够好，缺乏单元测试，以及自动化的回归测试。改进：将自动化单元测试加入cicd自动执行。
七、团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
在某方面有经验的同学就完成该方面的工作，人尽其才。
2. 团队成员之间有互相帮助么？
有，前端有经验的同学，积极帮助其他同学快速学习和入手项目
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
例会上进行相关讨论，并且由组长决定。
八、总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
管理级
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范
你觉得目前最需要改进的一个方面是什么?
安全性问题，设计问题，强化阶段检查机制。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
尽早、持续交付，可持续开发，业务人员和开发人员在项目开发过程中每天共同工作。
什么是在下个阶段要改进的地方？越具体越好。
- 加强前期调研，功能设计不再以脑补为依托
- 做好阶段性检查工作，严格控制进度。
- issue划分细粒度仍需加强控制。
- 加强测试，去除低效的手动测试，将单元测试集成进cicd自动进行回归测试。
