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

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

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

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

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

切合观看用户。

 

 

转载于:https://www.cnblogs.com/ustc-fb/p/9400632.html