事后诸葛亮分析

作业概述

这个作业属于哪个课程软件工程
这个作业要求在哪里团队作业6——复审与事后分析
这个作业的目标复审与事后分析
项目仓库链接坦克大战

设想和目标

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

    我们的软件就是设计一个坦克大战小游戏,面向想通过简单人机游戏放松心情的人、想与同伴一起回忆经典游戏的人设计。

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

    已经达到目标,原计划的功能全部实现,按照原计划交付时间交付,用户数量还需后期推广才能达到预期用户量。

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

    和上一个阶段相比,团队软件工程的质量提高了,主要在测试阶段对一些bug的改进。

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

    已经推广给不少用户测试方便告诉我们bug所在,预期用户量还需后期推广才能达到。

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

在开发项目之前,我们团队对开发设计以及开发技术的相关学习都有所欠缺,整体做出来的项目并不够完美。如果重来一遍,我们会提前学习相关开发技术,使开发过程更加顺畅,项目更加完美。

计划

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

    有充足的时间做计划。

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

    进行投票决定或者开会讨论。

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

    原计划的工作最后都做完了。

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

    花太多时间在素材的收集和整理上面。

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

    有一部分没有。

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

    我们项目的整个过程都在按照计划执行,但是对开发技术的不熟悉导致需要花费额外时间学习并查找资料。

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

    无。

  8. 将来的计划会做什么修改?(例如:缓冲区的定义,加班)

    还没确定,需要开会讨论。

资源

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

    有的。

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

    按照对项目所要开发的每个功能做大概时间预测。

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

    资源足够,没有低估难度。

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

    有的,在计划安排方面应该更加明晰一些。

变更管理

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

    是的,会在工作群里发消息通知每个成员。

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

    从两方面考虑,一是需求,二是实现难度。基础功能是必须实现的,而对项目整体进程没有影响以及实现难度较大的可以适当推迟。

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

    有,能够正常运行且没有bug影响到用户的体验。

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

    能。

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

    如果有队员遇到了难题或者时间不够完成自己的任务的时候,团队的队员都会去帮忙解决。

设计/实现

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

    在选题之后开始设计工作,由PM来完成。

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

    没有。

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

    因项目是由前端技术实现的,可以直接使用浏览器测试。

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

    在游戏地图方面产生的bug最多,因为要考虑到多种情况。发布之后发现游戏地图的地形有时候会和坦克不兼容,因为开发时候对技术的不熟悉导致这种情况的发生。

  5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

    由测试的成员进行复审的。

测试/发布

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

    有。

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

    是的。

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

    因项目是由前端技术实现的,可以直接使用浏览器测试。

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

    无。

总结

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

    处于规范期。

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

    团队整体的沟通效率以及开发水平提升。

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

    提前学习相关开发知识,提高开发效率。

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

团队成员角色具体贡献团队贡献分
郑贵南开发游戏地图设计开发18.76
陈威衡PM及开发坦克类型设计开发19.16
张嘉荣开发游戏操作方式设计开发18.84
陈梓鹏开发游戏首页界面设计开发18.69
马楚泽开发素材收集及帮助团队开发18.57
谢剑滔测试测试18.63

事后诸葛亮分析

  • 20
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
四象限法则是一种管理学中常用的工具,它将行动分为四个象限,分别是重要且紧急、重要但不紧急、不重要但紧急、不重要且不紧急。根据这个原则,我们可以分析诸葛亮在拯救企业和身边人命运方面的努力。 首先,诸葛亮在拯救企业方面采取了重要且紧急的行动。在《三国演义》中,有一段描述诸葛亮救援刘备的故事。当时,刘备的军队已经陷入了困境,粮食断绝,面对着被敌人围攻的危险。诸葛亮当时采取了紧急措施,亲自率军前往解围,并且想出了妙计,利用火攻打败了敌人。这种行动表明了诸葛亮在关键时刻能够果断采取行动,采取了重要且紧急的措施来拯救企业。 其次,诸葛亮也在身边人的命运救助方面采取了重要但不紧急的行动。在《三国演义》中,有许多描述诸葛亮治理民生的故事。在他的治理中,诸葛亮采取了许多不紧急但重要的措施,如改善民生、修路铺桥、开办学校等。这些措施虽然不是紧急的,但却对人们的生活有着深远的影响,提高了人们的生活品质,改善了人们的命运。 此外,诸葛亮也在身边人的命运救助方面采取了不重要但紧急的行动。在《三国演义》中,有一段描述诸葛亮救治病人的故事。当时,有一位病人因患上了急性病而危在旦夕,诸葛亮亲自前往为他诊治。虽然这个行动不是特别重要,但却是紧急的,因为病人的生命受到了威胁。 最后,诸葛亮也在身边人的命运救助方面采取了不重要且不紧急的行动。在《三国演义》中,有一段描述诸葛亮通过占卜来预测天灾的故事。虽然这个行动既不重要也不紧急,但它却展示了诸葛亮对于未来的关注和预见。 综合来看,诸葛亮在拯救企业和身边人命运方面采取了不同的行动,根据四象限法则,这些行动可以分为四个象限。这表明诸葛亮在处理问题时能够根据情况采取不同的行动,让自己的行动更加高效和有针对性。这种灵活性和高效性正是成功的关键所在。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值