• Beta阶段项目总结


    Beta阶段项目总结

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

    我们的软件是组队APP,要解决的是用户不方便找志同道合的队友的问题,定义很清楚,就是提供给用户一个组队,来寻找队友的平台。我们的典型用户就是想要参加活动的人,典型场景就是不知道怎么找队友。

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

    时间较为充足,基本满足项目的需求

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

    我们对每个人的意见列在一张纸上,然后共同讨论每项意见是否可行,然后投票决定去掉哪一项意见。

    2.用户量、用户对重要功能的实现的接受度和我们事先的预想一致吗?我们离目标更近了吗?有什么经验教训?如果历史重来一遍,我们会有什么改进?

    用户对功能基本满意,只是觉得有点单调,功能稍微简单,没有太多的功能,用户量没有完美预想的那么多,但是还可以,基本满足。

    我们离目标又近了一步,软件发布可以使用了。

    经验教训:要重视用户的体验,首先界面要做的美观一些,与用户的交互很重要。

    改进:将界面做的更加美观,增加与用户交互的弹出式对话框。

    3.计划

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

      基本完成,有一小部分没有实现,原因是要求的技术太高,我们的水平很低,达不到开发实现的要求。

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

    有,发现有一些代码重复编写,本来可以进行封装的,导致浪费了时间而且代码非常的冗余。还有查找资料,学习什么的好多东西都不是主要的,跟开发这款APP没有关系。

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

      没有,我们只是制定一非常初步的计划,交付件参考同类APP的设计结果,我们自己的交付件并没有进行全面的定义

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

     没有按照计划进行,因为开始预想比较乐观,但是实际开发起来却发现并没有那么简单,出现的问题很多,需要再次查询资料才能解决,有的功能太复杂只能放弃。

    5.在计划中有没有留下缓冲区,缓冲区有什么作用?(例如:缓冲区的定义,加班)

     有,虽然每次冲刺是10天,但是我们小组成员都清楚10天不会完成的太好,还需要加时间完成,并进行软件的测试和推广。

    6.将来的计划会做什么修改?

      增加学习的时间安排,对时间的估计不要太乐观。要慢慢来。

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

      我们会将用户体验放在首位,要将界面设计得美观一些,而且要详细地估算时间,不能盲目地觉得差不多就可以,要提前将相关知识点进行学习。

     5.资源

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

      学习资源足够,图片资源不好找,需要长时间地在网上查找符合自己意愿的图片

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

      各项任务与其他资源估计的时间方法较为一致,只是任务的精度较高,其他资源精度较低

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

    测试时间不太足够,在测试时经常发现bug,需要大量的时间来修改,然后再重新测试。

    对不要编程的资源低估了难度,到真正做的时候发现无从下手

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

      没有,我们团队任务分配较为明确,暂时还没有发现让别人来做更好

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

      要重视界面的美化,要提前学习相关的知识,要详细估算所耗费的时间。

    7.变更管理

    1.每个相关的组员及时知道变更的消息吗?

      及时知道,我们在小组QQ群中即时更新项目情况,每个人都能及时收到消息。

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

      我们通过团队会议,分析现在所耗费的时间来变通地决定是否需要推迟某一项功能点,分析现在最重要的功能点是什么。大家一起讨论决定。

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

      有,基本功能都能实现,按照正常流程不会出现问题,允许一定量的小bug的出现。但是不能影响正常使用。

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

      可以

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

      能够有效处理。

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

      我们会加强团队成员之间的联系,对于每个人的想法要及时地进行分享,团队成员共同决定是否采纳。

     9.设计/实现

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

       设计工作在项目开发之前,由团队成员共同开会讨论决定,是合适的时间、合适的人

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

      有,小组成员提出了想法,但是陈述不明确,或者其他成员也提出类似的想法, 但是最终并没有明确采纳哪一项,解决方法是再次进行讨论,确定出明确的意见。

    3.团队是否运用单元测试(Unit Test)、测试驱动的开发(TDO)、UML或其他工具来辅助设计和实现?这些工具有效吗?

      有使用一定的工具,但是很少,有一定的效果。

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

    在活动列表活动刷新功能产生的bug最多,因为监听总是不准确,发布之后发现点发布按钮没有反应,日期选择结果不一致。

    因为我们在开发的时候忽略了一些细节的检查,导致出现了问题。

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

      我们共同将整个项目过一遍,然后每个人提出代码编写的意见,基本执行了代码的规范。

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

      我们将重点开发界面,尽量开发出一款界面美观的软件

    11.测试/发布

    1.团队有没有测试计划?为什么没有?

      有测试计划,在软件基本开发完成之后进行测试

    2.有没有做过正式的验收测试?

      有

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

      有,发布到360应用商店,会给我们的APP进行测试

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

      我们在基本功能开发完成之后都会进行大量的测试,来发现软件的问题,测试软件的效能。测试工作非常有用,能够发现软件在编码时发现不了的问题,应该增加测试的时间。

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

      发布完成后又发现了很多bug,需要重新提交

    12.我们学到了什么?如果历史在来一遍我们会做什么改进?

      我们在发布之前要尽量做好大量的测试,要找到其中的bug,并解决。然后再进行发布,以免需要重新发布,会浪费掉很多时间。

  • 相关阅读:
    Linux下 find 命令用法
    MVC3 ViewBage 输出的值 被编码
    C#枚举数值与名称的转换实例分享
    关于Js的那些面试题
    Javascript Event事件中IE与标准DOM的区别
    原生js选项卡
    js之事件冒泡和事件捕获详细介绍
    js事件的三个阶段
    js对象中关于this关键字的作用
    css的相对定位与绝对定位
  • 原文地址:https://www.cnblogs.com/softwareteam4/p/7026686.html
Copyright © 2020-2023  润新知