租车App第一次迭代报告

项目:基于Android的汽车租赁平台——快租车APP

设想与目标

  1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
    • 产品定义:提供给租车公司的用户使用的租车app
    • 典型用户:有驾照,经常进行工作或商务活动的人士
    • 典型场景:出差人士需要驾车出行
  2. 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?
    • 原计划功能:做出app,实现用户登录,注册,租车,还车,充值等实用功能,并且设置后台管理界面
    • 实现情况:基本实现功能
    • 交付与用户:无
  3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么? 
    • 未交付使用,所以没有用户量
    • 离目标更近了
  4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
    • 大家对app的理解不同,我比较喜欢线性布局,相对布局这些,队友用的约束布局,在合并的时候,重写了一遍布局,所以下次一定要沟通好要用的技术

计划

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

         是的,一开始有两周的时间去做迭代开发计划,做了3个版本,同时还不断改进数据表

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

    团队讨论,互相说出自己的道理

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

    是的

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

    有,我在设计布局的时候和队友出现冲突,所以后来合并的时候队友重写了布局

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

    是的,在迭代开发报告中写清楚了

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

    没有什么意外,android和java web虽然比较花时间,但是学起来比较顺利

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

    没有

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

    暂时没有

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

    我学到了关于android的很多知识,同时也了解了很多后台的代码,包括jquery,servlet等
    历史重来一遍,我们应该更明确的分工

资源

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

有,其实并不需要什么资源,至少目前为止

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

大致估计猜测的,然后边做边修改

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

测试的时间还好,有一周,人力也足够,目前还没有考虑UI设计

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

没有

 

变更管理

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

大致是的,但是有时候突然发现一个bug,可能通知不及时,没有在群上讲,就直接改了

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

必须实现的功能是第一次使用必要的,比如登录注册,租车还车,充值

推迟的是附加功能,比如地图,常见问题,地图,延长租车等

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

我认为是将实际需要的功能都完成,然后使用比较简单,bug少就可以做好了

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

暂时没有

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

可以,我觉得大家对学习的热情很高,即使突然改需求,也能很快上手

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

做的时候要考虑到随时变更的需求,所以在设计的时候一定要注意封装,降低耦合性,提高代码可重用性

 

设计/实现

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

在比较前期大概第4周的时候,有大家开会讨论决定的,比较合适的时间

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

目前我觉得没有

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

使用了uml工具,绘制了类图,时序图等,帮我们理清的思路,开发更有针对性,还有腾讯工蜂,方便记录大家的进度

4、比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?

是有比较大的修改,比如类图等,主要是在设计数据库和java代码时发现原来设计的不合理的地方,所以修改了很多uml图

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

目前没有,但是我觉得可能在android连接数据库那块有bug,因为那里集中了比较多的线程,线程比较容易出错

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

目前还没有代码复审

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

在做事前,先画好图,理清思路是很重要的,磨刀不误砍材工

测试/发布

  1. 团队是否有一个测试计划?为什么没有?
    • 目前还没有测试计划
  2. 是否进行了正式的验收测试?
    • 暂时没有
  3. 团队是否有测试工具来帮助测试?
    • 没有
  4. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
    • 没有
  5. 在发布的过程中发现了哪些意外问题?
    • 还没有发布
  6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    • 在测试这一块暂时没有学到什么,不过按照老师课上的内容,我们也是在边开发边测试,调试bug

团队的角色,管理,合作

  1. 团队的每个角色是如何确定的,是不是人尽其才?
    • pm统筹安排,我写的android,有3个Android开发人员,两个后台,我觉得大家都做出了自己的贡献
  2. 团队成员之间有互相帮助么?
    • 有。
  3. 当出现项目管理、合作方面的问题时,团队成员如何解决问题?
    • 通过团队讨论解决的。

总结

    1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
      • 我觉得接近了CMM/CMMI中的可重复级(Repeatable)
    2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
      • 磨合。
    3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进? 
      • 大家的水平都有较大提高,而且功能实现得比较漂亮
    4. 你觉得目前最需要改进的一个方面是什么?
      • 代码写得比较冗余,在Android中大量的代码重复
    5. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 
      • 我们每周都会有开会,计划接下来的内容,其实我们已经做了比较多第二期的功能,所以接下来大概会比较轻松

 

原文地址:https://www.cnblogs.com/chen-song/p/10100403.html