homework10

Tsinghua Advanced Software Engineering 2011 – POSTMORTEM@Alpha Stage
 
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?

        我们的网站是基于实体经济的，经管方面的创业团队已经采取手工统计的方式将这个项目运行了一段时间。
b)     What was particularly problematic?  Why?

　　　用户界面有待改进，用户登录和注册系统有待完善，用户体验有待提高，还有一些安全漏洞有待修补。
c)     What should have been done differently?

        同上
d)     What planned results did you successfully accomplish / fail to accomplish?  Why?

        完成：可以订水果，价格数量等信息可以正确地入库和出库，注册系统能保留简单的用户信息。

        未完成：见b
e)     what would you do differently in Beta stage?
 　　 每天严格按照Work Item的计划实现，不临时抱佛脚
here are some questions to help your team discuss (you don’t have to cover all of them).
 
Planning / Goals
Did you have a clear problem definition, and typical user scenarios?

我们的定义是一个基于一个现在已经运行着的水果定期配送服务的网站。
Do all team members know the team’s goal and use the goal to guide other activities?

是的
What should have been done during planning, but wasn’t?

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

一般有效，因为分配任务和协调工作组织得不是很好，这方面以后要有待改进。
How does your team resolve differences among team members?  List some examples and discuss why it’s a success or failure.
 让适合的人去做适合的事情。例如董沛对django很熟，就去处理django相关的底层。刚总对django不熟，但有test的经验，所以做test。
Scheduling
How much of your planned work was done? How much was postponed to later? Why?

可以订水果，价格数量等信息可以正确地入库和出库，注册系统能保留简单的用户信息。

用户界面有待改进，用户登录和注册系统有待完善，用户体验有待提高，还有一些安全漏洞有待修补。

Did you do any work that was later abandoned or unnecessary or had minimal impact due to changed plans?

一开始读了不少cookies代码，学如何写注册系统，后发现可以直接使用。

数据结构一开始设计的也有些冗余
Was there enough risks management thru out the project?
 没有很大风险，因为实体项目已经在运营。
Resources
How were the tasks estimated? How can we improve our estimates?

学习时间与制作时间
Have we scheduled enough testing time/resource?
是的 

Change management
Did changes occur late in the milestone?  If so, why?
【回答】：很多时候是的，毕竟每个人都是在设计自己以前从来没有做过的东西，所以一开始实现的时候并不能很准确地估计出这

些工作的难易程度。往往到最后有一些貌似简单的功能很难实现，而一些原以为困难的功能却很容易地处理掉。所以最后估计的计

划和最后的产品有所出入也是情理之中。
Were changes communicated to you and other members in a timely manner?
【回答】：是的，因为我们定期有组会，每一次组会的时候，PM都会把最新的进度同步给大家。
What processes were used to decide which features to postpone and which were ‘must-haves’?
【回答】：我们必须使用用户的标准来衡量，很多时候采用自底向上的办法来做取舍。比如在我们的购物网站中，我们会事先想出

最简单的网站是什么样子，然后再在此基础上一步一步地设计增加的功能。
Was the exit criteria defined clearly enough?
【回答】：没有很清楚的定义。
  
Design/Implementation
Are the right people doing the design at the right time?
【回答】：这个问题很难回答，我们只能够按照事先制定的方案，一步一步地做，何为right people，何为right time，本来就是

事后诸葛亮的词汇。
Was there any ambiguity about certain design? How do you solve it?
【回答】：每个设计实际上都模棱两可，因为毕竟这不是数学。比如交互流程需要哪些环节，顺序如何，logo怎么设计，网站布局

怎么建立。这些问题其实每个人都有不同的见解。直觉和决断这个时候显得尤其重要。在初期，有的时候必须斩断犹豫，坚定地做

出一个初稿，然后再在可用的初稿上做改善，这样才能够真正地敏捷地直击问题的核心，而不是在模棱两可的设计上面浪费不必要

的时间。
What is the most difficult feature to implement? Why?
【回答】：security（安全）是最难的feature，因为作为一个网站，如果我们想把它发布，让它实际有用，那么在复杂的互联网环

境之中，我们必须让服务器百折不挠，能够在各种恶劣的环境下坚持工作，鲁棒而高性能。而由于互联网环境的复杂性，这个工作

是无止境的黑洞，所以我们只能尽我们所能，在有限的时间和资源精力之中做到最好。
Did you use unit test, TDD, UML, or other tools to help your design/implementation? How effective it is?
【回答】：暂时没有，因为我们网页的特点，以及大家使用的编程工具的特性，使用这一些工具对我们来说过于困难，甚至繁琐而

无用，所以作为一个course project，我们并没有采用如此高级的技术。
Which area/feature had most bug? Why?
【回答】：服务器端，因为服务器端要处理各种异常的输入，容忍各种网络攻击，而且还必须支持复杂地管理功能，并且在和UI的

交互过程之中需要做大量协调的工作。所以我们整个alpha版本的绝大多数精力都放在了服务器端的开发上。
Were code reviews conducted?  Was coding standard strictly followed?
【回答】：我们采用group programming的模式，code reviews在每一个人完成代码编写，交给其他人阅读的时候自然就完成了。编

程模式有一个大概的定义，但是实际中每个人在执行的过程之中难免有所简化。
 
Testing
Did you have a formal acceptance test?
【回答】：暂时没有，但是如果需要的话可以在很快的时间制定。formal的acceptance test需要网站正式上线，并且可以长期在稳

定的服务器上运行，这样test可以做稳定性和负载的测试。
Did you have a test plan? If not, why?
【回答】：半成品，对于需要测试的部分基本有了雏形，但是每一部分测试到什么程度还需要研究。具体来说，test plan需要包括

对网站整体的测试和对网站内部结构的测试，但现在无法对网站内部结构进行很完整的测试，原因是内部代码一直处于修正之中。

所以test plan主要在外部测试上，这样的测试alpha版本上已经做了基本的一些，可以参见当时的博客。
Did you feel that you had all the necessary tools to test code?
【回答】：基本有。现在没有automatic testing program。所以没有可以利用的tool，但alpha版本时用的test是各种浏览器的自

带功能。
How did you track the performance of your program?
【回答】：实事求是，诚实之上。performance的测试原计划是测负载，但当时的网站架构比较简单，用code来一直访问，却没有找

到performance的上限。
 
Teamwork and communication
1.    How is the team formed?
【回答】：我们根据通讯距离最短，通讯成本最低，友情至上的原则，选择了相邻寝室的同学，大家平时交流颇多，感情相对深厚

，拥有着其他队伍难以具备的同甘苦共患难的精神。在这样的精神的引领下，我们很自然地组成了一个志同道合的队伍。

2.    How did “leader” emerge from the team members?
【回答】：领导必须要有其独特的人格魅力，要在关键时刻挺身而出，为同学为组员承担责任，所以说很自然地大家选择了人格健

全值得信赖的人作为leader，而这样的人选在平时日常生活之中早已出现在每个人的心中。

3.    How did you go thru forming/storming/norming/performing stages?
【回答】：我们循序渐进，遵循新想法产生的客观规律，一步一步脚踏实地，首先使用集体brainstorm，记录下所有可能的idea，

完成自顶向下的一个模型构建，然后我们自底向上，一步一步积累实践经验，估计每一个模块的完成度，据此最后制定方案。即使

这样，有的时候我们所做的东西也不一定正确，所以在最后实现的过程之中，我们仍然需要根据实际情况进行调整。

4.    How is status, change, new request communicated to all team members?
【回答】：我们通过邮件，如果邮件不行就发短信，如果短信不回就打电话，如果电话不接就找本人的方式确保我们任何的信息都

能够达到每一个队员。

5.    If your team has absent-minded team members, how did you get them back on track?
【回答】：我们队的每一个队员都对于我们的工程抱有一定的热情，所以即使有队员暂时没有把时间和心思完全放在工程上，他们

其实也是有各自的客观原因。只要保持每周的组会，而且让每个同学诚实地说出难处，并且不要过于责难他之前的不作为，保持整

个队伍的团结，客观原因消失之后，每个人自然就能够回来。