事后诸葛亮(团队)

Posted laixl

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了事后诸葛亮(团队)相关的知识,希望对你有一定的参考价值。

设想和目标

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

帮助解决福大学生遇到的各种疑问,定义的算是清楚,有

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

并没有达到目标,原计划的功能大概完成了百分之七八十左右,现在还只是Alpha阶段,还没有交付时间。

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

现在完成的内容和预想还有所偏差,主要功能实现还有问题,当然离目标更近了。

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

设想的很美好,现实很骨感,在我们设想的初期想了很多可以加的内容,刚开始想的时候比较有激情,高估了自己,想到什么功能都一直往上加,然后后面在完成的过程中,发现实力跟想法相差悬殊,很多都舍弃了,没有开发经验,太天真。
如果历史重来一遍,会根据自己的实际能力去设想一些功能,不要是太复杂的那种,否则既耗时耗力了,又没有什么成效,这样对项目进度有很大的影响。


计划

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

时间肯定不会充足,没有人会觉得时间太多。在平时还有其他的课程要上,也不能把所有的时间都投入给软工实践,加上是第一次进行项目开发,所以我们的计划就不是很细致也不完善。

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

对于计划的不同意见,有进行相关的讨论分析,如果有反对意见会再进行商量,然后看情况整改。

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

没有。
一开始的分工没有特别明确,没有将功能模块分配到个人,每个人都集中在同一个模块,导致项目卡壳的时候每个人都没有什么新的进展了,没有经验,要花费的时间太多,一边学习一边做,一直有问题的时候激情就少了很多,进展就慢了,使很多原计划的工作没时间可以完成。

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

现在暂时没有吧。

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

定义的不是很清楚,一开始划分的任务都是一整个模块的大任务,没有细化到小版块,而每个人负责的也比较模糊,通常都是在完成的过程中才进行分配。

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

没有按照计划进行,计划的完成时间和实际的完成时间不一致,导致很多原定计划不得不推迟或者舍弃。andriod的页面跳转有点问题。风险现在还暂时没发现。

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

没有,课业太多,一般的时间都是在晚上,也没有其他空余时间可以挤出来了。
缓冲区可以在一些意外发生的时候减少对实际进度的影响。

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

可以增设计划缓冲区,然后将计划的分工内容细致一下。

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

一个良好的项目计划是很重要的,这样项目的执行过程也会更加有条不紊,有效率。
如果历史重来一遍,将对计划表做更详细的规划,分配好每一个环节,以及每个人负责的模块,每个人完成自己的模块后再进行整合改进,就不会出现一个环节停滞,所有人都一起停滞的现象了。


资源

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

现在任务量还比较小,资源还是够用的。

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

按照任务的分类来估计,如果是同一个模块相似内容用时就估计少一点,但是由于我们是Learning by doing,在某些任务上就经常会遇到瓶颈卡壳了,一开始是估计每天平均完成三四个任务这样的,但是现实却是有些任务花费了两三天研究才解决,或者还未解决,所以在各项任务时间的估计上精度不是大。

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

现在还没有进行测试,感觉人力上还是不够的,没有更加专业的人员,大家都是从起点开始一边学习一边完成的,力量还不是特别大。还好吧。

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

团队成员现在拥有的能力还是不够的,如果让能力更强的人来做,当然会更有效率。

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

合理分配好每个人力资源。


变更管理

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

有团队的群聊,消息传送很方便,如果是重大的变更,会讨论研究让每个相关人员都知道,如果只是一些细小的,只有负责该模块的人知道。

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

看功能的复杂程度,按照项目的计划安排,一般从使用app的习惯顺序来进行功能实现的排序,决定必须实现的功能,如果是一些比较复杂的模块,这个阶段感觉来不及完成的,就推迟了。

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

emmmm,没有清晰的定义,觉得实现的功能和预想的差不多,然后在测试环节没有什么出错,就感觉做好了吧。

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

尽自己所能制定。

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

经验不足,不能有效处理,耗费的时间较多。

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

在项目的完成过程中,肯定会发生一些意外,不得不对项目某些模块进行变更,但是处理却不够有效率。会先预想有什么可能发生的变更,制定相应的应急计划。


设计/实现

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

在项目开始的初期,由团队成员分工共同完成,要先设计再实现功能,所以时间应该合适吧,因为都是新手,所以合不合适还需要时间磨合。

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

没有遇到什么比较模棱两可的情况

3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么? 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?

还没有运用单元测试和测试驱动的开发。有利用UML帮助设计,将设计都梳理了一遍,但是在开发的过程中也很少利用它了,通过安排表完成任务更加清晰一些。UML文档没有什么变化。

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

现在功能内容还比较少,产生的bug主要是数据显示上有问题,代码方面有问题,在研究中。

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

现阶段还没有进行代码复审,代码规范上每个人都有自己的编码习惯,没有在一开始就制定严格的代码规范。

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

在实现的一开始就要制定严格的代码规范,在之后的整合过程中才能避免出现更多问题。


测试/发布

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

现在还没有测试计划,因为项目还没有开发完全,就没有去想测试的事情。

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

没有


团队的角色,管理,合作

1. 团队的每个角色是如何确定的,是不是人尽其才?

是在项目开发过程中慢慢确定的,边学边做,谈不上每个人有什么特别的才。

2. 团队成员之间有互相帮助么?

有的

3. 当出现项目管理、合作方面的问题时,团队成员如何解决问题?

分析问题,然后进行讨论,看问题出现的原因,商议后共同解决问题。

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

分配好每个团队成员的角色,对每个人的任务有清晰的定义,让项目的分工更加明确,才能更好的进行,加强沟通和交流。

总结:

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

CMM

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

磨合

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

团队每个成员的分工需要更加细致一些。

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

1、以有进取心的人为项目核心,充分支持并信任他们

我们的组长非常有进取心,我们非常支持信任她,组长经常用她的进取心来感染我们,鼓励我们继续前行!

2、无论团队内外,面对面的交流始终是最有效的沟通方式

在项目的开发过程中,我们每一天都有进行面对面的沟通交流,了解每一个成员所遇到的问题,并一起解决。


以上是关于事后诸葛亮(团队)的主要内容,如果未能解决你的问题,请参考以下文章

Alpha 事后诸葛亮(团队)

Alpha 事后诸葛亮(团队)

Alpha 事后诸葛亮(团队)

团队作业7——alpha阶段之事后诸葛亮分析

事后诸葛亮

事后诸葛亮(团队)