【WHAT TO DO】:
1. review what happened, find out why, and what can we do better in the future.
2. be frank, direct, and positive; no finger-pointing. Focus on what we can improve, not whose fault it is.
3. have someone record the meeting notes. And sum up after the meeting, publish it to your team blog, including the following:
a) What went well? Why?
【Answer】
成功之处:顺利地完成了alpha版的iLifer的基本功能,并且吸引了不少用户的注意(blog的访问量增长了不少)。
原因:软件比较有用,可以和Google方便地同步。
b) What was particularly problematic? Why?
【Answer】
问题之处:很多功能的UI不直观,使得用户不容易发现(比如summary)
原因:UI设计没有考虑到用户友好性。
c) What should have been done differently?
【Answer】
需改进之处:每天的工作需要渐进地完成,不能靠在deadline前赶工完成。
d) What planned results did you successfully accomplish / fail to accomplish? Why?
【Answer】
完成的功能:
未完成的功能:
原因:对UI的设计不够完善,同步部分由于Google API限制,对代理的处理很麻烦。
e) what would you do differently in Beta stage?
【Answer】
beta时期不同之处:
**********************************************************************************
Detailed Discussions
1. [Planning / Goals] Did you have a clear problem definition, and typical user scenarios?
【Answer】
我们在开始工作前就对iLifer的功能进行了明确的定义(iLifer项目介绍:http://www.cnblogs.com/SE-team-2011/archive/2011/04/10/2011162.html),同时对典型用户以及典型场景进行了详细的分析(iLifer典型用户和典型场景介绍:http://www.cnblogs.com/SE-team-2011/archive/2011/04/16/2018262.html)。
在已经release的alpha版本中,已经实现了部分的iLifer功能。
2. [Planning / Goals] How does your team resolve differences among team members? List some examples and discuss why it’s a success or failure.
【Answer】
当有问题产生时,大家通过互相讨论,比较各自观点的优缺点之后,选择一个最优的方案;如果没有一方能说服对方,就按照“少数服从多数”的原则make decision。
比如:在beta版本设计的初期,我们曾经想过将iLifer进行全屏显示。在这个时候,组内产生了以下的矛盾。
支持全屏的观点:“全屏”和google calender更接近,符合用户习惯,同时能显示每周、每个月等的appointment,并且可以实现更多功能;
反对全屏的观点:这与iLifer的轻量级的初衷相违背,并且除了可以按照周看之外没有其他优点,同时实现难度较大。
最后经过大家反复讨论以及和老师的商量,组内一致认为“全屏”不是一个好的功能,因此果断“杀”之。
3. [Scheduling] How much of your planned work was done? How much was postponed to later? Why?
【Answer】
根据我们的alpha项目时间表(http://www.cnblogs.com/SE-team-2011/archive/2011/04/10/2011162.html),三大功能以及基本实现。
4. [Resources] Have we scheduled enough testing time/resource?
【Answer】
由于一开始的进度比较慢,导致最后几天赶的比较累。在beta阶段要改变这一点,合理安排时间。
5. [Change Management] Was the exit criteria defined clearly enough?
【Answer】
没有充分考虑退出情况,在beta的时候需要考虑。
6. [Design/Implementation] Which area/feature had most bug? Why?
【Answer】
Google 同步部分。
原因:由于Google API理解不够,并且有时候由于网络等原因常常出现各种bug。
7. [Testing] Did you have a test plan? If not, why?
【Answer】
有test plan。
原因:石礼昕同学先制定了一些test case,然后根据这些写出了testcase的生成器。
8. [Teamwork and communication] How is the team formed?
【Answer】
一些比较熟的同学,在开学之前讨论好一起组成一组,之后还找了另外的几个不同年级的同学。
9. [Teamwork and communication] How did “leader” emerge from the team members?
【Answer】
大家怂恿的。。。。