第六次团队作业——Alpha冲刺之事后诸葛亮

设想和目标

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

  • 做出一个手机应用,在地图上记录图片与随笔。目前的团队的描述应该比较详细。有,在说明书里已经做出介绍。

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

  • 有,计划确定现阶段方向。但是组织时间讨论计划是一个很麻烦的事。

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

  • 讨论,谁有理,谁更有说服力。

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

  • 组员,多交流,多讨论,多沟通,能够减少很多麻烦。
  • 计划要变通。
  • 功能描述要详细,不能模棱两可,会导致很多麻烦,加大工作量。

计划

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

  • 没有,对自己的预估过高,低估了困难。时间安排上,时间剩余有些不够。

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

  • 学习上,认为要先大致学习一边,可是当下手时却不知如何动手,学习还是需要一边doing一边学

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

  • 没有,很多知识还在学习,还不能做到每个都有详细解释。有关这方面的习惯还不是完全,还需要提升。

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

  • 大致按着时间流程来的,但是在服务器阶段稍微有些拖延。对服务器的工作量低估,对自身能力的预计也不够。客户端编写,没有尝试结对编程,尝试是否会提升效率。

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

  • deadline的期限会提前,不能顶着最后期限,要留下变通的余地。
  • 服务器段的编写会提前,客户端的编写尝试结对编程。
  • UI设计的任务也会提前进行。

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

  • 任务安排,通知上,会更加有效的措施。
  • 多思考,采用更加有效的方式,不要执着于细枝末节。

资源

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

  • 关于知识上,是足够的。但是时间上,需要看个人安排。很大程度上靠个人自觉性。

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

  • 基本上是各自负责人估计,精度不高。任务分发下去,需要负责人自己决定怎么实行。

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

  • 测试的安排,有些滞后,因为接触到测试的时间就偏晚,相关知识也不全;不过都在学习,多练多学难度自然会低。

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

  • 要提升组员自觉性,团队不是单靠一个人或者几个人就能成的,太执着于团队感,很容易被忽视。
  • 测试的模块需要在每次编写时,就布置下去,尽量培养习惯。
  • 提升每个人的共同感,这个是团队项目,不能马虎,一个人马虎,可能让很多人跟着受累。

变更管理

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

  • 能,但是这边也有看不看,做不做的问题出现。

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

  • 早期设计,说明书已经详细说明功能。核心功能必须实现,根据版本,可进行推迟。

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

  • 任务分配下去,是由负责人决定的。除非要检查时,才会有不一样的意见。

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

  • 有,询问组员,讨论方案,是否能够解决,怎么解决。

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

  • 能,这个需要组员自身的调控。自身认为是否需要添加额外工作。

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

  • 决定团队能力的因素有很多,需要每个人努力。
  • 任务分配上,需要强硬,选择效率高的。

设计/实现

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

  • 在初期,进行项目讨论,设计时,就已经在说明书中进行详述。最终样式,会由UI人员决定。

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

  • 有,这个就需要通过多次询问,详细描述,明确定义。

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

  • 有,目前还符合使用要求。

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

  • 规范已经确定,但是复审由于时间原因,还没有开展。

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

  • 代码编写,测试要及时,能够确保后面的项目进行,不会增大之后debug的困难。

测试/发布

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

  • 没有,因为不被组员重视。

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

  • 还没有,都是个人使用后,说明有什么不当。

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

  • 有,个人都有响应的工具。

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

  • 个人使用后,说明,简述,查看是否符合要求。

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

  • 测评工作的任务,要强硬安排
  • 检测汇报的进度要跟上,不要增加工作量。

总结

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

  • 团队目前刚结束第一次真正的团队项目计划,这一切都是新鲜的,很多对我们来说都是未知的,都是需要学习的,都是在摸索中一步步走向目标。

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

  • 目前处于萌芽阶段,毕竟才刚接触团队项目,很多能力还不是成熟,都是摸着石头过河。

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

  • 团队正式接触一个项目的开发,学习的更多,看到的更多,更加有底气。

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

  • 团队交流,团队合作,要不然会有种有任务关系到自身时靠团队,无所谓时,各自做。
posted @ 2016-11-24 21:55  606notconnected  阅读(168)  评论(1编辑  收藏  举报