事后诸葛亮分析报告

事后诸葛亮分析报告

1.设想与目标

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

• 解决的问题：社交媒体的这几年变得越来越复杂。网络聊天的出现是为了方便人们沟通，但是渐渐的，这个“方便”也只是缩短了时间和距离，而并没有实现更加坦白的沟通。社交媒体依然没有真正实现“人人皆可说“的幻境，它只是给了每个人一支关掉的话筒，怎么能打开，还得靠自己。匿名提问信箱就是为了能够打破这些，实现提问双方的轻松社交。
• 我们对项目的定义非常清楚
• 典型用户和典型场景清晰的描述：

1.2我们达到目标了么?

基本目标已达成，已经实现最初设想的功能，第一阶段计划的所有功能，除了管理员功能仍未完善之外，其他功能已按原计划交付时间交付。

1.3用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?我们离目标更近了么?有什么经验教训? 如果历史重来一遍,我们会做什么改进?

因为时间原因，本项目还未能部署到服务器上，因此除了开发人员之外还没有其他用户，故用户量暂时为0；我们不断在接近我们的目标，相信如果有足够的时间，我们是完全可以实现我们最初的设想。

• 经验教训：时间的分配还不够合理，以至于项目进度有点点拖沓；每个队员都要去及时了解当前项目的进度，而不是交给pm一个人去催促；对工作量预估不够准确，和实际上工作量对比起来有出入。

• 改进：每周必须制定作业任务安排表，及时按时完成任务，才不会拖进度；拒绝拖延症；团队合作必须要开会进行讨论，大家充分交流，才能及时发现问题以及解决问题。

2.计划

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

是，在项目开始前，leader和pm通过召集会议以及会议讨论的结果进行了计划安排。

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

当队内成员出现不同意见或产生分歧时，我们先是由pm来分析和权衡其中的利弊之后再来决定，做到组内观点的统一；如果仍存在异议，我们会通过小组讨论来决定最终的结果。

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

还没有完全做完，因为时间原因，课程任务比较重，又临近期末考试，所以未能完成管理员页面的制作，因此举报功能也未能实现。

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

有，写博客时pm和leader打火焰山！

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

是，我们团队用leangoo来对任务进行管理和任务跟进。

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

我们项目基本都有按照计划进行，但也出现了一点意外。主要是我们购买的服务器出现了未知问题，导致我们的项目还未能部署到服务器上进行发布，而时间又不够，导致这个问题到现在还未能解决。这个风险也是我们最初没有估计到的，应该是属于服务器第三方的原因（当时心里想着都斥巨资了应该不会有啥大问题来着……）。

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

有，后端在计划时间前完成了基本的代码，为后面bug的解决留下比较大的缓冲时间，也有足够的时间去不断完善我们的项目。

2.8我们学到了什么? 如果历史重来一遍,我们会做什么改进?

• 我们学到的：团队合作；新的技术；技术交流；一个项目开发的过程所要做的事情；团队矛盾的处理；xd的使用。“开发过程考虑更多的实际情况和可能发生的错误并执行处理，重要的是提升了实现功能的能力和代码的能力，同时加强了对于部署服务器的理解和步骤，除此之外还接触了前后端分离的vue项目，因为自己在学习前端开发时只会thymeleaf，开展了眼界吧。因为我们队内都是女生，在这一个半个月里我们经常窜宿舍，交流，期间发生了许多有趣的事情，也互相帮助进度比较慢的队友。”——后端大佬感悟
• 如果能重来：更早去学习开发过程中所需要的技术，进行合理的计划安排；pm说如果能重来不会再打火焰山；更加合理地安排时间，和队友们充分讨论；发现问题及时解决。

3.资源

3.1我们有足够的资源来完成各项任务么?

有，但是服务器出现了问题，所以项目还没有上线。

3.2各项任务所需的时间和其他资源是如何估计的，精度如何?

任务所需时间主要是根据任务量来估计的，精确到小时。

3.3测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试时间和人力和软件/硬件资源足够，美工设计低估了难度，在原型设计的时候没有符合设计规范。

3.4你有没有感到你做的事情可以让别人来做（更有效率）?

我做的事就是对草稿的原型制作，撰写博客，协助pm进行任务分配、开会讨论，大家都有自己所负责的工作，提高工作效率。

3.5有什么经验教训? 如果历史重来一遍,我们会做什么改进?

• 经验教训：服务器第三方出现了未知问题。

• 改进：购买服务器时要选择好的服务器，避免出现无法解决的问题。

4.变更管理

4.1每个相关的员工都及时知道了变更的消息?

是，有变更信息我会第一时间通知相关队员。

4.2我们采用了什么办法决定“推迟”和“必须实现”的功能?

我们从系统的核心功能出发来看这个问题，如果它是核心功能，则它属于必须实现的功能，如果是外围扩展的功能（如管理员功能），则在时间紧迫的情况下我们进行了推迟。

4.3项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

实现基本功能（匿名提问和回答功能），用户体验良好，没有较大的安全漏洞，能成功部署到服务器上。

4.4对于可能的变更是否能制定应急计划?

是，如果出现变更情况，我们会立刻快速通知到相关人员进行会议讨论，进行计划变更。

4.5员工是否能够有效地处理意料之外的工作请求？

是，我们会通过讨论和互相帮助来完成意料之外的工作请求。

5.设计/实现

5.1设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作是在确定需求之后，由团队中的PM和Leader共同完成，前端人员也给予了一定的意见；是合适的时间和合适的人

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

有，比如有些功能可能前端后端人员出现了理解偏差，由设计人员来进行解释和回答。

5.3团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

是；有效；UML的类图中的表字段发生了变化；在项目开发的过程中，对表的设计进行了改动；需要。

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

问题展示前端的bug比较多，没有顾及到添加后要重新刷新问题展示等交互问题，致使用户体验不好。原因是前端人员对整个用户交互的认识不够成熟；BUG：使用shiro做权限登录校验，因为我们使用的是前后端分离项目，和普通的前后端不分离项目不一样，我们遇到了前端拿不到session的问题，所以我们改用了JWT的token来保存用户的登录信息

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

在提交代码时安排对应的复审员进行代码复审，保证了基本的代码规范。

5.6我们学到了什么? 如果历史重来一遍,我们会做什么改进?

• 我们学到的：设计规范，代码复审，一些软件的使用，代码规范。

• 改进：要多去学习一下设计规范，多去参考一些优秀的作品，提高自己的审美和设计水平。

6.测试/发布

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

有，在测试之前，由开发人员对项目进行项目测试计划的安排。

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

有

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

有，我们团队用了postman、swagger来帮助测试。

6.4团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

尽可能地模拟用户的所有操作流程，进行多次测试； 没有进行压力测试 ；有用 ；思考的范围还不够全面，未能完全模拟用户的情况，其次是没有进行压力测试。

6.5在发布的过程中发现了哪些意外问题？

由于服务器的原因，本项目只能在本地进行测试和使用，暂未发布。

7.团队的角色，管理，合作

7.1团队的每个角色是如何确定的，是不是人尽其才？

是的，每个角色都是队员主动选择的，成员根据自己的目标和熟悉的技术来选择的。

7.2团队成员之间有互相帮助么？

有，我们团队的成员非常注重交流，互帮互助，在遇到困难时，队内其他队员会伸出援手，互相鼓励，一起讨论解决问题。

7.3当出现项目管理、合作方面的问题时，团队成员如何解决问题？

首先是以pm的意见为主，其次是如果遇到了不能轻易解决的矛盾，我们团队会通过召开会议来对问题进行讨论，最后得出大家都能接受的解决方法。

8.总结

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

我觉得我们团队目前的状态属于CMM中的三级，即已管理级。

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

规范阶段。

8.3你觉得团队在这个里程碑相比前一个里程碑有什么改进?

这是我们的第一个里程碑。

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

自己的编程能力。

8.5对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例

• 以有进取心的人为项目核心，充分支持信任他们。在冲刺阶段，对队友的任务完成能力有充分的信任，相信队友的能力，并且给予充分的支持！
• 队员在项目开发过程中每天共同工作，出现问题及时讨论并解决。
• 快速反馈，在Alpha冲刺阶段，一天一次的站立会议会对每个人进行今天的任务汇报以及下一次的任务安排。

8.6代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

在项目准备阶段，必须给项目制定一套代码规范，并且要求严格执行。

8.7整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

可以通过设定规范完整的API，尽量降低前后端耦合性，从而提高质量

衡量质量的提高的方法具体包括系统bug数量的减少量，修复bug耗时的减少量，整体功能完成时间的减少量等

8.8其它软件工具的应用，应该如何提高？

充分利用GitHub的代码管理方式，通过学习使用其他软件，比如测试软件，来提高项目开发效率。

8.9项目管理有哪些具体的提高？

任务量化，细化，具体到可以立刻实现；需要有验收和整合的步骤。

8.10项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

通过日志系统来跟踪用户数据方面的信息

8.11项目文档的质量如何提高？

有专门的人负责专门的事情，文档的目的是辅助项目的发展，有效的记录、指导、督促才是重要的。。

8.12对于人的领导和管理， 有什么具体可以改进的地方？

需要有一定的领导以及组织能力的人来担任，才能增强团队的凝聚力，带领团队齐头并进！

9.会议照片及角色贡献

9.1会议照片

9.2角色贡献

名字	角色	团队贡献分	可验证贡献
宋旭清	Leader	19	撰写博客，前端界面原型设计实现，协助pm安排任务
杨川钡	PM	19	撰写博客，安排任务，前端界面设计
罗桂珊	前端开发	21	前端开发以及测试
郑宝柔	后端开发	20.5	进行后端开发，在github上合作提交，最后协助测试各模块
周华娟	后端开发	20.5	负责后端系统设计、数据库设计、修复bug