由于将会要组织一个全新的研发团队,而且可能团队中讲会以年轻人为主,应届毕业生尤其巨多。
我觉得这是一个尝试全新的开发模式的好时机,但是当然需要平稳过渡。首先,我们都没有敏捷开发的经验,其次,敏捷开发所有的概念也未必完全适合团队,需要动态的来寻找结合点。
1. 简单设计及重构
首先需要较为严格的确立工程的概念,我比较欣赏“简单设计”这个原则,但是不完全赞同。
系统刚开始整个架构还是应该细致设计,而之后每个模块的详细设计应该是经常勇于重构,经常有新的想法。而重构的实现实践也是要在不影响软件交付的前提下进行。
归根到底总结就是:有度的迭代。
2. 自动化测试
其次,自动化测试也是需要逐步普及的,特别是核心功能模块,但是关于如何构建可测试代码,这是一门需要钻的很深入的学问,我也将在之后的时间内亲自先实践这一点。我现在的疑惑主要是:
测试用例细到什么级别,如果是功能性模块需要若干个模块集成或者数据库特殊环境支持,是怎样来编写测试脚本的?这样脚本编写开销是否特别大?
3. 持续集成
这个是基于自动化测试已经成熟的基础上的,我想我现在对于这点暂时没有发言权。当然,我也会要深入细心学习,不过我觉得在相当长的一个时间内,小的团队、项目还是用不到做到持续集成的。
4. 代码公有化
在敏捷开发中,这不是版本库权限这么简单,而是一个所有人都必须对整个工程每个模块熟悉,或者整个工程代码风格和设计高度统一,我觉得在团队成员都不是一等一的高手,并且项目代码量较大的情况下,实施起来比较困难。
5. 结对编程
我一直认为,核心模块可以使用结对编程。前提是能够很好的估计工作量,定时定性的分派任务。但是普通工作还是不要使用结对了。
6. 例会
重构经验交流、敏捷开发体验交流、自动化测试心得交流,需要在各个例会中脱离业务层,来深入商讨我们的整个团队研发模式。
7. QA团队
那么测试人员在研发期间的参与度就比较低了,QA人员只负责项目最后的功能验收。一定要让QA团队和研发团队和睦共处,不能有“敌对”的关系,这样才不会出现BUG被踢皮球的现象。