事后诸葛亮分析报告
事后诸葛亮分析报告
一、设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 解决的问题：大学生等学生群体对背英语单词的刚需以及现有的背单词软件不能很好的满足需求
- 典型用户：广大学生群众、特别是大学生
- 典型场景：提前报名了四六级，但是没有具体的背单词计划，或者是试了几款背单词软件都不能满足自己的需求，效果不佳
-
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
- 顺利达成目标
- 原计划的主界面、用户界面、学习单词界面、后台按记忆曲线安排复习计划都顺利完成并且按时间交付了
- 可惜我们的用户数量没有达到第三阶段的50人的预期，线下推广效果一般
-
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
- 质量明显提高，最直接表现在界面的优化，原先的UI界面较为杂乱（初期较多考虑的是功能的实现）现阶段的界面设计有了明显的优化，简洁明了。
- 我们是以测试用户反馈的体验评分作为衡量标准的
-
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 大部分用户对我们的重要功能（背单词功能）的接受程度都是符合我们的预期的，基本都认为我们的单词界面简洁、轻快，没有什么花里胡哨的、更适合学习单词；当然，也有部分用户在单词界面提出例如“可以增加选项”的意见，使得我们的项目可以更加的优化
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训：如果重来一遍，我们会事先发一份大体的问卷调查，先实现大部分人共同的需求，再实现次要的需求，以此类推。
二、计划
-
是否有充足的时间来做计划?
有的，我们在任务发布的前3天会确定下小组内具体的分工细节
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
俄罗斯转盘——组内一致通过的解决分歧方案
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作按期圆满完成
-
有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有
-
是否每一项任务都有清楚定义和衡量的交付件?
项目初期确实有发生因为没有清楚定义而产生分歧的交付件（组内“23push”事件），因此我们吸取教训，在之后的任务中都会给出具体的定义，防止“撞车”
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
组内确实出现过意外——因某位组员狂热的push热情，其他成员一直push失败，一度怀疑是自己的本地仓库出错，导致其他成员不停的删库重建。
我们没有估计到push时间的冲突以及该位组员对项目的热情程度
-
在计划中有没有留下缓冲区，缓冲区有作用么?
有，一般都是在周末，在项目冲刺阶段，缓冲区起到提供协商的作用
-
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
最近考试临近，缓冲区的时间应该会有所调整，全组成员为了不进入“加班”这一事态而努力
-
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到的是不能在ddl之前没有准备，需要安排足够的学习技能时间，并有良好的自律或者是同伴的监督，确保项目有条不紊的发展。
三、资源
-
我们有足够的资源来完成各项任务么?
我们有足够的资源完成任务主体的开发，但没有服务器这些资源，因此还未上线。
-
各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务基于队员知识水平和学习能力制定，同时参考任务量和时间因素，精度以两天为一周期。
-
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试时间和人力和软件/硬件资源足够，低估了美工设计的难度，花了一定的时间在此之上。
-
你有没有感到你做的事情可以让别人来做（更有效率）?
每个人都有每个人擅长的领域方面，我们每一件事都由最正确的人来做，因此效率很好。
5、有什么经验教训? 如果历史重来一遍**, 我们会做什么改进？
前后端交接因为新接触因此不熟悉，如果再来一次我们会先充分全面地学习该领域知识，而后抽象加以运用。
四、变更管理
-
每个相关的员工都及时知道了变更的消息?
所有成员会在第一时间收到某个模块负责人下发的最新消息。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
从时间和该功能重要性来参考。
-
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
实现了基本功能，用户在使用过程中没有严重影响体验的恶性bug。
-
对于可能的变更是否能制定应急计划?
重大变更发生后我们第一时间召集所有成员开会。
-
员工是否能够有效地处理意料之外的工作请求？
成员会在进行必要性评估后进行处理，如若有必要则进行加工，无必要性则删减。
我们学到了什么? 如果历史重来一遍，我们会做什么改进?
我们学到了如何高效开会下达通知。如果重来一遍我们依然会这么做——也许会改为线上会议。
五、设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在项目一开始就已完成，由所有组员共同讨论完成。时间合适，人员合适。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
设计工作的过程中，组内想法较多，没有统一的想法，后来根据实际情况，选择了最合适我们的项目。
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
在开发过程中，后台使用spring boot的单元测试。工具可以有效地帮组项目开发。
-
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
前后端交互部分产生BUG较多，有些代码书写不规范，导致一些资源无法读取产生bug，发布后未发现重大bug
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审是由组长进行。在项目开始时已制定代码规范，但是在实际情况中会出现一些意料之外的问题。
六、测试/发布
-
团队是否有一个测试计划？为什么没有？
有制定测试计划
-
是否进行了正式的验收测试？
在项目完成后，有专门的组员进行测试，得到反馈较好
-
团队是否有测试工具来帮助测试？
使用burpsuite进行测试
-
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
软件的效能主要是根据背单词过程中单词的词量、准确度和流畅度来决定，从实际情况来看，项目开发完成得不错
-
在发布的过程中发现了哪些意外问题？
项目未在服务器上上线，并未发现问题
我们学到了什么?如果重来一遍, 我们会做什么改进？
通过这个项目基本学会了前后端的知识，和网站的基本搭建。重来一遍，我们会更好地完成这个项目，优化前端页面。
七、团队的角色，管理，合作
-
团队的每个角色是如何确定的，是不是人尽其才？
团队通过根据各个成员擅长的技能分配角色、分配需求，因此有人尽其才。
-
团队成员之间有互相帮助么？
有，大家遇到问题会及时求助其他组员
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
八、总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
完成级
2.你觉得团队目前处于萌芽/磨合/规范/创造 阶段的哪一个阶段?
萌芽
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
这个项目是我们第一个里程碑，但是我们会持续学习进步！
4.你觉得目前最需要改进的一个方面是什么?
开发知识不足
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
定时开会交换意见
遇到困难及时交流讨论解决方案
6.正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
规范代码（命名、注释、API方面）
对每个模块及时测试
7.代码管理质量具体应该如何提高？
使用源代码管理工具的主干，分支，合并功能，每次提交都需要review
8.整个程序的架构如何具体提高？
积极重构优化项目，留给设计阶段更多的时间
9.其它软件工具的应用，应该如何提高？
多学习获取知识与经验
10.项目管理有哪些具体的提高？
使用issue分配开发任务
11.项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
可以后台保存用户记录用以分析；提高抽样率
12.项目文档的质量如何提高？
编写前先安排文档规范，可以向厉害的团队、项目学习文档规范。
13.对于人的领导和管理， 有什么具体可以改进的地方？
可以更精细地安排团队内的工作与位置。
全组讨论的照片
团队成员在Alpha阶段的角色和具体贡献
| 名字 | 角色 | 团队贡献分 |
|---|---|---|
| 苏泓晖 | 前端后台开发、主要设计 | 22 |
| 刘健君 | 后台开发、次要测试 | 21 |
| 马自达 | 文档编写、主要测试 | 18 |
| 吴浩坤 | 前端开发测试 | 19 |
| 温桂豪 | 前端次要开发、文档编写 | 20 |
