Postmortem报告

Postmortem报告

1、每一个成员在beta阶段的实践较alpha阶段的改进：

陈修远：

所谓软件工程，相比于普通的编程来讲，是一个功能众多，内部逻辑复杂的工程项目。经过一学期的现代软件工程实践，我发现想作好一个好的软件，清晰的产品模型规划是十分重要的。在开发前必定要想清楚，须要开发的一个项目是怎样的。对整个项目进行怎样的删改都会对代码形成极大的影响。能够不须要想清楚每个细节，可是涉及软件核心的逻辑与功能必须想清楚，不然，后患无穷。

 

傅咏淦：

我我的关注较多的仍是技术层面吧。我的以为技术选型之于软件工程是很是重要的一部分，选用的开发工具最好容易上手但能有必定的深度，最好还能有好的开发文档和社区。这样说来咱们先后端所用的工具都是特别好的，让咱们的开发如虎添翼。

 

李浩冉：

在数据库方面，咱们发现alpha阶段的数据库创建的过于冗杂，其实使用flask自带的sql库对数据库操做很简便，让数据表及元素增长并非一件很好的事，因此在beta版咱们减小了表和元素的数量。在代码的实现方面，咱们增长了id与token，在先后端对接时增长了安全性与保密性。

齐天浩：

本学期软件工程的团队项目经历了alpha版本和beta版本两个阶段，这两个阶段的开发过程给我留下的感觉是大相径庭的。由于在alpha阶段在考试周附近，因此咱们仅仅是在较为集中的几天以内进行项目的开发，虽然咱们的beta阶段也是在必定的时间内集中进行开发，可是咱们的开发周期相对来讲比较长（毕竟暑假期间的事情相对较少）；并且，咱们在开发时没有后顾之忧，不用担忧考试的影响，能够全身心地投入到项目的开发之中。此外，alpha版本的先后端交互相对较少，beta版本涉及到了更多的交互，所以，更须要组内成员的交流与沟通，这无疑对咱们组是很大的挑战（三人是美国时间，三人是北京时间），然而，这并无影响咱们项目的进度，各位成员都或多或少地为了项目牺牲了本身的休息时间，这让我感到很欣慰，我对各位队友也很感激。

徐楠青：

我以为一个很明显的改善就是你们使用GitHub的次数也上升了很多，使得咱们的代码管理获得了大大提高。还有一点是前端的分工更加细化，目前采起制做界面—完备功能—美化—测试等步骤，让前端的工做更加高效有序。

尹童欣：

我在β阶段主要是负责界面美化工做。在α阶段咱们组由于界面不美观失分较多，因此就由我和美工一块儿负责界面美化。经过一系列的努力，再加上网络上丰富的资源做为参考，咱们组成功完成了对界面的美化。

 

2、团队在beta阶段吸收alpha阶段的经验教训

首先，好的界面是成功软件的一半。Alpha阶段咱们前端绘制的界面虽然具备基本的功能，可是美观程度不忍直视。在beta阶段咱们在美工同窗和组员的合力下将界面的美观性大大提高。

其次，咱们在alpha对于GitHub的使用不积极使得代码的交流，更新，修改变得不方便，而且有着较大的隐患存在。在beta阶段中，小组成员系统学习了git的使用方法，并且规范了代码的交互流程，使得小组开发的效率有了显著提升。

再次，咱们在先后端交互方面显著增长了交流的次数。使得先后端可以更为流畅地进行对接。不只如此，咱们还对先后端的某些接口进行了封装，在简化操纵流程的同时也方便了对于出错的调整。

 

3、敏捷开发原则中团队作的最好&最差的两点

首先细数敏捷开发的十二条原则：

（1）咱们最重要的目标，是经过持续不断地及早交付有价值的软件使客户满意。

（2）欣然面对需求变化，即便在开发后期也同样。为了客户的竞争优点，敏捷过程掌控变化。

（3）常常地交付可工做的软件，相隔几星期或一两个月，倾向于采起较短的周期。

（4）业务人员和开发人员必须相互合做，项目中的每一天都不例外。

（5）激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

（6）不论团队内外，传递信息效果最好和效率最高的方式是面对面的交谈。

（7）可工做的软件是进度的首要度量标准。

（8）敏捷过程倡导可持续开发。责任人、开发人员和用户要可以共同维持其步调稳定延续。

（9）坚持不懈地追求技术卓越和良好设计，敏捷能力由此加强。

（10）以简洁为本，它是极力减小没必要要工做量的艺术。

（11）最好的架构、需求和设计出自组织团队。

（12）团队按期地反思如何能提升成效，并依此调整自身的举止表现。

咱们组认为咱们在“（6）不论团队内外，传递信息效果最好和效率最高的方式是面对面的交谈”和“（7）可工做的软件是进度的首要度量标准”方面作得不是太好。前一点必定程度上是因为组员的年级和学院不一样形成的，不过也有一部分缘由是组内对于面对面交流不是过重视致使的。后一点一方面是由于咱们做为软件开发方面的小白，对于软件开发的流程和工具的使用不很熟悉，致使进度划分不是太清晰。另外一方面咱们在开发项目的初期阶段对于进度度量的意义不太明确，使得忽视了这一方面的评估。

可是咱们组认为咱们在“（5）激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。”和“（12）团队按期地反思如何能提升成效，并依此调整自身的举止表现。”这两点上作得至关不错。究其缘由，有如下几点：首先，咱们组虽然面对面交流的次数很少，可是线上交流和代码方面的交互仍是比较频繁的。其次，和谐融洽的团队关系让每一个组员在咱们组可以充分发挥本身的实力，相互信赖使得咱们可以达成更为理想的目标。最后，时常反思（尤为是相互之间交流本身的经验和教训）让咱们组每一个成员得以及时调整本身的开发状态，提升开发效率。

 

4、团队开发模式和优点、劣势品评

咱们组的开发模式基本是基于The Cathedral （大教堂）模式开发的。在优点方面，咱们可以精心地规划咱们项目所须要的大部份内容。不只如此，咱们还可以系统地调节整个项目的进程，合理分配时间，而集市型的。在劣势方面，The Cathedral （大教堂）模式开发的项目在开发过程当中，是很难接收到外来的意见和建议的，因此说开发过程当中踩坑比较频繁。再者，就开发时间和成原本说，“集市”较“大教堂”更为低廉，更适合于敏捷开发。

Eric Raymond这样看待大教堂和集市之间的竞争：“我认为，将来会更多地属于那些告别大教堂、拥抱集市的人们。这不是说我的的远见和才华再也不重要；而是在我看来，将来的成功者只是从本身的远见和才华开始工做，而后经过有效的社区合做，将其不断地放大。开放式的文化会最终胜利，这或许不是由于"开放"在道德上正确，或者‘封闭’在道德上错误，而只是由于开放式合做能够在一个问题上投入多几个数量级的技术工时，封闭的世界没法赢得这样的竞争。”

虽然业界的大师这样看待，但咱们并不这么认为。开放和封闭式的开发的确没有对错之分，并且开放式开发有着庞大的群众基础。可是现实生活中有不少项目因为某些缘由是没法开源的，封闭不时刻意味着保守，有些时候反却是安全的表现。此外，咱们能够设想，若是当某个问题上投入高出几个数量级的人员都收益甚微时，人们将会寻求从头精打细算的方式，将集市的砖瓦细细叠放。开放和封闭并不天生对立，二者不过是一种开发方式，在将来的软件工程中，相信咱们会愈来愈多地看到二者混成的开放方式。毕竟咱们的目的只有一个——开发出优质的软件。