事后诸葛亮分析
目录
一、团队讨论照片
二、设想与目标
三、计划
四、资源
五、变更管理
六、设计/实现
七、测试/发布
八、团队的角色，管理，合作
九、总结
十、团队成员在Alpha阶段的角色和具体贡献
一、团队讨论照片
二、设想与目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们做的软件主要是解决社团、工作室在招新过程中的问题，定义清楚，是一款基于方便面试官和面试者使用，提高面试过程体验的双赢产品
2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
招新系统基本功能基本实现，但由于时间紧迫，还有一些小bug和细节需要调试，基本按原计划交付时间交付，推广力度有限，用户数量未达到预期数量。
3.和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高？
团队软件工程的质量提高，代码质量，项目的稳定性有所体现。
4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么?
大致一致，也有些功能在开发过程中完善。
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
前期项目讨论时间过短，前后端功能讨论较少，导致后面花太多时间在对接和测试上。若再来一遍，会着重讨论，将需求分析透彻清楚。
三、计划
1. 是否有充足的时间来做计划?
这学期学业较为繁重，时间比较紧张，有些同学加入工作室，有项目在身，但我们合理安排时间，总体而言，时间安排还算是合理。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
主要是微信群讨论，按照实际需求进行合理的讨论，大家商量得出一个最为合理的解决方案。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本完成，但是对接过程中出现一些小细节的bug还没有完成调试，负责此模块的同学任务相对繁重，时间紧张。
4. 是否项目的整个过程都按照计划进行，项目出了什么意外？
总体来说，按照预计的趋势顺利发展，并没有出现过于严重的意外。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
有留下缓冲区，缓冲区主要是为突发事件和调试bug准备的，因为计划往往赶不上变化，比如突显隐藏bug等。
6. 将来的计划会做什么修改？
加快进度，大家都挤一挤时间，完成最后的bug修复，细节完善和冲刺。
7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
计划往往赶不上变化，在项目初期应考虑多种情况特别是突发情况，留足缓冲时间。有空的时候应该把该做的任务先完成，避免拖沓导致无法按期完成。
四、资源
1. 我们有足够的资源来完成各项任务么?
我们有拥有参与已上线项目的前端后台开发人员，能够较好应付协作开发、测试等任务，但在UI设计方面有所欠缺。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
我们将任务按照功能复杂程度，模块之间的耦合情况进行划分；已对该业务是否熟悉进行相应匹配。精度基本无误差，但容易出现不可抗的外力因素（其他课程出现的任务）而导致轻微偏差
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
对开发和测试部分能够较好消化，硬件资源如服务器等也足够应付该项目；但在设计方面有所欠缺，目前来说一个好的产品能够有好的界面也是至关重要的。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
在项目开发过程中，我们都按照已有经验进行了最优的分配，虽然自己的能力有所不足，但是假若改变任务分配，可能还需要付出更多的学习成本。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
项目初期资源和任务的估计、分配会更加细腻。
五、变更管理
1. 每个相关的成员都及时知道了变更的消息?
是的，变更前我们都会及时群聊或者线下讨论。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
按我们软件设计初衷紧密联系的功能和与软件运行必需的底层模块决定为必须实现
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有。能够通过基本数据、边缘数据测试、单测代码覆盖率超过百分之90
4. 对于可能的变更是否能制定应急计划?
在确定变更前我们都会讨论，并决定相应解决方案
5. 成员是否能够有效地处理意料之外的任务请求？
可以的，小组成员积极配合。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
前期功能实现逻辑分析不到位，导致项目推进过程不够顺利，如果再来一遍，前期花在功能分析的时间会考虑多点。
六、设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作主要是在项目初期完成，具体功能由大家讨论决定，确立大致模样后由前端人员细化优化，数据库表及逻辑由队长设计。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
基本没有。假如出现了是由大家进行讨论之后PM作出最终决定。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
我们用到了单元测试工具，这边为了测试不用模块的功能。这些工具也是极大了提高了我们的测试效率。
4.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审由开发人员，PM负责。在代码复审时会严格查看开发人员的代码规范的。
七、测试/发布
1. 团队是否有一个测试计划？为什么没有？
有测试计划，在开发和接口对接过程中都会进行相关测试。
2. 是否进行了正式的验收测试？
是的，功能上线后都会进行测试。
3. 团队是否有测试工具来帮助测试？
没有用到测试工具，采用了人工测试。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们将各个模块的测试进行分配，每个组员进行用例测试。最后的运行结果证明了测试工作还是有用的，发现了很多之前没发现的潜在问题，并及时解决。
5. 在发布的过程中发现了哪些意外问题？
我们开发的是网站，发布较为简单，暂时没啥大问题。
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
人工测试效率太低，性能无法保证，如果再来一遍，会优先学习测试工具进行性能、压力测试等。
八、团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
角色确定：我们是按照各自擅长的技术来分配任务的，比如擅长后端的同学搞后台部分，擅长前端的同学搞页面交互部分，擅长设计的同学搞页面设计部分。
是否人尽其才：是的，在整个项目开发过程中，各成员都将自己擅长的技术应用到相应模块上，各司其职，各尽所能。
2. 团队成员之间有互相帮助么？
有的，在遇到难以解决的问题时会在群里请教其他成员，成员之间会相互帮忙解答疑惑。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们会在群里讨论，有问题会及时提出，负责到对应模块的同学会进行对接并解决。
九、总结
1. 觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
二级
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
萌芽，我们需要学习的东西还有很多，希望能增加更多技能。
3. 你觉得目前最需要改进的一个方面是什么?
提高测试能力和解决问题的能力。
十、团队成员在Alpha阶段的角色和具体贡献
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
|---|---|---|---|
| 曾曼青 | 前端开发&队长 | 97 | 完成前端页面交互的开发 |
| 邓靖汐 | UI设计 | 96 | 完成页面的设计 |
| 陈诒祺 | 后端开发 | 96 | 完成数据库设计、面试官设置模块开发、项目部署管理 |
| 曾肖宇 | 后端开发 | 96 | 完成登录功能、学生信息模块、面试队列模块 |
