注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

大宝(sodme)的Blog

人生如戏, 梦一场; 岁月似歌, 任逍遥.

 
 
 

日志

 
 
关于我

执着, 务实, 勤于思考, 注重实效。我是大宝, 05年~11年2月在广州网易互动负责网游项目研发, 核心开发者, 网游行业六年从业经验, 主张并一直坚持实践研发+运营一体化产品观。工作内容涵盖:服务器研发/突发事件处理/产品技术攻坚、团队管理/培训、过程监控/改进、客服/运营管理等诸多方面。关注网游产品设计、研发、运营、市场完整流程构建和实践。现为创业公司项目合伙人。愿广结同道者, 共同进步。msn: sod_me@hotmail.com, mail&gtalk: sodme.dev@gmail.com

网易考拉推荐

我心中的敏捷(2)  

2007-09-09 12:02:32|  分类: 敏捷开发 |  标签: |举报 |字号 订阅

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

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

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

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

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

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

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

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

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

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

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

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

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

我先介绍一下我们的作法. 在我们这整个项目中, 配备了接近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的测试用例, 以及"测试式思维", 是对程序人员固有思维方式的一个非常有利的促进和监督.

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

  评论这张
 
阅读(451)| 评论(3)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017