关于逐步实践敏捷开发的想法

由于将会要组织一个全新的研发团队，而且可能团队中讲会以年轻人为主，应届毕业生尤其巨多。

 

我觉得这是一个尝试全新的开发模式的好时机，但是当然需要平稳过渡。首先，我们都没有敏捷开发的经验，其次，敏捷开发所有的概念也未必完全适合团队，需要动态的来寻找结合点。

 

1. 简单设计及重构

首先需要较为严格的确立工程的概念，我比较欣赏“简单设计”这个原则，但是不完全赞同。

 

系统刚开始整个架构还是应该细致设计，而之后每个模块的详细设计应该是经常勇于重构，经常有新的想法。而重构的实现实践也是要在不影响软件交付的前提下进行。

 

归根到底总结就是：有度的迭代。

 

2. 自动化测试

其次，自动化测试也是需要逐步普及的，特别是核心功能模块，但是关于如何构建可测试代码，这是一门需要钻的很深入的学问，我也将在之后的时间内亲自先实践这一点。我现在的疑惑主要是：

 

测试用例细到什么级别，如果是功能性模块需要若干个模块集成或者数据库特殊环境支持，是怎样来编写测试脚本的？这样脚本编写开销是否特别大？

 

3. 持续集成

这个是基于自动化测试已经成熟的基础上的，我想我现在对于这点暂时没有发言权。当然，我也会要深入细心学习，不过我觉得在相当长的一个时间内，小的团队、项目还是用不到做到持续集成的。

 

4. 代码公有化

在敏捷开发中，这不是版本库权限这么简单，而是一个所有人都必须对整个工程每个模块熟悉，或者整个工程代码风格和设计高度统一，我觉得在团队成员都不是一等一的高手，并且项目代码量较大的情况下，实施起来比较困难。

 

5. 结对编程

我一直认为，核心模块可以使用结对编程。前提是能够很好的估计工作量，定时定性的分派任务。但是普通工作还是不要使用结对了。

 

6. 例会

重构经验交流、敏捷开发体验交流、自动化测试心得交流，需要在各个例会中脱离业务层，来深入商讨我们的整个团队研发模式。

 

7. QA团队

那么测试人员在研发期间的参与度就比较低了，QA人员只负责项目最后的功能验收。一定要让QA团队和研发团队和睦共处，不能有“敌对”的关系，这样才不会出现BUG被踢皮球的现象。