标签：
1. 每个成员在beta 阶段的实践和alpha 阶段有何改进?
|
成员 |
Beta阶段的实践和alpha 阶段有何改进 |
|
余江伟 |
beta阶段较alpha阶段对相关技术更为熟悉，效率更高。 |
|
张 晨 |
beta阶段较alpha阶段对结构和算法的理解更为深刻 |
|
朱 晶 |
最重要的显然是更加好看了，我最喜欢的还是换主题颜色的功能，很简单但是效果很不错啊。 |
|
王知睿 |
beta阶段对测试的方法和工具理解更好，使用更加熟练 |
|
陈 雪 |
为团队贡献了定时提醒功能 |
|
洪 锴 |
beta阶段的实践：做了添加单词拼写，把雪姐做的定时提示加了进去 改进: 对代码更熟悉~ 理解更好.. ps: 我也喜欢新加的换肤~ |
|
庞 俊 |
对测验功能的理解与64位系统可能出现的问题理解更为深刻 |
|
欧阳云 |
beta阶段尝试了新的测试工具 |
2. 团队在beta 阶段吸取了那些alpha 阶段的经验教训?
在alpha阶段中，对功能的需求分析不够仔细，没有很好的了解真实用户的需求。Beta阶段结合了身边背单词的同学的需求，加入了按List浏览和即时复习的功能，统计了用户的近期表现，删除了较不相关的小游戏功能。
最好的两点：
(1) 工作的软件是首要进度度量标准。
我们非常认同这个衡量标准并在实际项目执行中很好地应用了这个标准。由于在beta阶段添加的代码耦合性没有第一阶段那么大，应用这个标准能够更加清晰地反映工作的进度。
(2) 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
起初，我们打算通过应用MVVM模式进行开发，PM把设计文档都写好，然后让组员实现。然后在实际过程中发现这个方法并不是最适合我们的。因为我们对WPF技术并不是很熟悉，与其因为整体框架所需知识的学习而拖慢进度，不如采用成员之间互相交流互相学习的方法迭代式地开发。
最不好的两点：
(1) 敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
Beta阶段由于客观原因没能做到按照恒定速度开发，出现过加班加点的现象。
(2) 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
面对在beta发布后反馈的安装不方便的问题，我们得到了一个教训：应该尽早地让客户使用我们的软件，从而了解最需要改善的地方。软件工程不仅仅是写代码，其中还涉及很多为人处事的道理需要我们去领悟。
我们团队的开发模式在alpha初始阶段更倾向于做成封闭的教堂，然后在实际开发过程中慢慢向集市方式转变，所以我们认为更倾向于集市模式。
采用这样的模式，我们的优势在于能够更加贴近用户的需求，随时倾听用户的想法，包括功能点和整体软件使用感受等方面。
劣势在于我们没有太多的时间思考关于项目骨架的问题，在“大教堂和集市”文中提到的以下两点上做得还不够好：
a) 健壮的结构远比精巧的设计来得重要。换句话说，结构是第一位的，功能是第二位的。
b) 保持项目的简单性。设计达到完美的时候，不是无法再增加东西了，而是无法再减少东西了。
在以后的项目中，还是需要尽早考虑一些关于结构的问题，应对敏捷开发中需求的变化。
标签：
原文地址：http://www.cnblogs.com/KaMiSaMaGroup/p/5585807.html
