postmortem报告【第二组】

一.alpha阶段的经验教训

1.针对 进度规划不到位，任务完成速度慢 的问题，引入teambition规范任务管理，每周组会验收上一周任务，发布下一周任务，对各组员是否完成任务以及完成质量进行评价。

2.针对 与用户接触不够多 的问题，在原有的组内自测，少量邀请外部用户测试的基础上，增加组外用户的测试次数，即测即改，也根据用户反馈的需求，适当增减开发内容，调整开发计划，在项目基本完成时邀请用户，完成用户报告。

3.针对 与旧版BBS相比，亮点不突出 的问题，在完成BBS核心功能基础上，开拓额外功能，重点放在提高用户体验，便于用户间交流上，完善了用户界面，用户互相关注的功能，增加了聊天功能，具体参见Beta版本展示博客。

二.敏捷开发的原则

做的最好：

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

1. 要欢迎变动的需求，即便是在开发的晚期也不例外。敏捷过程利用变更来为客户获得竞争优势。

针对测试中出现的问题，和与用户沟通了解的信息，我们一直到开发晚期，也在尝试改变，增添新的功能。

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

2. 向开发团队及在开发团队中传达信息的最有效率和最有效的方法是：面对面的交谈。

除了每周组会，我们组主要的开发方式是几人聚在一起，一边讨论一边开发，面对面的高效率传达信息，推进项目。

做的最差：

Business people and developers must work together daily throughout the project.

1. 业务人员与开发人员每天工作在一起，直到项目结束。

由于其他的学习任务，实际的各种因素，这一条难以做到。

Working software is the primary measure of progress.

2. 可工作的软件是进度的首要度量。

由于本项目不易划分成单个可工作的部分，在最后整合前，都难以做到这一条。

三.The Cathedral and the Bazaar (大教堂和集市)

• 大教堂模式（The Cathedral model）：源代码在软件发行后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的。作者以GNU Emacs及GCC这两软件为例。
• 市集模式（The Bazaar model）：源代码在开发过程中即在互联网上公开，供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例，亦引用fetchmail的开发为例。

我们主要采用的是市集模式，在项目的一开始，我们便将源代码上传到Github，供人检视和开发，实现让够多人看到源代码，错误将无所遁形”（Given enough eyeballs, all bugs are shallow），在本课程结束后该项目也将作为开源项目，交由有兴趣的组员或者他人，继续完成。