“Six”成功法则

卡巴斯基实验室业已成为网络安全行业的知名全球企业，一路走来，卡巴斯基经历了无数重要里程碑，其中最重要的即是推出革命性的卡巴斯基反病毒软件6.0。此版本软件于2006年正式推出，不久就在全球反病毒市场上赢得了用户的交口称赞，为卡巴斯基在未来几年内发展成为技术领导企业奠定了基础。将我们的产品称之为是全球最佳反病毒解决方案未免有些过誉，但确实是许多杂志和独立基准测试实验室对我们的评价。

卡巴斯基的成功之路并非一帆风顺，而是布满了荆棘和坎坷，希望好莱坞编剧有一天能以此为素材拍一部电影，再现当时的情景；但在此之前，我们将通过最初开发团队的照片、备注和备忘录的形式来与大家分享我们的成功故事。希望我们的故事能对现在年轻一代的新应用和服务开发者们有所引导，只要像我们最初的”Six”开发小组那样怀揣着梦想，希望有一天成为业内的佼佼者，那么成功一定离你们不远。

困难重重的2003年

“Six”是从上一版惨败的土壤中开出的成功之花。事实上第五版从未见过天日，与当初设想的完全不同。

要了解导致这一惨败的原因，我们将时钟拨回2002年：当时Windows XP才不过刚刚上架销售；CPU主频终于达到1 GHz的时钟频率；反病毒行业相对年轻，还没有遇到各种全新的威胁。所有反病毒企业都渴望拓展产品功能：当时有竞争力的解决方案必须含有防火墙、持续运行的系统监视器和其它数十种功能。

虽然卡巴斯基开发团队早在上世纪90年代就构建了强大的扫描引擎，但他们也承认，该解决方案中装满了各种各样的新功能，导致运行速度极慢，让人无法忍受，甚至当时的V4.0也遭到不少用户的诟病（当时只要谈到有关电脑的话题，就免不了有各种类型的指责”卡巴斯基运行太慢”）。这就是为什么新版5.0的开发过程非常谨慎，考虑到了许多核心的业务要素：新首席技术官走马上任，采用了新的开发框架，并选择了新的反病毒架构。

当时是倾全公司之力为此项目提供支持。但一年后，我们得出的结论是，即便严格遵循所有这些新的开发规则，也不一定就能保证开发出具有竞争力的产品。开发出的这套系统仿效的是企业级客户端/服务器应用（架构由CTO亲自择定），但无法满足市场上对反病毒产品提出的各种要求。该系统速度慢，占用资源多，bug无数，且在团队运行测试后依然未有减少。事实上bug数量是不减反增。

“我开始向公司元老们征求意见。他们说这都是架构的问题。就像一座纸牌搭建的房屋一样：手忙脚乱地拆东墙补西墙，结果整个房子塌掉了。”尤金•卡巴斯基（Eugene Kaspersky）承认。所以继续按原样改进这个项目毫无意义。我们必须全盘推翻从头开始构建。

我们能做到！

卡巴斯基实验室开发团队兵分两路：一路不管选择的架构多么不合理，仍奋力修补产品；另一路则负责将上一版V4.0改造成适用的新产品。

与此同时，一支四人小组决定开发一款全新的产品，不仅要满足各种市场需求，而且永不过时。这一目标由”Six”开发团队设定，但说起来容易做起来难。新版本必须做到防范所有病毒和威胁入侵系统，同时要求速度快、灵活性强、透明度高，哦……还得外形靓丽。

“我们只是想做出一款前所未有的最佳产品，”Six开发团队回忆道。这个短小精悍的开发团队肩负着极重的任务，受到公司其余200名员工的关注。但迎战这一艰巨使命的小团队还是有理由保持乐观：公司创始人尤金•卡巴斯基和Alexey De-Monderik当时正在寻找新的替代架构，他们即将发现替代架构确实存在，而且不是别人，正是卡巴斯基团队自己开发的。

来自布拉格的帮助

必须承认，在V4.0中装有两个反病毒内核（即所谓的”引擎”），以捆绑软件的形式运行。文件检查则由能力出众的旧版（受到包括G-Data到F-Secure的许多跨国公司的大量许可）V3.0引擎负责。V3.0早在1996年就已开发出。加强网络流量过滤功能的新任务则由1998年在布拉格头脑风暴会议过程中设想出的全新强大机制来处理。

该引擎最终被称为”布拉格”，虽然事实上是由Andrey Doukhvalov在莫斯科开发出的。Andrey Doukhvalov当时并未参加在捷克共和国首都布拉格举行的头脑风暴会议。但关键性的想法是源于布拉格，所以Andrey来公司后绞尽脑汁，基于这些想法实施了”布拉格”概念。

“布拉格”意图成为纯反病毒内核，但为其设定的目标实在是雄心壮志，以致于新开发的这款引擎的灵活性和独创性完全能够支持更复杂的系统。就像Andrey和开发人员说的，能否基于”布拉格”来实施整个产品这个问题给卡巴斯基带来了沉重的压力。

“有一次我问Victor Matyushenko关于布拉格在产品内部的表现如何时，他说”像磐石一样坚固！”突破就在这里。我把刚才这个问题整理了一下，然后走进Graf [De-Monderik]和Petrovich [Doukhvalov]的办公室问了他们以下问题：”为什么我们不把产品整个基于布拉格呢？”Graf说了一些”布拉格不可能这样用”之类的话，但Petrovich犹豫了一下。第二天他来办公室时带了一小叠纸，然后和我说：”我基于布拉格编写了一些用例代码。”Graf抬头看看他说：”我们得谈谈。”他们俩谈过之后，又一起来找我，确定这值得一试。”

试验由一支非常精简的团队负责执行，是他们编写了日后成为”Six”产品的第一批代码。

“我们开始四处招人，希望找到有创造性，能献计献策的人才，他们就是这支团队的扩编人员。”De-Monderik回忆说。”比如编码员Pavel Mezhuev，他虽然是新手，但非常聪明。还有Mike Pavlyuschik，我们已经一起工作了很长时间。他能提出立刻能用的点子和概念。我想他是整个组中最有天份也是最勤奋的开发人员。”

经过两个月的自由、实验性质的编码工作，我们得出的结论是该项目将成为商用解决方案。现在我们需要一名项目经理。

“还记得隔壁办公室的Nikolay Grebennikov吗？他读书很多，年轻有为，是公司的新人。我们要他！”Andrey Doukhvalov回忆与De-Monderik的谈话时说。驱动程序软件工程师Andrey Sobko稍后将加入该团队。

“布拉格”是什么

本部分可能软件工程师更有兴趣。其他读者可选择略过不看。

上世纪90年代初，反病毒行业才刚刚兴起，当时就有一些病毒无法通过常规签名检测到。例如，有一种变形病毒每次感染时都会对其代码以不同方式进行加密，因此通过签名方法无法检测到这种病毒。随着软件越来越复杂，全球互联网渗透率急速攀升，恶意软件编码员从纯为找乐子转变成为市场提供相关服务，恶意软件变成了日益复杂的多重威胁。即便对于在基于签名的检测算法基础上另外增加了功能的引擎，比如卡巴斯基，开发人员也被迫不断更新反病毒软件，而不仅仅是更新签名数据库，以防万一遇到利用新原理的恶意软件。这些因素严重影响了反病毒软件对新病毒的响应时间，而卡巴斯基实验室成为业内第一个成功追击臭名昭著的CIH（Chernobyl）病毒的公司，这证明为了缩短响应时间，值得进行任何尝试。

考虑到这点，1998年卡巴斯基向员工建议，是时候去精心开发新的反病毒引擎了。那么他们究竟该往哪里走呢？

“公司当时资金短缺，”卡巴斯基说，”我们不得不在莫斯科附近寻找一个最便宜的场地，远离城市，远离噪声和上班高峰，集中精力来解决问题。这个地方还得整个断网。当时周围还没有任何Wi-Fi。结果最便宜的地方就是欧洲首府城市－布拉格。

通过对新反病毒引擎版本进行头脑风暴，卡巴斯基实验室团队得出了结论：面向对象的方法是引擎层的最佳解决方案，也就是说每个被分析文件或对象必须基于其结构进行剖析，内部的对象也得经过检测、分析和检查。对象管理从总体来看必须在运行时执行。

在对所有已有对象环境进行讨论后，剔除了其中不够灵活、占用资金过多或速度过慢的环境。在讨论过程中，一个想法浮出水面：开发我们自己的对象环境，自带内存管理功能和其他服务过程，使反病毒软件有能力更快、更高效地剖析和分析潜在的恶意软件代码。

这个重要的想法诞生于布拉格，由De-Monderik和Andrey Krykov提出，Doukhvalov和Kryukov编写的第一批代码为此想法提供了支持。

在一年时间里，由Doukhvalov主要负责继续细化”布拉格”－别忘了，这也是卡巴斯基实验室聘用他的目的。Dukvalov拥有丰富的架构专业知识，能确保”布拉格”灵活、伸缩性强、易于部署到产品中，而不会造成任何架构方面的局限性。最终，目标是构建一个多平台解决方案。

对象层次结构调试起来有一定难度，但通过一个使用方便的对象间消息交换系统和一个极简编程界面，能够将”布拉格”轻松集成到架构中，并适用的地方根据需要使用。

“它旨在用于组件方法，”Doukhvalov骄傲地解释说。”这意味着组件可以添加到现有程序中。系统具有极强的开放性，能够添加元素，更改其行为模式。”

基于组件的架构小巧紧凑，占用资源不多，可根据通用协议提供，成为向KAV 6.0引入一系列颠覆性新技术的基础。这些技术实施起来非常容易。此外，可对”布拉格”进行些微调整，使其成为整个产品的基础，而不仅仅是作为反病毒引擎，Pavel Mezhuev对微调架构做出了显著贡献。

“我们另外又实施了一个架构解决方案，用途是部署用于分隔业务逻辑和界面的模型。同样是由Doukhvalov和Mezhuev创建了一个任务管理器，此管理器能够控制产品内的任何单个进程，进程相互作用非常简单，”KAV 6.0项目经理Nikolay Grebennikov表示。

“Six”的原理

在试验和初期开发阶段的工作都是由很小的一支团队来完成，显然，繁杂的项目管理方法并不适用于这支团队。因此，实施了类似于SCRUM的项目管理方法：开发人员在开放空间工作，不断进行互动，这样他们很容易就参与开发过程的方方面面。这就是”Six”开发团队的工作方式。

SCRUM简介

SCRUM是一种项目管理方法，适用于灵活的软件开发环境。它基于以下原则：客户（用户）不一定确切知道自己需要什么，而且在开发过程中要求可能会变化。这意味着开发过程的特点是能提供多个结果型周期：构建 － 演示 － 分析反馈 － 更新版本。

在对SCRUM的角色分布进行了大量研究后，卡巴斯基定义了六个角色：

架构师

这是指积极参与编码过程，了解构建内容和构建方法的人员。

技术设计人员

对于此角色没有明确的定义，但此类人员负责确保为特定解决方案赋予生命力。也许更重要的是，技术设计人员必须知道如何禁止做某此事。

开发人员

开发人员应用非传统的解决方案来解决各种问题。对于”Six”，问题简直是层出不穷。该解决方案最终必须提供的是高水平的保护，但对计算机资源的占用量最少。

项目经理

在SCRUM中，项目经理的角色并未严格地预先设定监管内容。项目经理负责控制资源池和最后期限，但并不是直接领导。他不是命令编码员去做什么，而是激励他们自行进取。

“团队很小，一开始我们甚至都没有头儿，”Doukhvalov说。”经理负责计划和报告，但对项目本身所做的决策则是集体的智慧。”

市场经理

产品是针对用户，而不是针对开发团队本身开发的。因此了解潜在用户评判产品的预期，以及以何种方式使用产品就至关重要。虽然运行原理由了解反病毒功能性质的人员进行界定，但像设置、消息传递或用户界面等数以千计的小问题也必须将用户要求考虑在内。

心理辅导师

工作压力大，睡眠不足，组内冲突、不稳定性……这些问题的存在需要有人能确保工作环境友好、高效。这一角色分配给了卡巴斯基本人，这样他能够预测性地将这一角色与赞助人的角色结合起来，赞助人负责为团队资金和资源，保护他们不受外界干扰。

坦白说，SCRUM项目中还有一个角色至关重要 － 那就是负责记录过程的记录员。但此职位未安排任何人，而这导致了一些问题。

“我们不知道为什么会这样做，半年前就应该决定了，”卡巴斯基肯定地说。

根据这一原则，角色数不一定与团队成员数一一对应。一个角色可能会由多人承担，而一名队员也可能同时担任多个角色。

“既要保留正规的组织结构，又要作为一个团队行事，所以角色之间的界限模糊：尤其是做头脑风暴时，大家都会承担不同的角色，”Nikolay Grebennikov承认。”比如一个人是负责编码的，但同也能表达自己在设计方面的看法，而且这些看法会很有份量。我本身是项目经理，但也会参与讨论，所以角色界限的模糊确实为我们的成功做出了贡献，因为我们不会放过项目中的任何单一要素。”

根据De-Monderik的说法，编码员的可互换性相当高：”每个组员都是自己领域的大神，但往往一个人的技能中有一半是与另一个人重叠的。如果Sobko不在，Mike能给驱动程序编程，用户界面专家能够处理一些引擎相关任务，反过来也一样。我能替代Max Yudanov做一些设计工作，而Kolya Grebennikov有时候也能做一些设计工作。”

每个角色在项目执行的特定阶段都会处于领导地位，理解这一点非常关键。在开始阶段，架构师是核心人员。在开发过程的中期阶段，开发人员开始行动以设计并开发各项功能。在最后阶段，核心人物是经理，因为项目现在有许多资源，需要严格管理，使团队能够按期完成工作。

追求完美

考虑到”SCRUM”式方法和项目的总体宏伟目标，”Six”并没有任何静态的要求清单。根据基本要求，产品必须具备以下功能：

• 成熟完备，能抵御目前的各种安全威胁；
• 优化了电脑资源的使用；
• 基于组件的基础架构，伸缩性更强；
• 能够轻松在不同平台上采用组件。

 

基于这些元要求，对产品的相应技术要求经历了一系列的变化。结果，虽然发行时间不断推迟，但团队有能力开发出一款领先普通市场要求数年的革命性解决方案。它在速度上也优于之前的版本。

卡巴斯基反病毒软件6.0发布后，负责用户界面设计的Maxim Yudanov表示：”项目中一个关键的不同点在于没有”一成不变”的要求清单。我们制作原型、讨论产品、更新技术要求和功能列表，在黄色便利贴上摘记要点并贴在显示器上，剔除一些内容、保留一些内容，这一过程反复进行，还要求助于受众用户（我的意思是Beta版测试社区）。我敢肯定，如果一开始打算将工作基于传统的要求清单，那么我们最终的产品不可能像现在这样。如果我们是这样做的，那么最终开发出的产品只是我们一开始设想的。肯定地说，这样开发出的产品要比我们最终推出的产品差很多。”

极限编程

如今，这一方法并不新鲜了。但在10年前，将这种方法应用于大型项目是革命性的创举，彻底颠覆了传统。所谓的”极限编程”（此术语使用广泛，现在类似的方法全部统称为”灵活软件开发”）与官方命名的CMM编码法（现在几乎不再用了）之间的区别在于是否有传统的要求清单，就像几年前一度批准《圣经》作为项目工程的唯一基础一样。CMM方法可能适用于外包开发项目，但对于商用项目则没什么用处。

现担任卡巴斯基实验室首席技术官的Nikolay Grebennikov同意此说法：”如果我们一开始就列出固定的功能列表，而没有适当的变化，那么我们不可能开发出满足用户确切需求的任何版本，也别指望能从用户那儿获得如此程度的支持。第一版构建的可用性并不高，存在许多问题。为了解决这些问题，我们花了大量时间－从阿尔法版到技术发行版之间经过了五个季度。这是非常奢侈的事，现在已经不可能了，但在当时是非常有用的经验。”

卡巴斯基对此说得更直白：”开发创新项目时，就必须做好最终期限不断推后的准备。”

沉浸在工作中的生活

KAV 6.0开发团队的主要成员常常会怀念那段想家的时光。睡眠不足、没有时间陪家人、没有周末，情绪压力极大，通过进度和工作质量才能看到回报。

在项目开发期间，Nikolay Grebennikov曾写过一封电子邮件，其中颇具一些诗意：

“时间似乎停在某个点，一切只剩下项目。就像玩一个巨大规模和力量的游戏，你一头扎进云，从开始一直到结束始终身在其中。上班途中，坐在地铁上，回想着上次游戏保存的胜利和失败，然后又开始工作，想着该怎么玩才能攻克下一关。哄孩子上床后，你再次沉入游戏中，在那里，你有能力想像一切，一切皆有可能。”

“这实际上就是我的生活，”卡巴斯基回忆道。”眼中充满热情、便利贴、彻夜不眠的团队成员。就像煮着一锅热气腾腾的创意与行动浓汤。”

团队扩编后，开发组的核心组员将这一团队精神传递给了新人，对此De-Monderik回忆道：

“所有组员们都配合良好，我们必须依赖”核心组”的能力来激发热情。”核心组”有非常重要的创意，但也面临着挑战：开发出前所未有的最佳产品。这是我们的主要目标。Kolya [Grebennikov]、Pavel Mezhuev、Doukhvalov、我本人、Mike Pavlyuschik……我们都能把热情灌注到其他团队成员身上。只要周围的人都在勤奋工作，那么身处同一间办公室，亲眼看到这一切是如何发生的，不知不觉中你也会努力进取。”

虽然项目管理并不十分正规，但还是结出了累累硕果。

“如果我没记错，一开始我们会安排状态会议。”De-Monderik说。”一大早组员们习惯集中到办公室，Kolya会就某类主题进行扼要讲话：我们有哪些资源，我们今天要做哪些事 － 他非常擅长这些。我们有一块很大的白板，可以在上面记录绘出我们的发现成果。因为我们的团队并不大，所以完全可以这样做。”

Grebennikov承认，从这一经验中吸取的关键教训是，把状态会议作为组织项目工作的正式方法并不是重点。重点是只有开会有利于项目发展时，才应该召集团队开会。

扩大范围

随着时间流逝，从2003年9月到2006年3月，项目不断地向前发展，团队也不断发展壮大，到发布产品的时候，团队成员数已近30人。产品要求越来越多，而且要过渡到”阿尔法”阶段，因此团队又增招了设计员Maxim Yudanov和软件工程师Pavel Nechayev、Denis Guschin、Eugene Roschin和Andrey Gerasimov。他们带来了一系列创新功能，包括基于外观的用户界面和内置防火墙。团队中还包括安装专业人员和Beta版测试主管。但在修改并定义KAV 6.0过程中，最有决定意义的一步”Six”开发团队采用的开创性新方法 － 基于论坛对Beta测试版进行测试。

论坛

所有股东都一致同意，卡巴斯基反病毒软件6.0能一举成为设计合理、经过精心测试的产品，专业的测试者论坛功不可没。当时对Beta测试版公开进行测试（这已成为卡巴斯基实验室的通用做法）是真正的创新之举，需要面对竞争对手可能有机会在产品发布前就了解到产品特色功能的风险。

“我们对此非常慎重，因为Beta版测试实际上对黑客和竞争对手公开了Beta版代码。”Grebennikov说。”所以员工对此各持己见。反对方有自己的道理，理由如上所述。而劫持方也有非常可靠的证据劫持自己的立场。我们的资源有限，只有两名测试员，其他测试员全部分给了V5.0试验。我们的产品是从头设计的，需要一大群人来运行测试。这是我们第一次采用常规构建更新方法，起初是每周更新一次，后来每天更新一次。通过在论坛上测试这些构建版，我们能够提供高质量的测试，而无需大量内部资源参与其中。”

所有开发人员都积极加入论坛，参与和测试者的讨论。

“在论坛测试期间，一组测试者就包含几千名用户，其中500名左右是核心活跃分子，”Nikolay Grebennikov补充道。每天晚上，Nikolay都会花用几个小时在论坛上，有时候就在电脑边睡着了。他们渴望看到新的构建版，并习惯每天晚上运行，而这些绝不耗费公司的任何成本。

论坛用户提供了bug相关信息，以及如何改进产品的建议。总体反馈中有相当大的一部分被纳入考虑范围，提升了KAV 6.0的价值。此外，建议并不单单通过网络收集。卡巴斯基回忆说，开发人员定期轮流到办公场所参与Beta版测试，范围涉及所有人，包括销售经理和技术支持人员。根据员工们的反馈，产品进行了某些改进：例如，根据技术支持团队的建议，设计了一键式将语言切换为英语的功能。

此外，通过论坛讨论获得改进也是有代价的 － 主要表现在多次延后最终期限。

“根据论坛用户的反馈，我们收到长长的建议改进清单，但有一瞬间我意识到，我们不可能把所有建议都添加到现有产品中，即便建议有强有力的理由。我们有严格的计划要求，需要在2006年2季度正式发布。我们正巧赶在3月31日下午6.30发布了产品。”Nikolay Grebennikov有些戏剧性地指出。

发布

见证成功

我们已经扩编但仍相当精简的团队开发出的产品所带安装程序惊人的小巧，产品最基本的要求是用户界面流畅，外观可更换，对电脑性能影响小，最重要的是产品实际封装了强大、新颖的功能，包括能够根据行为模式阻止可疑应用程序的主动防御功能。

幸亏在欧洲、美国和中国建立了合作伙伴网络，成功的产品随即进入了供应链，一路绿灯迅速成为网上商店的热卖产品，这一切有目共睹。

“Six”的成功源于合理选择的架构，它能轻松部署技术创新，性能高，而就开发方法来说，它100%适用于更精简、更有热情的团队。这才应该是从完成的工作中吸取的关键经验，正是这些经验将卡巴斯基反病毒软件6.0推向了市场，它将使您的项目100%成功，无论是架构还是开发技术都应调整，以适应开发团队和工作规模的要求。

六个角色和一台咖啡机

“在SCRUM的剧本里，在确定有趣的规则时我们会掷硬币来决定，现在除了开发之外，我还会多方面考虑。”卡巴斯基表示。”如果有什么障碍挡在开发之路上，首要做的就是把它清除出去。时间周期。不管是什么都一样。这也就是说，对开发人员有求必应。”

“有一天，在一个项目中我问：”你最需要的是什么？””咖啡机。”Petrovich回答说。第二天，他们就有了一台昂贵奢侈的咖啡机。我们说到做到。”