事后诸葛亮会议

事后诸葛亮会议:做个有效的项目总结。

 

设想和目标

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

我们组负责天气预报，功能领域定义的很清楚，典型用户和典型场

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

由于项目比较简单，计划时间不多，但已经足够。

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

在sm的带领下，大家基本没有不同意见。

4.如果历史重来一遍, 我们会做什么改进?

各个团队各自为战，导致团队做的功能有些重合，而且大家的数据结构有差异，

给代码整合带来很大麻烦，同时，软件的具体功能没有定义清楚，

　　1. 估计任务所用时间时，需要询问当事组员意见

　　2. 留给组员学习的时间

 

计划

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

　  没有但这个主要是因为开始各个团队没有协调好，主要我们的api接口不会做，耽误了很久

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

　　有，做了个分享界面，最后发现没地方用得着

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

　　任务在博客写的比较简略，但由于比较简单，大家都能明白。

　　4.是否项目的整个过程都按照计划进行?

　　大家的进度不一致，导致没有按计划进行，有点不尽人意

　   5.如果历史重来一遍, 我们会做什么改进?

　　1. 善用google英文搜索，多了解流行的开源解决方案，

　　2. 预留必要的缓冲时间，留给后期的整合。

 

资源

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

　　资源(书籍，开源解决方案，服务器，素材)非常充足

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

　　各项任务估计精度不是很好，因为任务是由Po估计的，而由组员完成，Po不知道组员对技术的掌握程度如何，有时候估计的任务不是很精确。

　　3.用户测试的时间，人力和软件/硬件资源是否足够?

　　不足。时间很紧迫。

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

　　没有。

 

变更管理

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

　　变更是由po通知组员，组员能够及时了解。

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

　　根据功能在整个项目中的重要程度

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

　　没有。

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

　　由于经验不足，不能够有效处理，但是大家在sm的带领下出色的应对了各项突发情况。

　　6.如果历史重来一遍, 我们会做什么改进?

　　1. 善用源代码管理，少用QQ互传文件

　　2. 多开碰头会，少通过短信通知

测试/发布

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

　　团队有明确的测试计划。

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

　　没有。。