事后诸葛亮分析报告
一、设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要是做一个展示自己的个人博客，同时也可以用来展示自己的创意、分享见解、记录生活；定义还是很清楚的，在之前的博客中也对典型用户和典型场景进行了较为详细的描述。
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
我们原计划的功能大部分都实现了，有一些功能由于技术问题还在完善，项目的Alpha版本已经发布，因为项目还没有实现全部功能，所以团队没有进行推广，用户量还没达到预期数量。
- 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量相比预期还有很大的上升空间，根据目前用户的反馈，部分重要功能的用户体验还要加以改善，在团队成员的努力下正在向目标不断靠近。
二、计划
- 是否有充足的时间来做计划?
有，项目开始阶段预留了充足的时间进行规划
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
采取投票的方式，按照人数多的一方的意见进行
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有全部完成，计划实现的软件功能太丰富，团队成员的时间和技术水平有限，有些功能在规定时间内无法实现
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有
- 是否每一项任务都有清楚定义和衡量的交付件?
是
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
基本上整个过程都按照计划进行，我们先让负责后台开发的同学把雏形构建出来，再让负责前端的同学修改页面，结果页面修改时导致部分功能出现异常，后期修复增加了不少工作量，计划受到影响。
- 在计划中有没有留下缓冲区，缓冲区有作用么?
有，留出一定时间进行bug修复，起到了一定作用。
- 将来的计划会做什么修改？
给每个模块分配的时间不要太长，提高成员积极性，留出更多时间用于项目测试和改进
三、资源
- 我们有足够的资源来完成各项任务么？
- 人力资源：项目成员有6位，分别负责前端开发、后端开发、测试以及项目经理工作，人数充足，人员构成合理
- 开发资源：部分成员参加了工作室，有相关项目经验，手上的技术资料也比较丰富
- 设备资源：每人一台电脑
- 时间资源：由于部分成员还需要复习考研、上课，以及兼顾工作室的项目，时间比较紧张
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，主要是关于页面的设计，各个功能按钮放在哪个地方最合适，团队先做出一个雏形，让班上其他同学体验并提出改进意见。
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
只用了单元测试，对于发现项目的漏洞还是挺有帮助的。
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
注册登录功能产生的bug比较多，因为对于用户的用户名和密码有格式限制，如果输入不符合格式的内容要进行提醒并不允许注册通过；发布后发现有些功能点击之后反应很慢，之前在开发的时候由于只是在本地运行，没有通过网络，所以没有发现。
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
当天的开发工作结束后马上进行代码复审，将问题总结出来第二天进行修复，很遗憾团队并没有能够严格地执行代码规范，每个成员都有自己的编程习惯，很难保证每个人都能执行规范。
四、测试/发布
- 团队是否有一个测试计划？为什么没有？
有，负责测试的同学针对各个功能都设计了测试计划。
- 是否进行了正式的验收测试？
由于项目开发的时间比预期长，只是做了简单的验收测试之后便进行了发布。
- 团队是否有测试工具来帮助测试？
没有，都是人工操作
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
团队采用了压力测试的方式进行软件效能测试，测试期间发现并修复的一些问题使得软件实际运行的结果更接近我们的预期，改进的方向主要是测试的深度和广度。
- 在发布的过程中发现了哪些意外问题？
没有发现
五、总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
属于CMMI二级的档次。我们团队基本遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
属于规范阶段，项目成员之间的合作沟通交流都没有问题，能够各司其职、互相帮助，共同完成项目开发。
- 你觉得目前最需要改进的一个方面是什么?
前端和后端开发应该同步进行，不能互不干涉，整个开发过程中要注意各个模块之间的兼容性。
六、全组讨论照片
七、成员贡献评估
- 我们规定的团队贡献分总分：250分
- 基础分 150 (60%)
考虑到不管任务难度，并且每个人都在为团队做任务，所以我们有一开始每个人的基础分30分，但同时基础分也是最重要的，团队项目也是在每个基础上面完成，所以基础分我们还要包括- 按时完成任务 50%
- 按照要求完成任务 50%
(只有完成上面要求才能的满分，否则按照任务重要性，延迟延期的，不能按要求做到将会按照比例扣分。而这些被扣掉的分我们将会用来去给协助完成别的任务的成员)
- 贡献(任务难度)分 90(36%)
每次发布任务，会在团队讨论或者直接由项目经理决定任务的难度系数，在分数的占比。 我们必须给优秀的人给予奖励，毕竟一个团队不可能存在绝对的平均，平衡。一个人有能力，就理所当然的得到更多。
- 创意分 10(4%)
一个项目的提出，或者一个好的项目，肯定是从一个有效，有创意的idea开始的，我们鼓励每个人提出自己的想法，如果你的意见被采纳，当然你就能获得高分。同样这也是对一些编码能力差的同学的一些友好的选择，用自己的想法去补充。
| 姓名 | 职责 | 团队贡献分（满分为250） |
|---|---|---|
| 249 | ||
| 245 | ||
| 235 | ||
| 240 | ||
| 235 | ||
| 235 |
