首页 > 其他 > 详细

团队Beta阶段事后分析

时间:2018-01-14 14:11:51      阅读:78      评论:0      收藏:0      [点我收藏+]

标签:出口   做了   估计   保留   -c   规划   合作   代码   相关   

团队Beta阶段事后分析

设想和目标

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

我们的软件要解决用户的休闲娱乐问题,为用户提供好玩的模拟经营类的游戏,游戏主题是软件开发公司的成长历程。对典型用户和典型场景有清晰的描述。

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

我们的功能达到了基本目标,总共5个功能做了3个,但没有按照原计划按时交付延期发布,并因此用户没有达到基本目标。

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

和上一个阶段相比,我们团队的关键工程质量有了提高,首先是文档更加齐全,主要完善了美工文档和策划文档,并重点更新、维护了策划文档;此外整体的风格更加统一了。衡量标准主要是github上的wiki文档的数量以及完备度。

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

用户量还在增长,也接受了我们做出的重大功能,与我们的预想基本一致,离目标更近了。

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

如果要说经验教训的话,我们在当初设计的时候应该选择简单的益智类或者类似的游戏类型而不是模拟经营类游戏,因为模拟经营类游戏在短期来看我们没有良好的美术功底并不能做到在等待过程中很好的游戏体验。

计划

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

我们计划时间很充足,在beta阶段我们总共花了1周多的时间进行策划完善和设计计划。

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

我们通过每天晚上的长时间的策划会议征集大家的意见,并最终由PM决定是否保留争论或者定下功能进行下一步的计划。

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

我们原计划的工作到最后并没有全部做完,因为时间上不太充足,遇到了重大的技术障碍导致我们的工作效率严重下滑。Cocos creator不能支持多人同时开发UI并由于他的环境依赖无法做有效的测试这些都导致了后面开发过程十分缓慢的问题。

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

在计划初期一直在横向广度上进行功能的探索而不是对于一个功能更加细致的进行设计规划。这个工作在第二周才开始,导致整体进度有些拖后。

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

是,我们每一项任务都有一个issue以及对应的文档写入或者代码签入可以衡量。

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

没有按照计划进行。项目在中期出了美工开发进度没有赶上开发,这个主要是由于没有及时的督促、进度管理导致的;项目中后期出现了严重的技术问题,主要是当初选择的cocos creator框架的问题,当时没有估计到是因为对这个框架本身没有做过很细致的调查导致的。

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

我们留下了缓冲区,有些作用,但由于强大的技术风险缓冲区瞬间填满并没有发挥全部作用。

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

将来的计划上,加班是一定的,缓冲区上我们需要更加细致的定义,将预留时间改为频繁多轮迭代来设置缓冲区。

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

我们学到了在选择框架等技术问题上需要货比三家,多加调研后再去决定,要不技术风险巨大又无法承受。如果历史重来一遍我们首先不会再使用cocos creator并多加调研使用更适合本项目的框架再去进行开发。

资源

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

我们的美工资源并不足够,组内没有足够的有美术功底的人进行总体的美工设计。其他资源足够完成各项任务。

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

各项任务根据任务量的大小进行时间估计并写在issue上,并完成后在issue上评论实际所花时间来进行衡量,对下一次任务估计有所帮助。精度上基本都跟预测的一样,比较准确,只是任务量的估计上有些差错。

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

在alpha阶段,我们对不需要变成的资源低估了难度导致没有出来好的需求设计等文档以供后续开发,开发流程上也有些混乱。这次我们投入了三个人进行策划设计,两个人进行美工设计,其余进行开发,人力、软件资源都足够,没有低估难度。

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

我感觉基本上没有,我把能让别人来做更有效率的事情尽可能分配了。

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

在资源上我认为下次应该再招收有美术基础的人进行美工设计会更好。

变更管理

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

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

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

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

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

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

设计/实现

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

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

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

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

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

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

测试/发布

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

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

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

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

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

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

团队的角色,管理,合作

团队的每个角色是如何确定的,是不是人尽其才?

团队成员之间有互相帮助么?

当出现项目管理、合作方面的问题时,团队成员如何解决问题?

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

总结:

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

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

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

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

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

全组讨论的照片。

团队Beta阶段事后分析

标签:出口   做了   估计   保留   -c   规划   合作   代码   相关   

原文:https://www.cnblogs.com/cxyscpjljt/p/8283227.html

(0)
(0)
   
举报
评论 一句话评论(0
0条  
登录后才能评论!
© 2014 bubuko.com 版权所有 鲁ICP备09046678号-4
打开技术之扣,分享程序人生!
             

鲁公网安备 37021202000002号