王者荣耀交流协会PSP Daily项目Postmortem结果

王者荣耀交流协会PSP Daily项目Postmortem结果

整理:王超

设想和目标

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

PSP Daily 要解决用户(主要是软件工程课上学生)记录例行报告、写每周PSP表格和统计的需求。该群体小而精,需求比较明确。对典型用户和典型场景在我们的软件功能说明书中有清晰的描述。

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

有时间,但是一开始我们没有清楚地意识到及早利用这一段时间来做计划:PSP阶段的预估时间和实际时间及WBS规划。这导致我们无法较为精确地度量我们的开发能力、工作量和工作效率,很可惜。

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

有时是组长负责决定安排,大部分时候通过交流解决,大家都比较善于沟通,善于接纳好的建议。

【另外阿超有某种“光环”,大家对TA比较信任,所以TA说的话别人比较容易接受,不同的意见也没有特别强烈。】

 

计划

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

大部分计划基本完成。事后发现没有完成饼状图的时间百分比统计。因为这个小功能没有在软件功能说明书中定义清楚,开发原型没有很具体,所以开发到后面DEV不记得了。后期有人提及,DEV觉得在发布之前没时间做出来了,所以延期完成。

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

没有。大部分工作都是必要的。

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

起初没有清楚定义如何衡量交付,因为我们大家都没意识到衡量和交付问题。后来划分了细致的颗粒度,对于分工和交付都比较清楚了。

4.       是否项目的整个过程都按照计划进行?

基本上,因为每天开会,大家都会积极参与,起到一种比较强的推动作用。

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

没有缓冲区,不知道要设置“缓冲区”。我们的项目相对比较小巧,所以大家进度不会差太远,相对好控制。

且记缓冲区为组长请客聚餐。

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

PSP阶段要预估时间和度量实际耗费时间。

对于功能的说明和设计要更加具体、细致,及时review和修改。

功能快速原型的手段很不错,要继续使用。

分工要细致、加强测试环节的配合。

 

资源

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

一般有时间和设备来完成各项任务,时间是宝贵的资源。有时候大家比较忙,需要花费时间来统计开会时间。完成任务有时候比较滞后。

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

开始凭着DEV的估算、精度很粗略,后来随着项目任务的加重,大家只顾得上干活,没时间考虑精度问题。

3.       用户测试的时间,人力和软件/硬件资源是否足够?

足够。

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

没有。我们后期已经有较为细致的分工,且ddl是第一生产力。

 

变更管理

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

成员有时会在群里说明更新情况。有时不会。

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

软件功能说明书的定义,基本功能必须实现;

功能的难度和思路如果清楚了,快速原型基本做好,则必须实现;

时间够必须实现;否则,推迟。

3.       项目的出口条件(Exit Criteria)是否得到清晰的定义?

大家都不太懂“出口条件”是什么。说实在的,在这个项目里面我们没有用到或者我们不知道我们用到了。

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

会。开会讨论决定、群里讨论。

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

是。队员之间配合得都不错。

 

设计/实现

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

由提出项目主题的人完成。是合适的时间,合适的人。

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

很多,大家都不知道如何解决。设计者就大概设计了一个UI,但是后期改动很多。因为一开始没有定义清楚,开发设计思路都不完善。

3.       团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?

没有运用单元测试(unit test),测试驱动的开发(TDD)、UML工具。运用了 leangoo看板、燃尽图、todolist控制项目进度,挺有效的。

4.       什么功能产生的Bug最多,为什么?

时间处理和excel表格的操作bug最多。

时间处理因为逻辑需要想清楚,开始没有很完善,所以bug较多,改了三次。

excel操作不熟悉,学习的难度稍微大一点,网上的可学习使用的代码错误或者版本都不太一致,需要调试很久。

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

没有进行代码规范要求。开发迭代周期短,没有最终的代码复审。

 

测试/发布

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

我们有测试计划,但是大家的测试反馈不太多。似乎是因为DEV开发本地测试好了,其他人没有测试或者测试了没有报告。

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

没有。时间有点紧。

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

没有使用测试工具。

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

本地运行程序。有用。改进:测试和debug做好记录。

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

Excel的操作需要Office的引入,涉及到版本问题。

原文地址:https://www.cnblogs.com/wangc034/p/7794186.html