第八组Postmortem事后分析

第八组Postmortem事后分析

一、团队成员总结的改进和教训

隆晋威:Beta阶段完善架构设计,分工更加明确,文档更丰富,交流带来开销减少。Alpha技术选型不固定,分工混乱,没有方便的测试引擎,部分模块耦合严重。

付千山:Alpha阶段工作较少,主要进行技术积累,由于考试,工作进度稍慢;Beta阶段学到了很多东西,debug能力大大加强,Commit数量、代码量及处理问题的经验积累也有所提高。

欧阳炳濠:Beta阶段中,不同于Alpha阶段。Alpha阶段中主要做的是游戏界面的基本逻辑功能能够实现,但是有许多漏洞,而且玩家体验的效果也不佳,缺乏提示性语句,使得未接触过游戏的玩家对于游戏内发生了什么,该怎么做,完全不知道。而且缺乏封闭性的设置,使得游戏很容易崩溃。

所以在这次Beta阶段的开发中,着重在提升玩家的用户体验。我在这次优化中,找美工同学帮我们重新画了一张地图,同时还增加了消息框功能,用于让所有玩家知晓游戏局势。除此之外,我还设计了玩家在移动后,地图自动跟随玩家移动的功能,便于玩家快速找到自己的位置,而且隐藏了地图的滑动条,使画面更为美观。除此之位,设计了悬浮窗口功能,当玩家将鼠标放置在某一个玩家的人物上时,就能出现显示该玩家的状态信息窗口,包括身份、生命值、英雄、射程、火力、机动性等。便于玩家在游戏中对局内情况进行博弈。

总而言之:在Beta阶段中,打破了信息交流的堡垒,优化了界面的风格,增加新用户的友好性,增强游戏的稳定性,改善玩家的游戏体验。

吴宏宇:Alpha版本中主要是学习新的技术与框架,再一次次的失败中吸取教训与经验,提高自己在团队中的工作效率,改善自己的开发习惯,总的来说就是在开发中提炼自己;beta版本的开发注重了各类的细节,不再是摸着石头过河,而是有准备的进行工作,在之前的版本下不断完善存在的缺陷,总的来说就是要以用户的角度开始提高他们的体验。

朱池苇:Alpha阶段初期对使用的模型和框架比较陌生,用了较长时间学习和实践。Beta阶段,技术已经较为熟练,能够不需要他人协作完成本部分的工作,效率得到了提升,且加深了对模块化的编程方法的理解。

二、关于敏捷开发

① 做的最好的两点

(1)经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。(Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.)

我们的Alpha版本产出较早,虽然非常简陋,而且爆破测试也无法通过,但是有了这个框架,我们在后续阶段的发挥就有了基础。

(2)不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。(The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.)

本团队开会较为频繁,在非考试周保证了每周2-3次面对面会议,即使是在考试周也有每周一次的集中。这使我们解决问题的效率和效果比较好。

② 做的最差的两点

(1)欢迎需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。(Welcome changing requirements, even late in development. Agile processes harness change for the customer‘s competitive advantage.)

由于游戏开发的初衷是“我们想做一个这样的游戏”,向客户征求的大多是细节问题。而且电子游戏,必须要作出原型,才能收获用户的反馈。因此我们在很长一段时间内,用户调研的方式都是线下使用纸张和卡牌做成的桌游版,请桌游社的同学进行评测(测评反馈较为积极,同学也针对游戏提供了宝贵的建议和意见)。在集中精力开发的一段时间内,与用户也有所脱节。

(2)以简洁为本,它是极力减少不必要工作量的艺术。(Simplicity--the art of maximizing the amount of work not done--is essential.)

由于技术设计的问题,我们在某些细节上的处理有一些冗余,甚至是dirty,这也是我们将一直致力于改进的问题。

三、关于“大教堂和集市”开发方式

本组在刚起步阶段时,为集会模式,所有人都可能会接触到所有代码并进行修改,而在技术选型确定,掌握情况较好之后,则按照各自的分工进行工作,不再互相干涉,因此变为大教堂模式。

我们的体会是,大教堂开发模式更适合管理,而在项目规模较小的时候,或者项目刚开始的时候,集市更适合,因为那个时候需要创意,且BUG最多。

原文地址:https://www.cnblogs.com/NoWarningNoError/p/9409735.html

时间: 2024-07-30 14:13:08

第八组Postmortem事后分析的相关文章

M1事后分析汇报总结

学霸网站项目Postmortem结果 设想和目标 1.       我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 学霸网站为计算机学习提供了一个网上基地,在这里你可以上传下载公共资源,你可以提出问题,也可以搜索已经解决的问题,还可以通过搜索标签来查看标签下的网页.主要的用户是高校计算机相关专业的老师和学生以及从事计算机领域工作的人. 2.       是否有充足的时间来做计划? 有一周左右的时间进行计划,时间还可以. 3.       团队在计划阶段是如何解

集美大学网络1413第十五次作业成绩(团队十) -- 项目复审与事后分析(Beta版本)

题目 团队作业10--项目复审与事后分析(Beta版本) 团队作业10成绩 --团队作业10-1 Beta事后诸葛亮  团队/分值 设想和目标 计划 资源 变更管理 设计/实现 测试/发布 团队的角色.管理.合作 总结 全组讨论的照片 团队成员在Beta阶段的角色和具体贡献 合计 1 1 1 1 1 1 1 1.5 0.5 1 10 六个核桃 1 1 1 1 1 1 1 1 0.5 1 9.5 NO.NE 1 1 1 1 1 1 1 1 0.5 1 9.5 六指神功 1 1 1 1 1 1 1

Alpha阶段事后分析报告

Alpha阶段事后分析报告 设想和目标 1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 网站能够采集专业化社区中的问答数据.高质量课程资源.专业技术文档中的内容,为使用者提供一体化的.精准的.高质量的搜索内容2. 是否有充足的时间来做计划? 计划得比较仓促3. 团队在计划阶段是如何解决同事们对于计划的不同意见的? 分析可行性以及向学长以及有经验的老前辈咨询 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么? 不一致未达到预期

团队Beta阶段事后分析

团队Beta阶段事后分析 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们的软件要解决用户的休闲娱乐问题,为用户提供好玩的模拟经营类的游戏,游戏主题是软件开发公司的成长历程.对典型用户和典型场景有清晰的描述. 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?) 我们的功能达到了基本目标,总共5个功能做了3个,但没有按照原计划按时交付延期发布,并因此用户没有达到基本目标. 和上一个阶段相比,

【Alpha】事后分析

目录 [Alpha]事后分析 设想和目标 计划 资源 变更管理 设计/实现 测试/发布 团队的角色,管理,合作 总结 照片 [Alpha]事后分析 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们的软件(网站)希望帮助同学们完成大二学年的物理实验,包括完成实验预习报告.实验数据处理及最终实验报告生成. 对于要解决的问题我们认为定义的比较清楚,对典型用户和典型场景也有清晰的描述. 详见 Alpha展示博客 我们达到目标了么(原计划的功能做到了几个

团队作业10——复审和事后分析(Beta版本)

团队作业10--事后分析(Beta版本) http://www.cnblogs.com/newteam6/p/6953992.html 团队作业10--复审(Beta版本) http://www.cnblogs.com/newteam6/p/6985781.html

【Gamma】事后分析

目录 [Gamma]事后分析 设想和目标 计划 资源 变更管理 设计/实现 测试/发布 团队的角色,管理,合作 总结 照片 [Gamma]事后分析 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们的软件(网站)希望帮助同学们完成大二学年的物理实验,包括完成实验预习报告.实验数据处理及最终实验报告生成.除此之外在Beta阶段我们也希望能帮助同学们复习设计性实验. 对于要解决的问题我们认为定义的比较清楚,对典型用户和典型场景也有清晰的描述. 我们达

团队项目 _社团管理 个人总结 第八组

团队项目 _社团管理 个人总结 第八组 一.项目相关文档整合: 1.需求分析 2.设计文档 3.原型设计 4.项目源码 二.个人工作: 前期准备工作: 需求分析阶段: 我们设计的社团管理系统主要面向三种人员,分别是社长.社员还有管理员.针对社团管理社团的使用人员,提出需求与需要实现的功能并归纳整合. 设计阶段: 首先是数据库设计,ER图的设计如下 数据库设计完毕后编写javaBean并采用hibernate框架连接数据库并测试成功 javaBean: hibernate框架: 其次是部分时序图:

抓包分析第八组

--------------------- TCP报文格式 解析TCP头部数据20字节固定首部:ec 61 8f 50 06 5c b7 11 00 00 00 00 80 02 ff ff b8 81 8f 50 TCP 报文 =以太网头部(14字节)+IP 头部(20个字节)+TCP 头部(20字节)+TCP数据部分 源端口占2个字节:ec 61;0xec61转化为十进制为60513 ;发送tcp包的进程端口为60513 目的端口占2个字节: 8f 50: 0x8f50转化为十进制为3668