导航

第一次迭代开发总结

Posted on 2018-12-14 14:40  黄飞龙  阅读(128)  评论(2)    收藏  举报

设想和目标

  1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
    • 为高校学生开发的活动交流平台
    • 典型用户:在校大学生
    • 典型场景:建立社团、发布问题、组织活动......
  2. 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?
    • 原计划功能:安卓ios各自实现私聊关注等、微信小程序
    • 实现情况:
      • 私聊关注基本实现
      • 小程序对接未完成
    • 交付和用户:app部分可以使用但小程序不行
  3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
    • 未发布
    • 未完成全部
  4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
    •  二期开发虽然有现成的部分,但是和我们开发的部分关系不大,而且在原UI上的修改还需要注意冲突问题,后台的代码有的看起来可以复用,但实际做起来很麻烦,不好理解。

    • 如果重来一遍,不如重新做一个,比如把全部的工作放到做小程序上。

计划

  1. 是否有充足的时间来做计划?
    • 有充足的时间,却花费到无用的地方
  2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
    • 有讨论,但是各自平台不同,只能起一定的作用
  3. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
    • 团队整体项目推进艰难,源代码的理解都存在问题
  4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
    • 花费大量时间来看原项目的代码,很多部分是没设计或者不必修改的
  5. 是否每一项任务都有清楚定义和衡量的交付件?
    • 分工明确,但人力过于分散
  6. 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
    • 未按照计划进行,开发过程人员都在调动
  7. 在计划中有没有留下缓冲区,缓冲区有作用么?
    • 有缓冲区:迭代计划需求描述模糊,界面设计没有太详细的要求,可以省下一些精力
    • 非常有用
  8. 将来的计划会做什么修改?(例如:缓冲区的定义,加班)
    • 计划大幅修改二次迭代计划
  9. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    • 学到很多,数据库设计、环境搭建、各种框架使用等,再来一次打算一开始就找公司的开发人员了解需要学什么,并且一开始将源代码跑起来而不是直接去刚

资源

  1. 我们有足够的资源来完成各项任务么?
    • 没有完成项目,但资源还是够的
  2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
    • 没有特别去估计
  3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
    • 人力足够,但极度分散,资源足够,但使用存在问题
    • 没有美工,没有文案,实现都成问题
  4. 你有没有感到你做的事情可以让别人来做(更有效率)?
    • 可以,需要一个更有领导力的人,而且能力超强,然后让大家划水。
  5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
    • 调整人力分配

变更管理

  1. 每个相关的员工都及时知道了变更的消息?
    • 非常及时
  2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
    • 看进度
  3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
    • 没有
  4. 对于可能的变更是否能制定应急计划?
    • 并没有指定应急计划
  5. 员工是否能够有效地处理意料之外的工作请求?
    • 关键看网上的资料给不给力,公司的人配不配合
  6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    • 应急计划有必要

设计/实现

  1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
    • 一边设计一边实现,非常的糟糕
  2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
    • 讨论,或者先自行解决
  3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
    • 没有使用
  4. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
    • 前端页面存在bug,后来修复了
    • 后台bug踢皮球中
    • 开发的时候就发现了,但是公司的人说他们来修复,结果因为种种原因没有及时修复
  5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
    • 代码存在诸多不规范,反正能用就行

测试/发布

  1. 团队是否有一个测试计划?为什么没有?
    • 没有
    • 3个平台同时开发,各自测试不好计划

  2. 是否进行了正式的验收测试?
  3. 团队是否有测试工具来帮助测试?
    • 暂未考虑
  4. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
    • 暂未考虑
  5. 在发布的过程中发现了哪些意外问题?
    • 未发布
  6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    • 一个功能测试一次

团队的角色,管理,合作

  1. 团队的每个角色是如何确定的,是不是人尽其才?
    • 开始时各自选择,然后老师进行了一些建议,我就被安利了从未接触过的ios开发
  2. 团队成员之间有互相帮助么?
    • 存在一些帮助,前端设计和与后台的对接有共通的部分
  3. 当出现项目管理、合作方面的问题时,团队成员如何解决问题?
    • 进行一些交流,与后台的交流最为频繁但也最为费劲

总结

    1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
      • 不清楚
    2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
      • 还在磨合
    3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
      • 大家彼此更加熟悉,互相的配合会比之前更有效率
    4. 你觉得目前最需要改进的一个方面是什么?
      • 界面设计
      • 功能实现
      • 对接