事后诸葛亮分析
一、团队讨论照片
二、设想与目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们做的软件主要是解决人们日常生活中有些音乐资源难找的问题，定义清楚，是一款基于共享为主要宗旨的音乐共享网站，用户可在网站上上传，下载，评论歌曲。
2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
歌曲的共享功能基本实现，但由于时间紧迫，还差评论功能（2020/6/16日已完成），推广力度有限，用户数量未达到预期数量。
3.和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高？
团队软件工程的质量提高，代码质量，项目的稳定性有所体现。
4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么?
大致一致，也有些功能在开发过程中完善。
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
前期项目讨论时间过短，前后端功能讨论较少，导致后面花太多时间在对接和测试上。若再来一遍，会着重讨论，将需求分析透彻清楚。
三、计划
1. 是否有充足的时间来做计划?
这学期多门课程都需要课设，时间比较紧张，有些同学加入实验室，有项目在身，但我们合理安排时间，总的来说还可以接受。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
主要是微信群讨论，取意见更加符合实际需求的，大多情况下是少数服从多数。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
差歌曲评论模块，负责此模块的同学有项目在身，时间点紧张。
4. 是否项目的整个过程都按照计划进行，项目出了什么意外？
大体上按计划进行中
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
有留下缓冲区，缓冲区主要是为突发事件准备的，因为计划往往赶不上变化嘛，比如突显隐藏bug等，负责人突然有事等。
6. 将来的计划会做什么修改？
加快进度，多留时间给测试。
7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
计划往往赶不上变化，在项目初期应考虑多种情况特别是突发情况，留足缓冲时间。
四、资源
1. 我们有足够的资源来完成各项任务么?
有足够的开发人力资源；但缺少测试经验、界面设计知识；
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
我们将任务按工作量和难度进行拆分估计，实际工作时间往往比估计长，精度不高。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
对测试缺乏经验，我们人力资源足够，手动测试，用例测试。对于美工设计有所低估，后来也意识到美工设计的重要性。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
在项目开发过程中，我能力有限，对任务安排可能略有轻重，让更强的大佬当队长可能会更有效率；
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
项目初期资源和任务的估计、分配会更加细腻。
五、变更管理
1. 每个相关的成员都及时知道了变更的消息?
是的，功能变更前我们都会群聊讨论。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
按我们软件设计初衷紧密联系的功能呢和与软件运行必需的功能设为必须实现，
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有，无明显bug，满足用户正常使用，项目运行稳定。
4. 对于可能的变更是否能制定应急计划?
在确定变更前我们都会讨论，并决定相应解决方案
5. 成员是否能够有效地处理意料之外的任务请求？
可以的，小组成员积极配合。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
功能分析不到位，导致后面有些功能改动较大，如果再来一遍，前期花在功能分析的时间会考虑多点。
六、设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作主要是在项目初期完成，具体功能由大家讨论决定，ui由mp确立大致模样后由前端人员细化优化，数据库表及逻辑由队长设计。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
基本没有。若有，则团队讨论解决。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
我们开发中用junit单元测试工具，整合前用postman和Rester进行接口测试，便利我们测验提高我们的测试效率。
4.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审由开发人员，队长，pm负责。有严格执行代码规范的。
七、测试/发布
1. 团队是否有一个测试计划？为什么没有？
有测试计划，在开发和接口对接过程中都会进行相关测试。
2. 是否进行了正式的验收测试？
是的，功能上线后都会进行测试
3. 团队是否有测试工具来帮助测试？
没有用到测试工具，采用了人工测试
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们将各个模块的测试进行分配，每个组员进行用例测试。最后的运行结果证明了测试工作还是有用的，发现了很多之前没发现的潜在问题，并及时解决。
5. 在发布的过程中发现了哪些意外问题？
我们开发的是网站，发布较为简单，暂时没啥大问题。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
人工测试效率太低，性能无法保证，如果再来一遍，会优先学习测试工具进行性能、压力测试等
八、团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
是的，在整个项目开发过程中，各成员都按自己将自己擅长的技术应用到相应模块上，各司其职，各尽所能。
2. 团队成员之间有互相帮助么？
有的，在遇到难以解决问题时会在群里请教，懂的成员会帮助解决。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
群里讨论，有问题及时提出，对应模块负责人进行相应对接并解决。
九、总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
二级
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
萌芽，各成员都应继续学习，增强技能。
你觉得目前最需要改进的一个方面是什么?
提高测试能力，讨论效率。
十、团队成员在Alpha阶段的角色和具体贡献：
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
| 陈忠明 | 后端开发&队长 | 21.5 | 歌曲歌手模块及上传下载后端开发，项目部署管理 |
| 吴茂平 | 后端开发&MP | 19.5 | 用户登陆，注册以及评论模块后端开发 |
| 吴尚谦 | 前端开发 | 21 | 歌曲歌手列表以及歌曲播放，评论模块前端开发 |
| 郑靓 | 前端开发 | 19.5 | 用户信息修改，歌曲上传下载前端开发 |
| 杨锐龙 | 前端开发 | 19.3 | 用户登陆注册模块前端开发 |
| 黄海钊 | 后端开发 | 19.2 | 数据采集，管理，主要博客撰写等 |
