标签：方法   一些事   ima   过程   24点游戏   table   方式   码云   写代码   

事后诸葛亮分析

一、设想和目标

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

• 我们的软件可供各类人群闲暇时间消遣娱乐，锻炼脑力。
• 定义的很清楚，就是一个定位准确的算24点的PC游戏。
• 用户范围、受众人群十分广，可谓老少皆宜。闲暇时使用电脑就可以进行游戏。

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

• 算是达到目标了，原计划里主要目的就是做一个计算24点的游戏，次要的就是做一个练习模式以及简易的排行榜功能。剩下的就是一些细节完善。
• 做到了按照原计划交付时间交付。
• 因为我们做的是PC游戏，尚未发布，所以用户数量仅限组内成员。

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

emmmm.....本次是alpha阶段，其上一个阶段……大概是所谓的“0”？具体提高了多少……只能说是“无中生有”了吧。

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

本版本尚未发布，所以只能根据Alpha复审时其他各队的反响来看，就这点而言总的来说还是不错的。

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

经过为时两周的Alpha冲刺阶段，我们总算拿出了一些成果。在冲刺过程中也算尝遍了酸甜苦辣，通过钻研自己所负责任务的相关知识，并加以探索、实践、运用……付出总有回报。除了完成各自的分工，还认识到团队协作并不是各自埋头苦干，而是需要考虑到队友的各种需求，并在互相交流沟通时充分讨论，才能推动整个项目的前进发展。

二、计划

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

算是比较充足吧，毕竟老师在开学时的时候就已经大体讲述了课程教学的流程。

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

一个团队共同努力做一个项目，必然是会出现不同意见的。关键在于人与人的沟通方式的选择与应用，大家都会致力于营造团队内一种和谐向上的讨论气氛，并且在PM的协调下，算是可以融洽地进行团队工作。

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

大部分算是做完，剩下的部分算是完善细节功能，加以包装吧。会放在Beta阶段实现。

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

大家统一的意见是，所谓“事后看来没必要或没多大价值的事”都可以看作是实践中的一次尝试，尝试是必然的也是必须的，所以不认为它是不必要的。

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

不能说是全部都有，但是大部分吧，从Alpha阶段冲刺博客中都可以看出来，码云上也行。

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

其实我们最早是打算做移动设备端的算24点软件，但是由于各种原因，最后还是决定做PC端。风险这种还算是没有遇到。

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

没有..看其他队伍的说法，具体作用是防止紧急情况出现时出现手足无措的情形，用于BUG修复等。

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

会留出缓冲区吧，用来修bug什么的。冲刺计划会做的更严谨一些。

三、变更管理

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

肯定要知道啊，肯定要及时啊，毕竟出门左转一间宿舍就能通知。

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

在老师要求下，冲刺期间每天都是有站立会议的，在PM引领下讨论这些问题，安排之后工作。

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

运行程序后可以游玩算24点游戏，并附练习模式以供解答。这两点是最核心的地方，完成后就可以算是“做好了”，剩下的就是一些细节的完善，界面的设计等。

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

有人提出变更可能的话，就会紧急召开会议，大家共同商量讨论可行性、必要性。通过的话就会制定任务计划，共同实现。

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

我们的团队是一个团结的团队，当某个成员需要处理意料之外的工作请求时，大家会共同帮忙，一起出谋划策。

四、资源

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

王进喜同志说的好：“没有条件创造条件也要上！”
总的来说还算是有吧，虽然我们组所有成员都称不上编程达人，但是通过各自私下的努力，共同完成这个算24点的项目也还不能算是天方夜谭。另外真要说的话我们肯定缺少美工啊233。

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

这次项目让我们初次接触到名为燃尽图的神奇事物。运用起来效果还算是不错，精度还可以。

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

这是第二次！王进喜同志说的好：“没有条件创造条件也要上！”
好吧其实不太足够。。美工设计这方面从来就没有低估过它，朋友，这是拿钱吃饭的活啊，哪能随随便便就让你程序员轻描淡写就包了？

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

首先，大家肯定是有实力差别的，让一个实力高于我的人来做我这块任务肯定会做的更完善，更效率，但是反过来说，我就做不来他原本负责的任务啊。所以这个问题我觉得还是注重实践前的分工安排，不能从某个人某项任务入手去看。

五、设计/实现

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

算是PM吧，在Alpha阶段伊始阶段完成的，至于合适...肯定合适啊！谁反对我们PM我们就锤谁！

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

有吧，挺多的，比如练习模式实现的形式应该怎样选择。如何解决么……开会讨论是万能的，必须的，必然的。

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

这说的都啥玩意..?
没有，讲真我们就是就算24点这个游戏开会讨论、制定计划、分工、各自努力、整合完成。没有搞到很复杂的东西。

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

练习模式产生Bug算是最多的，因为我们对其实现的形式一直摇摆不定，导致最后实现的时间不是很多。比如完成后就发现练习模式中莫名少了张黑桃8。。设计时这块敲定的不够果断吧，还有完成时不太仔细。

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

每个人负责自己编写代码的复审，检查有无冗余、有无执行代码规范等。最后大家统一再过了一遍。

六、测试/发布

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

郑重声明一下，我们是有测试计划的！只是比较简单而已...

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

不能算很正式吧，但是是有的。

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

没有，我们只是做了一些简单的测试，比如查运行信息时只是用了任务管理器分析了一下。。

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

运用任务管理器大致测了一下。这些工作是有用的，发现了一些潜在隐患。

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

我们还没有正式发布，会尽量为之后的发布做足准备。

七、总结

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

CMMI二级，管理级。

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

磨合阶段。毕竟我们做的项目还不能算是能放的上台面的好项目。所以即使这次项目感觉不错也不能高估自己。

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

emmm.......改进在于本来是不存在BOTC这个团队的，现在有了。从0个人到6个人，我觉得改进还是很大的。

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

在冲刺开始前的计划安排上还是需要改进一些，不仅要让各个成员了解自己应该做什么，还应该让彼此间大概地熟悉一下各自的任务，这样在后期会省去不少麻烦。

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

• 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

冲刺阶段里每天都有召开站立会议。互相充分交换各自的工作进度。

• 隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

每次召开会议时大家都会尽力找出自己的不足处，共同讨论如何解决。以及这篇博客——事后诸葛亮分析。

八、全组讨论照片

九、团队成员在Alpha阶段的角色和具体贡献排序

Alpha阶段事后诸葛亮分析

标签：方法   一些事   ima   过程   24点游戏   table   方式   码云   写代码   

原文地址：https://www.cnblogs.com/D-WD/p/9046269.html