zoukankan      html  css  js  c++  java
  • Alpha冲刺之事后诸葛亮

    1. 设想和目标

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

      我们的软件要解决的是需要进行财务管理的用户的痛苦, 给他们一款轻量级、易用性高的记账小程序,能够实现日常记账以及账单分析;是,我们在做这个选题时有下载过几个记账app,以及在网上查找到一些关于使用记账软件的反馈;是,在通过根据对用户需求分析之后,我们对典型用户和典型场景有清晰的描述。

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

      我们目前刚结束完第一阶段alpha阶段,并没有上一个阶段可以进行比较,所以这个问题不能做出回答。

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

      我们实现了alpha阶段制定的功能,原计划的功能共有记账和查询功能,都已经实现了,也在alpha阶段结束将alpha版小程序发布出去,按时将项目交付了。
    因为还在alpha测试阶段,并没有进行公开推广,使用的人目前就是同学,亲人(预期用户数20人),以达到。

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

      用户量已达到我们预期估计的用户数量,用户对我们发布的记账小程序的重要功能(记账和查询)的接受程度和我们事先预想的一致,通过咨询使用过我们小程序的用户,小程序的功能符合他们的需求(记账和易用),我们离目标更近了。

    2. 计划

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

      是,我们花了一段时间来做这个项目的需求分析,人员的分配,以及有七次(15分钟)的站立会议来讨论一下项目进度以及遇到的问题。

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

       对于处理团队团员之间的意见不同时,我们先让每个团队队员先讲清自己的意见想法,然后采取少数服从多数的原则,确定最终的决定。

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

      我们alpha阶段的工作计划都有做完。

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

      没有,我们团队在开始alpha阶段时就已经进行人员工作的分配,每个人都是按照自己分配到的任务去完成,所以都是些必须的事。

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

      是,我们的每一项任务都是在分析阶段已经协商确定了的,每个任务该完成什么功能都已经清楚,并且在码云上有相应的源代码、软件规格说明书、代码规范文档以及alpha阶段七篇冲刺博客标明项目的进度。

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

    • 项目整个过程并不是一直按照计划进行的,计划有出现一些变动。
    • 在项目进行过程中,出现了一个重大的意外,就是我们在安装Eclipse的SDK插件时,安装过程出现了错误,导致软件不能运行,整个项目的进度都被耽误了,并且后来为了项目可以正常进行,我们只好更换了微信小程序平台来开发项目。
    • 安装软件失败问题导致项目无法推进,差点出现“开天窗”的结果是当时没有估计到的。
    • 因为当时还没有开始项目之前,我们只觉得代码上可能会出现一些问题,就将前期的精力主要放在代码的学习和准备上了,就没有提前进行软件的安装和软件的学习、准备,但是没有想到最后居然是在安装软件时出现的差错。

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

    • 在计划中有留下缓冲区。
    • 缓冲区有作用,我们团队主要是利用缓冲区的时间里进行我们项目代码的测试、查找项目的Bug和修复项目的已知Bug。也利用了缓冲区这段时间进行团员之间的相互交流,并根据交流的结果对项目进行了完善,像是有些地方的设计改成这样会更好之类的修改。

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

      将来的计划会做出的修改有:

    • 我们将会预留出比Alpha阶段更多一些的缓冲区,毕竟预留出缓冲区可以应付一些紧急事件,也可以帮助我们将我们的项目进行完善。
    • 然后的话,我们会将工作安排得更加合理吧,避免像这次一样一直在熬夜加班的状态,争取能够少熬夜。

    3. 资源

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

    • 相对于其他团队,我们团队的人力资源可能就不是特别丰富了,我们团队中有两名成员在编程方面的能力不是很出众,导致大部分项目的任务需要有其他三位同学担起来。
    • 时间资源上,也因为安装软件和插件不成功的原因,导致时间上很紧张,我们就只能够利用上一切我们可以利用的时间,还每天熬夜,这才赶在项目截止时间前完成。
    • 学习资源很丰富,因为当前微信小程序是比较热门的,网上的教程比较多,可以很容易找到自己需要的学习资料和视频教程。

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

    • 各项任务所需的时间一般是按照任务的难度进行预估的,像是界面的排版不是很难这样的任务分配的时间就不会太多,像界面中功能的代码编写就需要分配比较长的时间。一般会根据头一天的任务进行情况来分配今天的任务,像是今天需要完成哪几个任务这样。而其他资源的话,像是人力资源,就会根据每个人的编程能力的大小来分配相应的任务,这样可以节约时间,更好地完成项目。
    • 但是我们团队的任务的各项资源分配的精度并不是很高,都比较精度低。

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

    • 各个模块的测试时间相对充足,每完成一个模块,就会对这个模块进行验收,验收合格之后这个模块才算真正完成了,不合格的模块是要重新进行更改的。在整体项目完成后,我们就用缓冲区的时间进行了整体项目的测试,像是模拟用户使用微信小程序的测试,项目自身的测试,像是安全测试,CPU占比等测试,时间上还是挺充裕的。
    • 人力资源和软/硬件资源是足够的,本团队共有5名团员,人数充足,并且每个人都安装好了所需要的软件,需要的硬件资源也准备好了。
    • 美工设计的难度没有被低估,一开始我们的团队就很重视美工设计这块,毕竟软件不仅仅是有功能就好,而且还需要有美观的界面,才能够令人赏心悦目,让用户满意。所以我们的项目的最终成果的界面还是挺美观的;
    • 文案的难度没有被低估,我们整个团队在写博客上每个人都参与进来了,按照每个人分配好的任务进行撰写,保证每个人的参与度和任务的完成度。

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

      有在一些情况下感到我做的事情可以让别人来做更有效率。像是与其,我们每个人在进行编写代码时,都对界面进行美工设计,导致界面风格不一致,最后还要重新修改过,还不如一开始就由一位擅长美工的团员进行界面的美化设计。

    4. 变更管理

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

      每个相关的员工都及时知道了变更的消息。我们团队有自己的讨论群,有变更的消息,我们都会在群里发通告,并@所有人,让她们收到回复,这样就能够保证每个人都通知到位了。并且大部分的团队是一个宿舍的成员,基本上都在一起,消息变更的话,知道的会比较迅速。

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

    • 我们采用的方法是从用户的角度出发,来决定哪些功能是主要的,哪些是附加功能,哪些是可有可无的,从而排出功能的优先级,来决定哪些是必须在Alpha阶段完成的功能,哪些又是可以推迟到Beta阶段完成。
    • 根据我们项目的实际情况,我们首先实现的是项目的主要功能。“必须实现”的功能包括了:每日的收入、支出情况,当月账单的显示,账单的修改、删除及账单的查询功能。完成这些功能之后,我们的项目就可以运行,可以实现用户的需求了。而其余的功能就是可以推迟的功能,我们就可以放在Beta阶段在实现它们。

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

      有,我们的项目基本能满足用户记账的需求,包含记账,修改,查询,删除的功能都能使用。

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

      可以的,就像这次冲刺过程中,我们环境搭建就出了问题,导致我们几乎浪费了一周的时间,眼看时间要来不及了,我们小组成员一致决定更换开发平台,改成做微信小程序,原本的项目根本内容不变;能够及时作出变更决定,以至于我们团队终于在期限内完成了我们的项目。

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

      可以。虽然目前还没有遇到意料之外的工作请求,但是我相信我们队员的能力,以及大家团结在一起的精神,什么困难我们都能克服。

    5. 设计/实现

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

      开发初期,我们队员约定先按最简洁的设计来做,但是大致风格要一致,到后期风格再统一设计美化;我们队内有很适合美工的成员,后期能很好地完成设计工作。

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

      我们的设计工作基本上是按照原型设计来走,基本符合预想,虽然也有碰到过模棱两可的情况,但是经我们队内讨论后都能统一意见。

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

      由于我们是做微信小程序开发,使用微信web开发者工具,其本身就可以实时测试代码,所以没有用到其他工具。

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

    • 没有什么功能性的bug(可能是由于我们的项目太简单了。~)
    • 发布之后发现的bug
      • 页面高度设置失误,导致有的手机显示时可以上下滑动
      • 输入备注时,整体框架往上跑了
      • 查询页面没有提示用户点击哪里选择日期
    • 对于页面高度这个问题,我们设计时是有考虑的,不同机型可能情况不同,但是没有一个根本的解决办法;日期选择这点是我们欠考虑了,会改进的。

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

      一开始写了代码规范文档,编写代码过程中有疑问都可以去查看;代码复审是边写边进行的。

    6. 测试/发布

    6.1 团队是否有一个测试计划?

      有的,事实上由于我们使用微信web开发者工具,我们可以实时进行测试,通过不断测试,然后修改达到我们想要的结果。

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

      我们团队并没有进行正式的验收测试,没有客观的用户和测验人员来进行这项工作。

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

      团队有测试工具来帮助测试:优测网的云真机、微信开发者工具的测试。

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

    • 团队是如何测量并跟踪软件的效能的
      • 首先总结代码实现过程中自己找到的bug,
      • 然后以用户的身份来使用软件,并根据实际运行情况找出明显的bug ;
      • 其次进行场景测试,对比当初的需求分析,看团队是否实现了核心功能,抓住了用户的痛点;
      • 在不同的平台测试软件;
      • 使用测试软件测试。
    • 从软件实际运行的结果来看,这些测试工作的作用:
        有用,这些测试结果可以直观的表现出软件是不是“好”
    • 可进行的改进:
        测试应该尽可能的覆盖所有的情况。

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

      我们的软件的发布是发布到微信平台的,就是将我们Alpha阶段的最终版本提交后进行审核,审核完成后就可以发布,这过程中并没有出现意外。

    7. 总结

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

    • 我们团队目前的状态 处于CMMI阶段。
      • 在Alpha冲刺阶段,我们通过码云管理项目代码,分配任务,每天会开站立会议向组长汇报自己的工作量以及工作进度,组长由此知道整体项目的进展,决定接下来项目的发展。
      • 在Alpha冲刺阶段之后,团队有了类似项目的开发经验,一定程度上可重复类似项目的软件开发。

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

    • 我觉得目前团队已经经过了萌芽、磨合的阶段,现在处于规范的阶段。
      • 经过Alpha阶段,团队的每一个人都互相了解,PM分配任务也会考虑每个人不同的情况,根据每个人的强项去安排。

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

    • 经历过一次敏捷流程以后,我们对于软件工程比较了解了,不像之前只是纸上谈兵。
    • 有了一些项目开发的经验,在接下来的Bate冲刺阶段,不会很慌张。

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

      目前最需要改进的是功能方面。在接下来的Bate阶段,我们要增加一些其他的功能,例如扇形图。

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

    • 我觉得我们小组做的最好的是:
      • 1、尽早并持续地交付有价值的软件以满足顾客的需求。我们在一周的时间里实现了一个有价值的软件,也就是项目的MVP版本。
      • 2、业务人员和开发人员在项目开发过程中应该每天共同工作。团队所有人员每天都要一起工作,并连续7天开站立会议,展示项目的进展,决定项目接下来的发展。
      • 3、以有进取心的人为项目核心,充分支持信任她们。团队以PM和主要开发人员为核心,其他队员作为辅助人员,围绕她们的思路进行进一步的开发。由少部分人带动其他的人。
      • 4、无论团队内外,面对面交流始终是最有效的沟通方式。每日站立会议中,我们会轮流发言,说出自己所负责任务的进展以及遇到的问题,其他团员帮忙解决问题,这样就可以高效率完成项目。
      • 5、试试总结如何提高团队效率,并付诸实践。团队每天有固定的时间来完成项目,这段时间是这样分配的:首先用半个小时或一个小时审核昨天的代码,剩余时间才开始写今天的部分,这样后期代码复审就简单很多。

    8. 团队会议照片

    9. 成员贡献

    名字 角色 团队贡献排序 可验证的贡献 团队贡献分
    郭雅芳 前端 1 账单显示界面
    月支出、收入计算
    账单的删除
    账单的修改
    写博客
    27
    谭燕 前端 2 收入、支出的账单记账界面
    整体和各个界面的UI设计
    写博客
    26
    徐婉萍 PM 3 账单的日月年三种查询
    授权界面
    服务器和数据库的搭建
    跟踪任务进展
    写博客
    25
    李香荣 前端 4 登录和注册界面 14
    罗邓宇 复审者 5 代码复审 8
  • 相关阅读:
    9.11 eventbus
    9.10,,,实现new instanceof apply call 高阶函数,偏函数,柯里化
    9.9 promise实现 写完了传到gitee上面了,这里这个不完整
    9.5cors配置代码
    9.5 jsonp 实现
    9.5 http tcp https总结
    9.3 es6 class一部分 and es5 class 发布订阅
    8.30 cookie session token jwt
    8.30vue响应式原理
    warning: LF will be replaced by CRLF in renard-wx/project.config.json. The file will have its original line endings in your working directory
  • 原文地址:https://www.cnblogs.com/coolgirls/p/9030824.html
Copyright © 2011-2022 走看看