对第一个milestone工作的postmortem

 

由于不是所有的问题对我们团队有很高的价值，所以不对所有的问题进行回答了，只是选取一些合适的问题进行回答和分析。

1.     Did you have a clear problem definition, and typical user scenarios?

回过头来看这个问题，简单的一张族谱图似乎能表达的信息很少，我们的user story变的很不清晰，比如对于资深专家，桃李满天下，搜搜看我的学生们都在做什么，取得了哪些成就，关注一下他们的研究现状。但是从这张学术族谱图上能马山表达出来吗？所以为了能够到达这些vision，接下来的milestone将对功能进行部分的更新和设计。

2.     Was team discussion effective? If not, why? What can you do differently next time?

 

我们组的交流还是很不错的，对于一些特定的问题，只有相关的人员会去讨论。一般情况：当出现一些问题的时候，PM会组织相关人员讨论，大家会积极的提出自己的建议，经过激烈的讨论而达成共识。

 

3.     How were the tasks estimated? How can we improve our estimates?

 

这个还是存在很大的问题，在milestone1开始的时候，大家对将要做的事情不是很清楚，估计的时候只是凭空想想，没有一些根据，所以估计的结果出现了很大的偏差。比如一个同学发现在最后做的事情和之前几乎计划的几乎没有一样的。但是对于milestone2而言的话，我们会在planning阶段把应该做的事情都想好（大家一起来想），做出比较准确的估计。

 

4.    Were changes communicated to you and other members in a timely manner?

这个也是我们在之前那个milestone做的不好的，有一些dev会按照自己的想法修改feature，并且没有通知其他组员。所以下一个milestone，我们尽量做到一旦有feature修改，就马上让相关的人员知道。

 

5.     What processes were used to decide which features to postpone and which were ‘must-haves’?

这个也是我们在milestone1做的不好的地方。在一定接下来的milestone中，如果有人有新的想法或想放弃一个feature，会组织相应简单的会议进行讨论，并且在前期讨论中做的全面一些，尽量减少changes的出现。

 

6.     Did you have a test plan? If not, why?

我们有相应的计划，但是不是很好。tester不明确功能需求，功能的定义知道的不是很清晰。在下一个milestone中，我们会让tester一起加入我们的前期feature的讨论，并希望其能站在用户的角度提出建议。最后基于前面的讨论设计plan。

 

7.     How is status, change, new request communicated to all team members?

这是一个很关键的问题，组员之间的交流决定了接口能否较快的工作，feature能否较好的满足用户的需求等等。目前我们小组在部分问题上讨论很仔细，比如接口设计，但是在feature改变等一些问题上做的不是很好。所以下阶段在保证工作进度的前提下，会相应的增加组员之间的交流，朝着共同的方向前进，争取做出更好的软件。

 

 

 

 

 

转载于:https://www.cnblogs.com/ustc_msra_ase/archive/2011/01/17/1937798.html