脚本宝典收集整理的这篇文章主要介绍了事后诸葛亮分析报告，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。

一、设想和目标

1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们的软件主要是为在整理资源上有难处的同学提供一个资源整合平台，各个用户都能在上面搜索想要的学习资源，同时可对资源进行收藏等操作，同时该平台具有较强的扩展性，是一个值得深入开发的项目，定义的相对清楚。在之前的博客中对典型用户和典型场景已有清晰的描述。

2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?

我们原计划的功能大部分都实现了，有一些功能由于技术问题还在完善，项目的Alpha版本已经发布，因为项目还没有实现全部功能，所以团队没有进行推广，用户量还没达到预期数量。

3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

用户量与预期差不多，根据目前用户的反馈，我们发现了一些功能待完善，导致用户体验不好，在团队成员的努力下正在向目标不断靠近。

二、计划

1、是否有充足的时间来做计划?

有，项目开始阶段预留了充足的时间进行规划。

2、团队在计划阶段是如何解决同事们对于计划的不同意见的？

采取投票的方式，持有不同意见的同事分别说出自己的意见，经过团队讨论后投票确定采取哪种意见。

3、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

没有全部完成，计划实现的软件功能太丰富，团队成员的时间和技术水平有限，有些功能在规定时间内无法实现，有些功能则因为技术问题暂时无法实现。

4、有没有发现你做了一些事后看来没必要或没多大价值的事?

有，用户在访问资源时点击【下一页】按钮时会有弹窗提示：将去往某页。这实际上是在编写代码时用于测试的，为了提高与用户的交互性保留了下来，但用户反馈的体验并不好，应该删掉。

5、是否每一项任务都有清楚定义和衡量的交付件?

是

6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

基本上整个过程都按照计划进行，我们先让负责后台开发的同学把雏形构建出来，再让负责前端的同学修改页面，但在实现【邮箱发送验证码】时花费了大量时间，另外由于疏忽导致验证码严格区分大小写，这导致用户体验较差。

7、在计划中有没有留下缓冲区，缓冲区有作用么?

有，留出一定时间进行bug修复，起到了一定作用。

8、将来的计划会做什么修改？

给每个模块分配的时间不要太长，提高成员积极性，留出更多时间用于项目测试和改进

三、资源

1、我们有足够的资源来完成各项任务么？

• 人力资源：项目成员有4位，分别负责前端开发、后端开发、前端与后端交互以及项目的测试。
• 设备资源：每人一台电脑
• 时间资源：团队成员的时间都相对宽裕，有一定的时间用于项目开发

2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有，主要是关于页面的设计，各个功能按钮放在哪个地方最合适，负责前端的同学先做出一个雏形，让团队的其他成员体验并提出改进意见。

3、团队是否运用单元测试（unIT test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

有，在后端开发中使用了工具包，对实现邮箱发送验证码以及请求的处理有较大的帮助。

4、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

注册登录功能产生的bug比较多，因为对于用户的用户名和密码有格式限制，如果输入不符合格式的内容要进行提醒并不允许注册通过；发布后发现有些功能的用户体验不好，例如用户访问资源时每次点击下一页都会有弹窗提示，验证码区分大小写等，在开发时没有想到是因为我们测试时输入验证码都是直接复制，导致忽略了大小写问题。

5、代码复审（Code review）是如何进行的，是否严格执行了代码规范？

当天的开发工作结束后马上进行代码复审，将问题总结出来第二天进行修复，团队相对严格地执行代码规范，每个成员都有自己的编程习惯，但整体上是符合代码规范的。

四、测试/发布

1、团队是否有一个测试计划？为什么没有？

有，负责测试的同学针对各个功能都设计了测试计划。

2、是否进行了正式的验收测试？

由于项目开发的时间比预期长，只是做了简单的验收测试之后便进行了发布。

3、团队是否有测试工具来帮助测试？

没有，都是人工操作

4、团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

团队采用了压力测试的方式进行软件效能测试，测试期间发现并修复的一些问题使得软件实际运行的结果更接近我们的预期，改进的方向主要是测试的深度和广度。

5、在发布的过程中发现了哪些意外问题？ 在项目发布时，由于不熟悉项目的发布，花费了较多时间，最后在有项目部署经验的同学的帮助下完成了项目的发布。

五、总结

1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

属于CMMI二级的档次。我们团队基本遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。

2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

属于规范阶段，项目成员之间的合作沟通交流都没有问题，能够各司其职、互相帮助，共同完成项目开发。

3、你觉得目前最需要改进的一个方面是什么?

前端和后端开发应该同步进行，不能互不干涉，整个开发过程中要注意各个模块之间的兼容性，同时还应重视项目的测试。

六、团队照片

七、成员贡献评估

团队成员绩效评估方法

成员绩效

成员绩效 = 团队所获分数 + 个人贡献分

个人贡献分指标

指标	占比
按时完成任务	30%
任务质量	30%
积极性	20%
创新性	20%

团队成员绩效

学号	姓名	角色	成员绩效（满分一百）
3119005383	林泽涛	组长、后台	98
3119005380	梁晋源	前端	98
3119005367	陈益俊	前端	98
3119005368	陈志恒	后台	98

脚本宝典总结

以上是脚本宝典为你收集整理的事后诸葛亮分析报告全部内容，希望文章能够帮你解决事后诸葛亮分析报告所遇到的问题。

如果觉得脚本宝典网站内容还不错，欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。