第五组postmortem报告

第五组postmortem报告
为期近半年的软⼯课程顺利收⼯了。

这⼀个学期的⽹站制作中，憧憬过、懊恼过、兴奋过，回顾整个制作过程，我们按⽼师的要求来⼀份验⼫报告。

1. 每个成员在beta 阶段的实践和alpha 阶段有何改进?
尹宇飞：alpha:参与⽹站排版和⽹站内容的讨论制作⽹站浮窗结构
beta：根据反馈的内容，在⾏动上对⽹站的浮窗位置以及内容进⾏修改，对⽹站的排版进⾏修改
詹元成：beta阶段实际租⽤服务器、域名使⽤，对服务器配置和管理有了新的认识
学会对服务器的数据库进⾏维护
武松桦：beta阶段精细化了页⾯的设计。

更熟练掌握了页⾯结构的美⼯设计
学会了视频上传管理
王泽友：alpha:参与了⽹站页⾯形式设计和内容讨论，制作主页、成功案例、我们的优势⼏个页⾯的最初版本
beat:根据反馈的要求和意见，协助修改页⾯。

王亚正：belta阶段对代码bug进⾏调试，找出页⾯跳转失败等⽅⾯的问题。

加深了对对bug的调试和修改的理解
张军：belta阶段对博⽂的发表、与⽤户间的交流有了进⼀步进展
2. 团队在beta 阶段吸取了那些alpha 阶段的经验教训?
在alpha阶段中，虽然我们团队已经确⽴了⽹站的基本框架，并按照我们⾃⼰的理解设计了⽹站的样式。

（当然也是参照了许多留学机构⽹站）从感觉上来说我们应该是取其精华去其糟粕
⽤以提供给⽤户更好的体验，但交给验收⽅后它们还是提供了许多改进意见。

所以在beta阶段，我们果断换⽤新的设计⽅式，以验收发为主体，每次制作⼀个页⾯，由他们来提出改进意见，我们再改，如此循环，⼀直到他们满意为⽌。

从根本上解决了⽤户满意度的问题。

同时吸取了alpha阶段的教训，我们还会把设计给同班同学看，让他们提出宝贵的意见。

3.12 条敏捷开发的原则中, 团队做得最好和最不好的各列举 2 点地⽅
最好的地⽅：
1. 在整个项⽬开发期间，业务⼈员和开发⼈员必须天天都在⼀起⼯作。

软件项⽬不会依照之前设定的计划原路执⾏，中间对业务的理解、软件的解决⽅案肯定会存在偏差，所以客户、需求⼈员、开发⼈员以及涉众之间必须进⾏有意义的、频繁的交互，这样就可以在早期及时的发现并解决问题。

在我们的整个开发周期中，我们团队⼏乎每天都在⼀起讨论开发，并于验收⽅交互。

2.在团队内部，最具有效果并且富有效率的传递信息的⽅法，就是⾯对⾯的交谈。

⼤量的⽂档交流其实并不是很经济的做法。

此时⾯对⾯的交谈反⽽更快速有效。

因为我们的团队不⼤，寝室隔得不远，⾯对⾯交流很⽅便。

平时编程遇到bug，我们会跑到谁的寝室讨论；遇到设计上的分歧，将召开⼩组会议解决。

最不好的地⽅：
1.敏捷过程提可持续的开发速度。

责任⼈、开发者和⽤户应该能够保持⼀个长期的、恒定的开发速度。

在开发alpha之前，团队并没有做到在⼀起讨论如何完成，⽽是各⾃顾⾃⼰⼿头上的事，忽略了这个项⽬，以⾄于项⽬进展缓慢，博客更
新不够
及时。

2.即使到了开发的后期，也欢迎改变需求。

敏捷过程利⽤变化来为客户创造竞争优势。

改变需求是好事情，因为这些改变意味着我们更了解市场需求。

但在开发后期，我们团队没去改变需求。

项⽬进度有所停滞。

4.对照 The Cathedral and the Bazaar (⼤教堂和集市), 你的团队开发模式是哪⼀种, 优势/劣势在哪⾥?
以下是我对两种模式的理解
⼤教堂模式：传统⼤型软件公司的开发模式就像艰难缓慢的⼤教堂建造⼯程，有这严密的关机和封闭的集中式结构，在创新⼒、⽣产⼒和bug控制上落后于集市模式。

集市模式：⼀种并⾏的、对等的扁平化开发接⼝参与者⼤多来⾃于互联⽹上的志愿者，结构松散、来去⾃由。

我们团队的开发模式⼤体上为⼤教堂模式。

采⽤这样的模式，我们的优势在于项⽬⾻架清晰，设计⽬标明确，项⽬完成效率⾼。

可以说完成的过程⽐较的流畅。

但劣势在于离实际观看⽤户太远了，不能够更加贴近⽤户的需求，随时倾听⽤户的想法，包括功能点和整体软件使⽤感受等⽅⾯。

导致设计出来的⽤户⽐较切合验收发，但不是很
切合观看⽤户。