? 解决问题是：帮助同学们高效的进行包括但不限于航概课程的背题，日常高效的进行学习。定义的较为清楚，有清晰的描述，详见功能规格说明。
? 达到目标了，原计划alpha阶段的功能已经全部完成上线，按照原计划时间交付了，注册用户数量达到了50，日活用户达到10人以上，达到了原计划的用户数量。
? 实际上不是很一致，用户高频使用我们的核心基本功能，但是对我们的一些特色功能使用频率并不高。
? 我们缺乏前期进行需求调研，导致我们的特色功能使用频率较低，并且缺少安全性设计。
? 实际上我们觉得计划的时间略少，课程组给予的时间太少，并且我们也缺乏相关经验。
? 共同商议，pm(组长)拍板。
? 都做完了。
? 在项目前期，前端人员试图本地运行后端进行测试，花了一些时间折腾后端环境，但是实际上后端马上就部署到了服务器上，并不需要前端人员本地部署。
? 开始时划分的任务颗粒度太大，很难确定具体的交付件。后面开发阶段对任务进行不断细化之后，就有一些明确的交付件，例如按钮功能是否正常，页面是否完善，跳转是否正常。
? 基本按照计划，没有出现什么意外。
? 留下缓冲区了，有作用，因为工作安排留了缓冲区，调整了工作进度和工作节奏，课程组给了一周的 时间进行测试与发布，我们再这个阶段也进行了前端一个页面的开发工作。
调整任务划分细粒度，组会的时候每个人要展示成果，让每次组会都给人以ddl的压力。
我们希望对任务进行更严格的ddl要求以达到提高开发效率的效果，有一组的方法非常好——线下集中开发，但这个方法并不适用于我们组这样的复杂情况，每个人的时间安排都很紧，难以协调统一时间。
服务器资源充足，但是人力*技术资源与时间资源不是很充足。
佛系开发，估计的精度较差。
测试的时候硬件资源与人力资源足够。我们低估了美工难度，我们没有专门留出专门的界面设计人员。
有，如果cy承担更多的后端功能细节开发可能效率更高，但是cy同时承担了pm的工作，所以在考虑下一阶段更换pm，进行工作调整。
前端美工，界面设计，beta阶段尽量均衡工作，均衡任务颗粒度。
知道，会在群里或者是开会时发布。
技术难度学习成本过高的功能且非核心功能的可以推迟，核心功能与特色功能必须实现。
基本条件就是可以正常使用，无明显bug，前端页面可以正常跳转，可以给后端发送正确的消息，后端处理请求不报异常，返回正确的信息。
可以
能，alpha由于时间紧，经常设计和开发一起进行，在需求和功能有所改变或者增加时，开发人员往往都可以快速进行修改与增加。
在进行的一些规范或者接口文档修改时，以及一些私聊决定的事情要在群里再发一遍，通知到每个人。
功能设计在开发之前，接口设计与功能细节实在开发过程中设计的，有pm完成，是合适的时间合适的人。
有，讨论解决。
没有使用单元测试，用postman进行后端的测试，没有使用uml。alpha阶段功能简单时间紧急，所以就没有采用单元测试以及uml。
设计时间的功能出bug比较多，因为当时有两个data类，本地获取的data类和从数据库中读写的data类使用较为混乱，时间之间的比较也容易出问题，由于对java时间比较的理解不是很到位。发布之后没有重要的bug。
复审：前后端负责人检查其他人写的代码，前端执行单文件组件规范，接口调用与vuex的使用都有相应的规范文档，缩进格式按照编译器标准格式。
在开发过程中遇到的不确定的问题一定要及时测试及时解决，拖到最后解决会越发困难。
? 对于简单的场景有基本的测试计划，我们的代码功能比较简单，每个人都会对自己写的部分进行单独的测试。
? 在上线之前的每次打包我们都一起进行了测试，每个人都尽量对所有功能以及情况都使用了一遍。
后端使用postman进行测试。团队暂未使用自动化测试，预计beta阶段的改进：使用cicd进行自动化单元测试。
主要是通过服务器的响应速度来评判软件的效能，压力测试相关信息已经包含在测试文档里，测试工作有用，通过测试工作我们发现对于我们的目标用户量，我们的服务器完全可以经受得住考验，在不配置负载均衡的情况下也不会有很大问题。
没有
测试上我们做的还不够好，缺乏单元测试，以及自动化的回归测试。改进：将自动化单元测试加入cicd自动执行。
在某方面有经验的同学就完成该方面的工作，人尽其才。
有，前端有经验的同学，积极帮助其他同学快速学习和入手项目
例会上进行相关讨论，并且由组长决定。
管理级
规范
安全性问题，设计问题，强化阶段检查机制。
尽早、持续交付，可持续开发，业务人员和开发人员在项目开发过程中每天共同工作。
原文：https://www.cnblogs.com/sxdjlmy/p/14791807.html