1. 每个成员在beta 阶段的实践和alpha 阶段有何改进?

Yuchen Zhang:

由设计者思维逐渐转变为用户导向思维.

Botao Hu

寻找了更不错的工作场地和设备。

Dong Wang

Alpha阶段的实验工作，帮助了Beta的服务器的重架构。但重复劳动很不爽。

Mu Yang

分工的模块化更强

Zhouyue Su

项目的代码有了更明确的架构。

Yi Yang

由于人多，对合作性的要求更高

Yu Liu

比Alpha更深入了iOS的开发。

Yitao Gao

Beta学习了iOS的开发。

2. 团队在beta 阶段吸取了那些alpha 阶段的经验教训?

1. Alpha的方式是每个人开发自己的部分，并且没有结构设计。最后合并起来非常凌乱。

Beta由架构师，设计好了整个代码的结构。由相应的人填入各自的部分，最后合并起来比较方便。

2. Beta 开始采用Pair programming的方式。就是每次找需要整合的两个开发者来，一对一的编程，找到问题点，现场解决。而Alpha阶段采用的是整个队伍一起合并，其实效率不高，不是所有人同时都是有事做的。

3. Beta 有一个大的 Office 能保证，我们的工作有一个相对稳定的环境。

4. Alpha中最大的问题是进度很拖沓。Beta其实也有一样的问题，并且也没有很好的控制。

5. Alpha中人多，干活的人不多。在Beta中，这个问题暴露的更加明显，因为成员更多，交流成本非常的高。PM为了更好的控制进度，往往要比Alpha花更多的时间沟通开发者。

3. 12 条敏捷开发的原则中, 团队做得最好和最不好的各列举 2 点。

最好的两点：
(1)  在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

非常认同这个观点。邮件和文档，虽然是很明确的沟通方式，但往往使得人们缺乏激励和激情。面对面的交谈，通过问答和讨论的方式，能使交谈的人对项目的需求和架构更加了解。

(2)   围绕被激励起来的人个来构建项目。
往往我们采用1-2个主要的人来负责架构，这些人清晰整个项目的架构，并且其他的开发者，可以围绕他们的思路进行进一步的开发。由少部分人带动其他的人。

最不好的两点：
(1)   敏捷过程提可持续的开发速度。敏捷过程提可持续的开发速度。

由于大家的时间都不是很多，也不是很集中，所以通常是在一段时间（比如一个周末）突然有了大量的进度。其他时间没有什么进展。

(2)   经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。

直到每次Release前，我们还并没有一个完整的可以运行的程序。我们没有把工作很好的迭代执行。

4. 对照 The Cathedral and the Bazaar (大教堂和集市), 你的团队开发模式是哪一种, 优势/劣势在哪里?

我们团队的开发模式在Alpha阶段是大教堂模式。因为在最后发布以前，我们并没有公开的渠道向用户和其他开发者沟通。在Alpha发布以后，我们得到了一些来自其他组的开发者的反馈，开始重新架构我们的软件。（有点Bazaar的感觉，但不完全）

大教堂模式的好处

(1) 需求不太容易变动。军心稳定。大家比较不迷茫。

(2) 内部的开发者交流比较充分。并且整个源代码，由一个团队管控，比较没有风险。

大教堂模式的坏处。

(1) 没有激励去 Release Early, Release Often。这导致我们Deliver的非常晚。

(2) 没有很好的倾听用户的想法，在功能点的选择取舍上，比较自以为是。

在The Cathedral and the Bazaar 文章中提到了这么几点，我们还最的不够：

(1) Release early. Release often. And listen to your customers.
(2) The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.