团队项目之事后分析
设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的网站主要是参照豆瓣的部分功能，解决用户分享影视，音乐，摄影交流平台的问题。
网站的定义是比较清楚的，我们主要根据这三个功能模块进行展开论述，用户的定位也是20-30岁这个年龄段的年轻人。
我觉得我们对典型用户和典型场景描述的较为清晰，首先根据我们团队的设想进行构思和描述，后面通过查阅网络相关资料，询问身边的同学和朋友来确定我们的场景。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
总的来说，我们达到了原有的目标。
基本功能虽然有一些细微的问题，但总体而言还是完成了。由于期末考试临近，所以我们在原有的一些基础上进行了细微的调整。
由于网站还没有上线，所以暂时无法统计我们的用户数量。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
在团队看来，团队成员对网站的重要功能还是比较满意的。当然，跟预想的结果还是有一点不一样，但总的来说，我们离目标是更进一步了。
4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训是要提前分配好任务，预留无法工作的时间，因为期末临近，并不是每一天都有空弄这个改进的东西。
如果历史重来一遍，我们会做好规划，并更好的付诸行动。
计划
1. 是否有充足的时间来做计划?
我们预留了时间做计划，但不算很多，
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们出现不同意见的时候，大多数会先在组内展开讨论，如果实在无法达成共识的话，队长就会选择他觉得比较合适的方案。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
团队成员基本上完成了自己的任务。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有时候因为没有事先商量好负责哪一个板块的东西，所以导致出现了一点小的问题，导致工作量的重复。
5. 是否每一项任务都有清楚定义和衡量的交付件?
对的，基本上每一项任务都有清楚定义和衡量的交付件。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
网站由于时间有限和成员能力有所不足的问题，进展比较缓慢，没有准确预估好团队成员的工作时间。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
有，缓冲区可以让我们歇一口气。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
留够充足的时间来完成项目，留下更多的时间给缓冲区，增加项目的灵活性。
9. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
主要从这次项目中学到了团队协作，一个人走的话虽然走得快，一群人走的话才会走的元。
资源
1. 我们有足够的资源来完成各项任务么？
人力资源上：我们有6个人完成，其中4个人负责后端的模块，2个人负责前端的模块，
开发资源：我们的开发资源主要通过github上的开源项目还有百度百科上的一些开发经验给我们帮助。
设备资源：我们的设备主要是通过人手一台的电脑来实现的
时间资源：我们还是留出自己的空余时间一起完成这个项目。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何？
同样是根据任务量估计的，根据网站的功能，细化的功能大小来预估，精度还算是较为准确的。
3. 测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
测试的时间、人力和软件/硬件资源还是相对比较充足的，并没有降低非编程的资源是否低估难度。
4. 你有没有感觉你做的事情可以让别人来做（更有效率）？
可以把分工做的更还一点来提高团队的效率。
5. 有什么经验教训？如果历史重来一遍，我们会做什么改进？
需要更多的时间和资源来完成项目。
变更管理
1. 每个相关的员工都及时知道了变更的消息？
是的。每位成员更新代码后，都会上传至GitLab，并且在微信群通知大家；每位成员测试时发现接口文档有问题，都会提交到gitLab的issue中，方便成员及时更新接口文档
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？
从两方面考虑，一是需求，二是实现难度。结合需求与实现难度，综合难度较低的需求必须实现，综合难度高的需求需要推迟。
3. 项目的出口条件(Exit Criteria - 什么叫“做好了”) 有清晰的定义么？
有。
Web页面可以及时响应数据给用户
用户的相应需求都能得到满足
测试时发现的一些bug得以修复
4. 对于可能的变更是否能指定应急计划？
可以。对于临时增加的紧急需求，可以通过gitLab创建分支，在分支上进行相应的开发，等满足需求后，并测试稳定后合并到上线的分支上，更新项目版本
5. 我们学到了什么？如果历史重来一遍，我们会做什么改进？
整个过程我们体会最大的还是团队合作的意识，唯有团队分工明确，主旨统一时，才能够较好地完成一个项目。如果重来一遍，我们会更好地分工，在分好工后再开始实现项目
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在测试阶段开始的时候，我们一起商议了接下来等待完成的各个工作。对于新增接口，大家一起商定，由前后端人员分别实现。前端的美化由陈俊锋去完成，图片和图标等素材由易俊楷完成。测试则由郑伟金先进行，其他人完成各自工作后进行辅助。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，比如对于某些新功能是否需要的问题，大家的意见不一致，我们就当即进行讨论，对于相应的情况进行表决，以多数的投票为意见
3. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
基本没有，由于大家的基础不同，所以代码风格各有差异，所以代码规范基本是以个人的代码素养为前提来进行复审的。
4. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在一开始的时候，由于没有分析好需求与相应的难度，我们制定了许多了需求，到了后期，由于时间的不足与需求难度的上升，导致一些需求无法满足而被搁置了。归结到底，是由于我们最初没有考虑好产品的定位，从而导致了需求过于复杂。如果再来一次，我们会把基础的需求先提出来，而后对于难度较大的需求进行综合评估，看看团队是否有条件与能力去完成这个需求。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有，由于是前后端分离，所以需要书写接口文档，在对接口文档之前，需要前后端人员各自先本地测试功能是否能正常运行。不过测试是由具体的开发人员来完成的，不同部分进行不同的测试
2. 团队是否有测试工具来帮助测试？
没有，在整个开发过程中，都是通过一些假数据来进行模拟的
3. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
对于此款软件我们团队对其进行了相应的压力测试，观察了后台大概能够承受的并发量。由于该软件未上线，所以测试工作的作用并未得以体现，最好是可以将软件上传到相应的服务器，然后用几台机器进行压力测试
总结
-
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
达到CMMI中的二级，管理级别。在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制。但是还没有一套完整的管理措施，没有制度化。
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合和规范之间。
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
很多大家的磨合度明显提高，效率也提升了，而且更加有默契，遇到问题大家都会讨论解决
- 你觉得目前最需要改进的一个方面是什么?
代码规范性问题，我们的代码注释比较少，以及开发效率问题
- 我们小组什么地方做的比较好？
我们组的很积极、团结，配合程度还是比较不错的，遇到问题大家会积极参与讨论，合作起来比较顺利
- 下个阶段需要改进什么？
没有下了阶段了。但还是期待大家后续的合作
改进
- 团队目前最需要改进的地方是，团队合作的流程不够规范，没有完整的制度或流程有效地提高效率
- 时间规划不够好，到后期，大家的时间都比较紧，不过，后来通过每天提交代码的形式，团队的执行力有效提高了，只要任务布置下来，大家都会挤出来时间去完成的。
