6.2 事后诸葛亮分析报告

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/SoftwareEngineeringClassof2023/
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/SoftwareEngineeringClassof2023/homework/13332
这个作业的目标	事后诸葛亮分析报告

设想和目标

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

非盈利的娱乐游戏，没有解决新的问题，只是对经典游戏的复盘。

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

可以说勉强达到了目标，为什么勉强，请往下。

3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

软件工程的质量没有提高，仍然缺乏了具体的实质性的规划，尤其是在经典这一标签下，更让人产生怠惰。总体来讲，有所提高，因为这是第一步，不可能再下降了，提高的方面在于，了解了软件工程的过程。

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

设计中不在意用户量，是随缘的状态。

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

因为是对某一系统的复盘，如果仅考虑在这一情况下而不考虑突破，我觉得有必要参考别人的项目,但是我没参考，拍脑子就上，事后看有些太乐观；其次，它太小了，让人难以做令人满意的总体设计，在我的设想中，各个功能是随意漂浮的，不由某一数据或者指令而联系起来，因而在设计方面非常拘泥。
继续总体的架构，在我的设计中，它把一大堆东西塞在了一起，内部做数据的沟通，这显然给测试增加了难度，不利于发现问题。我认为有必要对这一部分代码做重构，由于认识不足，不会做。所以有必要学习更多的知识，但这又是在准备阶段难以预料到的。
简而言之，其实是考虑太少，考虑不详细。

计划

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

有。

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

我自己一个人不能左右脑互搏，从这看来，团队是专断的。

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

否。没有做UI的改进，因为我觉得当前UI符合最低限度；没有做进度保存,因为和微软的扫雷一对比，我就觉得这一切是一场徒劳无功，肮脏的代码越积越多，自己也就越迷 茫，最后 开 始 摆 烂

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

无。

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

是。

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

否。bug不算意外。

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

有。没有什么用，因为日期偏离了计划。

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

暂时不会，会重点放在总结上。

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

在目标那里。

资源

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

有。

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

所需的时间和精力是随缘估计的，包括冲刺前和冲刺中，可以说由于缺乏了某种见识，做完时真是觉得估计的时间是既多了（实际与计划不符）也少了（对自己实力的评价），精度实在不咋地。效率实在是低。

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

是。是。

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

没有别人。

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

缺少知识，所以要好好学。

变更管理

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

否。缺少开发文档对一个长周期的或者是一个大项目是致命的。做着做着就忘了三天以前自己干了什么，我都怀疑自己是不是痴呆。

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

项目太小，这类问题没有遇到。或者说不推迟，遇到困难干耗着。

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

认为符合需求说明书即可。

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

项目太小，此问题没有考虑

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

没有员工。

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

增加开发文档，至少把各个函数汇总一下也好。开发文档应该是时刻可见的，像起床就能看到一样，不是翻箱倒柜才能找到的东西；要回顾开发文档，首先文档要写得合适，规划的要方便记忆。

设计/实现

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

只有我一人，没有别的人选。但我有疑问，设计的人要对内容有多熟悉，需要设计模块和代码吗。

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

从上看，有；在设计过程中，没有。或者说，装作不知道。

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

有运用单元测试，只是很难找到一个我可以理解的文档，测试也没有做全，自己当时又懒又急。

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

对于前一个问题，不回答。对后一个问题，“右键标旗功能不稳定，在部分情况下会误翻格子甚至崩溃”,虽然不知道为什么崩溃，但是再次使用软件，确实发现了不符合预期的情况（不知道是否一样），在写本段的时候，我也难以想象这个bug是怎么发生的。我觉得是因为，由于系统设计的时候没有一个核心，一个逻辑过程，整个串行代码偏离了预期过程；另一方面，自己没做系统测试导致的；不过，这个bug很难复现，可能要做极端点的测试：如鼠标在10ms的间隔下按下左右键会怎么样。

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

代码复审很随意，全局变量没有执行代码规范（全大写，因为有很多全局变量）

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

首先。得了解测试的方法，怎么了解是一个问题。要记得做系统测试，要考虑一些极端情况。
设计问题我感觉不那么好做，得看别人得案例才行。

测试/发布

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

做前我觉得勉强算，做后我觉得没有。我觉得还是得跟着做。

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

无。过于潦草了

3. 团队是否有测试工具来帮助测试？
很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

没有有效地使用测试工具。在这方面，我给不出有建设性的建议。

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

Crtl+Shift+Esc任务管理器通过观察得出。没有压力测试。

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

打包问题。我甚至在考虑怎么打包美观，最后没做。

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

参考别人的测试经验，得学。增加压力测试。

总结:

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

不入流。

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

不存在。

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

没有。

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

都要改进。投降主义情绪。

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

难说。因为我只有一个人。

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

还是要以多交流为主，我自己缺少指导。

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

我认为应该有一个可见得开发文档，需要有一个或多个不脱离开发，熟悉流程的代码审查人员做代码复审和规范，而且这个人是有效的。

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

这个问题我无法回答。

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

这个问题我无法回答。

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

这个问题我无法回答。

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

这个问题我无法回答。

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

想象一个压根什么不懂得人来看你的代码，他提出了代码的理解上的疑问，说明文档做得不够好，让另一个开发人员来无法接手。

7. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

这个问题我无法回答。

8. 对于软件工程的理论，规律有什么心得体会或不同意见？

我相当迷茫，言语错乱，这个问题我无法回答。还是做了才知道。

贡献分

按照事先约定的，不做更改，贡献分总共20分/人*1人=20分

名字	角色	贡献分	扣分项
郑深生	所有	7	没有设计一个接近经典的UI，得-1N 没有做了完善的测试，得-1N 没有真正做了反思,愿意改变的,得-1N 没有队友，得-10N