Postmortem报告
Postmortem报告
一、每个成员在beta阶段的实践较alpha阶段的改进：
陈修远：
所谓软件工程，相比于普通的编程来说，是一个功能众多，内部逻辑复杂的工程项目。通过一学期的现代软件工程实践，我发现想做好一个好的软件，清晰的产品模型规划是十分重要的。在开发前一定要想清楚，需要开发的一个项目是怎样的。对整个项目进行怎样的删改都会对代码造成极大的影响。可以不需要想清楚每一个细节，但是涉及软件核心的逻辑与功能必须想清楚，否则，后患无穷。
傅咏淦：
我个人关注较多的还是技术层面吧。个人觉得技术选型之于软件工程是非常重要的一部分，选用的开发工具最好容易上手但能有一定的深度，最好还能有好的开发文档和社区。这样说来我们前后端所用的工具都是特别好的，让我们的开发如虎添翼。
李浩冉：
在数据库方面，我们发现alpha阶段的数据库建立的过于冗杂，其实使用flask自带的sql库对数据库操作很简便，让数据表及元素增加并不是一件很好的事，所以在beta版我们减少了表和元素的数量。在代码的实现方面，我们增加了id与token，在前后端对接时增加了安全性与保密性。
齐天浩：
本学期软件工程的团队项目经历了alpha版本和beta版本两个阶段，这两个阶段的开发过程给我留下的感受是截然不同的。因为在alpha阶段在考试周附近，所以我们仅仅是在较为集中的几天之内进行项目的开发，虽然我们的beta阶段也是在一定的时间内集中进行开发，但是我们的开发周期相对来说比较长（毕竟暑假期间的事情相对较少）；而且，我们在开发时没有后顾之忧，不用担心考试的影响，可以全身心地投入到项目的开发之中。此外，alpha版本的前后端交互相对较少，beta版本涉及到了更多的交互，因此，更需要组内成员的交流与沟通，这无疑对我们组是很大的挑战（三人是美国时间，三人是北京时间），然而，这并没有影响我们项目的进度，各位成员都或多或少地为了项目牺牲了自己的休息时间，这让我感到很欣慰，我对各位队友也很感激。
徐楠青：
我觉得一个很明显的改善就是大家使用GitHub的次数也上升了不少，使得我们的代码管理得到了大大提升。还有一点是前端的分工更加细化，目前采取制作界面—完备功能—美化—测试等步骤，让前端的工作更加高效有序。
尹童欣：
我在β阶段主要是负责界面美化工作。在α阶段我们组因为界面不美观失分较多，所以就由我和美工一起负责界面美化。通过一系列的努力，再加上网络上丰富的资源作为参考，我们组成功完成了对界面的美化。
二、团队在beta阶段吸取alpha阶段的经验教训
首先，好的界面是成功软件的一半。Alpha阶段我们前端绘制的界面虽然具有基本的功能，但是美观程度不忍直视。在beta阶段我们在美工同学和组员的协力下将界面的美观性大大提升。
其次，我们在alpha对于GitHub的使用不积极使得代码的交流，更新，修改变得不方便，并且有着较大的隐患存在。在beta阶段中，小组成员系统学习了git的使用方法，而且规范了代码的交互流程，使得小组开发的效率有了显著提高。
再次，我们在前后端交互方面显著增加了交流的次数。使得前后端能够更为流畅地进行对接。不仅如此，我们还对前后端的某些接口进行了封装，在简化操纵流程的同时也方便了对于出错的调整。
三、敏捷开发原则中团队做的最好&最差的两点
首先细数敏捷开发的十二条原则：
（1）我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
（2）欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
（3）经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
（4）业务人员和开发人员必须相互合作，项目中的每一天都不例外。
（5）激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
（6）不论团队内外，传递信息效果最好和效率最高的方式是面对面的交谈。
（7）可工作的软件是进度的首要度量标准。
（8）敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
（9）坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
（10）以简洁为本，它是极力减少不必要工作量的艺术。
（11）最好的架构、需求和设计出自组织团队。
（12）团队定期地反思如何能提高成效，并依此调整自身的举止表现。
我们组认为我们在“（6）不论团队内外，传递信息效果最好和效率最高的方式是面对面的交谈”和“（7）可工作的软件是进度的首要度量标准”方面做得不是太好。前一点一定程度上是由于组员的年级和学院不同造成的，不过也有一部分原因是组内对于面对面交流不是太重视导致的。后一点一方面是因为我们作为软件开发方面的小白，对于软件开发的流程和工具的使用不很熟悉，导致进度划分不是太清晰。另一方面我们在开发项目的初期阶段对于进度度量的意义不太明确，使得忽视了这一方面的评估。
但是我们组认为我们在“（5）激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。”和“（12）团队定期地反思如何能提高成效，并依此调整自身的举止表现。”这两点上做得相当不错。究其原因，有以下几点：首先，我们组虽然面对面交流的次数不多，但是线上交流和代码方面的交互还是比较频繁的。其次，和谐融洽的团队关系让每个组员在我们组能够充分发挥自己的实力，相互信赖使得我们能够达成更为理想的目标。最后，时常反思（尤其是相互之间交流自己的经验和教训）让我们组每个成员得以及时调整自己的开发状态，提高开发效率。
四、团队开发模式和优势、劣势品评
我们组的开发模式基本是基于The Cathedral （大教堂）模式开发的。在优势方面，我们能够精心地规划我们项目所需要的大部分内容。不仅如此，我们还能够系统地调节整个项目的进程，合理分配时间，而集市型的。在劣势方面，The Cathedral （大教堂）模式开发的项目在开发过程中，是很难接收到外来的意见和建议的，所以说开发过程中踩坑比较频繁。再者，就开发时间和成本来说，“集市”较“大教堂”更为低廉，更适合于敏捷开发。
Eric Raymond这样看待大教堂和集市之间的竞争：“我认为，未来会更多地属于那些告别大教堂、拥抱集市的人们。这不是说个人的远见和才华不再重要；而是在我看来，未来的成功者只是从自己的远见和才华开始工作，然后通过有效的社区合作，将其不断地放大。开放式的文化会最终胜利，这或许不是因为"开放"在道德上正确，或者‘封闭’在道德上错误，而只是因为开放式合作可以在一个问题上投入多几个数量级的技术工时，封闭的世界无法赢得这样的竞争。”
虽然业界的大师这样看待，但我们并不这么认为。开放和封闭式的开发的确没有对错之分，而且开放式开发有着庞大的群众基础。但是现实生活中有很多项目由于某些原因是无法开源的，封闭不时刻意味着保守，有些时候反倒是安全的表现。此外，我们可以设想，如果当某个问题上投入高出几个数量级的人员都收益甚微时，人们将会寻求从头精打细算的方式，将集市的砖瓦细细叠放。开放和封闭并不天生对立，两者不过是一种开发方式，在未来的软件工程中，相信我们会越来越多地看到两者混成的开放方式。毕竟我们的目的只有一个——开发出优质的软件。
