第五组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控制上落后于集市模式。

  集市模式:  一种并行的、对等的扁平化开发接口参与者大多来自于互联网上的志愿者,结构松散、来去自由。

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

采用这样的模式,我们的优势在于项目骨架清晰,设计目标明确,项目完成效率高。可以说完成的过程比较的流畅。

但劣势在于离实际观看用户太远了,不能够更加贴近用户的需求,随时倾听用户的想法,包括功能点和整体软件使用感受等方面。导致设计出来的用户比较切合验收发,但不是很

切合观看用户。

 

 

posted @ 2018-08-01 13:45  ustc_吉利  阅读(198)  评论(0编辑  收藏  举报