我心中的敏捷(2)----我们的实践

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明: 本文可以不经作者同意, 任意复制, 转载, 但任何对本文的引用都请保留文章开始前三行的作者, 出处以及声明信息. 谢谢.

引言:
第一篇文章，说到了敏捷方法论和世界观的问题，看似有点玄了，其实，任何一个可以坚持下去的人或者任何一件可以坚持作下去的事，它的背后，都一定有一套自己的逻辑体系在支撑，而这个逻辑体系，就可以看作是它作事作人的方法论．敏捷二字, 其含义有两层: 高效率, 高质量. 其目的也绝不仅仅在于"快"研发, 它的终极目的, 是推动整个产品或者公司团队加速面向市场提供好产品的速度和质量. 在这一篇文章中，将会详细谈到我们自己的具体作法，当然，这已经是一年前的文章，很多作法可能已经因应现在的形势进行了改进，但基本的思想已暗含其中。你的作法可能与此不一样，但任何已经学会驾奴开发过程的同仁应该都会明白这些作法背后的含义。

正文:

敏捷开发, 最最主要的, 是要理解敏捷的本质是什么? 在我看来, 敏捷的本质, 很简单: 如何快速出东西, 快速的出质量高的东西.

由此, 我认为开发过程中的所有东西, 都应该围绕着这两个主题展开: 快速, 质量.

写程序写了这么多年, 我们大家可能都有点感受: 写得越来越没感觉了, 写得越来越麻木了. 因为, 随着自身的成长和成熟, 很多开发过程中会出现的常规难题, 被我们一一攻破, 似乎在我们眼前的路, 已经没有了太多的挑战, 技术难度的挑战.

为什么会有这种感觉? 在这里, 我要毫不客气的指出: 那是因为你把自己仅仅当成了一个有任务就作, 无任务就闲的技术人员, 而非产品人员. 当你把自己定位成一个产品人员之后, 你才会知道用户需求是如此多而复杂, 我们还有如此多的事要作, 要去作得更好.

什么是技术人员? 什么是产品人员?

我给一个狭隘的解释:
技术人员, 就是只泡在技术的单纯世界里, 而不太注重用户感受以及用户体验的人, 他们把攻克一个技术难题当作是对自己能力最大的肯定;
产品人员, 是指从产品出生到投放, 都一直能为用户考虑, 为用户着想, 在每一个细节上让用户爽而不是让开发者自己爽, 他们把用户口碑当作是对自己能力最大的肯定.

那么, 我们要作什么样的人? 要作什么样的技术人?

对于一个研究院所, 他可以选择成为一个单纯的技术人员. 但是, 如果放在绝大多数直接面对市场的大中小企业里, 他就必须选择成为一个从产品角度考虑的技术人员, 要让自己成为产品人员.

我坚持认为, 技术有没有价值, 不是靠别人推荐, 不是靠专家认证, 也不是靠发了多少研究论文, 而是技术本身有没有在创造价值, 有没有很好的在创造价值. 我是一个彻头彻尾的实用主义者, 我鄙视所有的学院派.

马云说: 找人, 首先, 要找价值观相似的人. 而什么样的价值观才是相似的?

马云, 从一个企业管理者的角度, 认为跟他价值观相似的应该是这种人: 进入阿里, 就要想着长期耐得住寂寞的作下去, 作对社会有推动的有价值的事, 不要只想着钱, 不要只想着干几个月就走人.

而我, 除了认同他的这些观点之外, 想在招技术人员方面额外加一点: 我们不要学院派. 我把这一点同样视为价值观是否相似的一个基本考核点, 单纯的学院派, 不适合来我们团队.

在网易, 我们的团队, 是一个狼性文化十足的团队, 这在现今的网易, 可能是一个非常独特的特例. 但是, 我们正用自己的成绩, 效率和质量来证明着自己. 没有狼性文化的团队, 注定无法成长; 而没有狼性文化的公司, 也注定无法壮大.

我先介绍一下我们的作法. 在我们这整个项目中, 配备了接近10名程序, 5位QC(质量测试), 近10位策划. 根据项目内容, 分成了五个小组: A, B, C, D, E. 平时的工作, 是将整个项目内容拆解, 各个小组平行推进. 这是我们总体的人员分配.

我所在的组, 是D组, 我们的程序有两位, 一个客户端, 一个服务端, 其他人员: 一个QC, 一个策划. 我们组共计四人. 我们小组, 从7月份开始, 接手作游戏内的一个比较大的群体系统: 势力系统. 这是比公会系统更为庞大和繁杂的系统, 是将来带动玩家互动的主要系统之一. 在接手这个新系统时, 我就在尝试一种新的开发方式.

原来的开发方式是:
策划人员出策划案, 程序将策划案实现, QC对已经实现的系统进行测试.

我们现在的方式是:
策划人员出策划案, 所有人员对策划案进行流程模拟, 找问题, 程序开始带着QC一起设计, 程序将系统进行实现, QC对系统可行测试.

而更具体的步骤是:

1. 策划出案子;

2. 所有人员(程序,QC)通读案子, 各自模拟流程进行推导, 看有没有破绽及断层之处, 提交策划人员进行修正; 修正完后, QC开始进行测试用例设计.

3. 程序制定数据包协议, 对协议进行走读: 向其他程序, QC以及策划讲解这个数据包过来之后会如何进行处理,包括要进行的判断, 要作的逻辑, 以及广播包要发的玩家对象范围. 这一步, 最大的好处, 是让每个参与者都明白我们的逻辑底层到底是如何走的.

4. 程序设计关键数据结构, 这一步, 是带着QC一起作. 一个程序功能, 就两点: 数据结构+算法. 而首先, 最主要的是决定采取什么样的数据结构, 数据结构进一步决定了采取什么样的算法. 这个数据结构, 其意义已经超出程序代码本身, 这个数据结构会牵涉到QC, 牵涉到策划. 在我们这个项目中, 数据结构最主要的内容就是各种各样的配置表, 这个表的内容应该含有哪些内容, 这些内容应该如何组织和约定, 就成为提高程序,QC和策划工作效率的一个重要环节.

5. 程序对功能进行逐块实现. 但在这里的实现, 也会有多种不同的方式. 我们的作法是: 先实现最基本的功能, 让客户端和服务器端能尽快联调起来, 然后各自发布一个基本流程版本给对方: 客户端给服务器端发布一个可用的客户端, 服务器端发布一个可用的服务器给客户端, 两个人分别用这个可用的版本进行各自的细节完善.

6. 程序实现功能后, 按照QC之前设计的测试用例对自己作的程序进行自测. 由于时间及专业有限, 这种自测, 主要是测关键逻辑及易错部分, 全面的覆盖性测试还需要依赖QC人员自己完成.

7. 程序自测完成后, 带QC及策划人员进行代码走读, 将产品正式交付QC进行测试. 之所以在这个环节加入代码走读这一项, 其目的也只有一个: 让项目的每一个参与者, 都能非常清楚程序底层到底是如何实现的. 这一点, 对QC进行全面测试非常非常重要, QC在进行代码走读之后, 可能会对当初的测试用例进行修正. 当然, 这里的代码走读, 还是具有一定技巧的, 因为QC和策划毕竟不是专业的技术人员, 对于算法和太深层次的技术细节可能并不容易理解, 所以, 这里的走读, 要作到既能让他们能理解关键逻辑, 也要让他们不要因为无法理解众多技术细节而出现过多的懊恼情绪, 这也会影响工作效率.

8. QC第一轮测试完成后, 策划人员对已经实现的功能进行游戏体验, 提出修正和完善意见.

以上, 就是我们在实际开发中所采用的一套完整的方式. 其核心思想有几点:

1. 让项目的每一个参与者, 都成为项目本身的主人. 这种主人翁思想的植入, 是通过让他们每个人都参与到项目的各个环节中, 让他们每一个人都仔细了解项目的每一处细节实现来体现.

2. 将QC的优势发挥在开发设计期, 而不是后面的交付期. 因为到了交付期, 其实, 产品已经出来了, 如果到那时发现问题要进行修改, 其带来的代价将远远大于开发期的修改. QC的测试用例, 以及"测试式思维", 是对程序人员固有思维方式的一个非常有利的促进和监督.

我们的开发方式还在不断的总结和完善中, 还有很多很多我认为非常有效的方法和感悟想和大家分享, 在下篇文章中再接着谈。