Agil По-Нашему, Или Кое-Что О Российских Инновациях В По

Когда говорят, что инновации Made in Russia — это лишь спорные проекты вроде «Ё-мобиля» паровоза Черепановых, явно неоспоримые, как космические ракеты и прочая полу- и вовсе неполувоенная продукция, или голые идеи на экспорт. , не верьте им.

Нам есть чем похвастаться, и я этим горжусь.

За последние двадцать двенадцать лет моя компания выросла из маленького местного мухомора до вершины рейтингов IDC и правого верхнего угла «магического квадрата» Gartner. Красивый офис на главной улице страны, Слон Дали на ресепшене, почти 3 тысячи человек в штате, 30+ офисов по всему миру.

и прочие похвалы.

Но мы здесь говорим не об этом.

Почему это случилось? Много причин.

Например, мой неизменный принцип: пробуй, пробуй и не бойся ошибок.

А еще - партнерская программа, работа с ритейлерами, онлайнерами, столицами и провинциями - там много чего было, но это не по этой теме.

Все вышеперечисленное вторично (да простят меня те, кто выполняет эту услугу).

Первичны наши технологии и продукты (в смысле просто ПО, а не «ПО + все остальное»).

Потому что если у вас есть программное обеспечение, все остальное можно настроить.

Если нет главного — продукта — то нет смысла строить и все остальное.

В противном случае бизнес (продажи) будет либо одноразовым, либо коррумпированным, что мне категорически и фатально не нравится.



Agil по-нашему, или кое-что о российских инновациях в ПО

Итак, программное обеспечение.

Чем здесь можно гордиться? Есть что-то! Расскажу вам, дорогие хабрцы, о «Шестерке».

Совсем недавно мы отмечали восьмилетие со дня выхода революционной (для своего времени) шестой версии КАВ (то есть Антивируса Касперского), продукта, который в 2006-2009 годах сломал (в буквальном смысле) рынок домашних антивирусов.

Который объединил суперизобретательные технологии: превентивную блокировку вирусов, простоту использования и минимальное потребление ресурсов (да, с «Шестеркой» мы больше не тормозим).

Я оставляю в стороне прорывные методы работы с мировыми ритейлерами, онлайн-торговцами и маркетологами; это тема для другого разговора.

Трахни его в следующий раз.

Коротко о технологиях: — встроенная объектная среда для парсинга объектов произвольной сложности и расширения функционала антивируса новыми компонентами «на лету»; — обнаружение и блокировка вредоносных программ без сигнатур на основе их поведения в системе; — пополнение антивирусных баз при обнаружении неизвестного вируса (вот тут и начались все антивирусные облака!); — система обнаружения и лечения руткитов; — оптимизировано и ускорено антивирусное сканирование; - на закуску - быстрое и компактное обновление приложения, при котором загружаются только измененные фрагменты файла.

Благодаря всему этому «Шестерка» оказалась принципиально лучше предыдущих версий.

Принципиально лучше предыдущих версий наш продукции и на годы опережал всю отечественную продукцию наших основных конкурентов.

И не основные конкуренты.

Это изделие ловило вирусы, как «Мессершмитты» Покрышкина, будучи при этом очень компактным, незаметным и быстрым во всех хороших смыслах этих слов.

Правда, разрабатывали его очень долго, почти три года, и с большими приключениями.

Мы подумываем отнести их описание на голливудский «Мосфильм», но тут сразу признаюсь, что для создания этого проекта нам пришлось придумать свой вариант гибкого метода на основе SCRUM, уволить технического директора, нанять нового и уволить его.

тоже, а также положил под нож пятую версию продукта.

Путь к победе был непростым и тернистым.



Под нож
Почему на плаху пошли два директора и один продукт? Это было 12 лет назад, в 2002 году.

Кто помнит те времена? Windows XP только вышла (кстати, вспомним старушку «всего доброго и спасибо за рыбку»), 1 ГГц — это вполне круто, до iPhone еще 5 (пять!) лет, но на антивирусный фронт популярности Интернета делает его веселее с каждым днем в течение дня.

Появляется всё больше новых типов вирусов (Melissa, RedCode, всякие Slammers), и антивирусные компании вынуждены повышать функциональность продукта.

Антивирус должен содержать сетевой фаервол (или брандмауэр, если вам больше нравятся немецкие слова), постоянно работающий файловый монитор и десятки других функций.

Наша «четверка» не смогла справиться с такой нагрузкой («Касперский медленный» — это как раз оттуда, из той эпохи), и мы, попрощавшись с техническим директором «четверки», наняли нового.

Чтобы он смог сделать нам современный антивирус, ловящий всё и вся.

И это не тормозит, это зараза! Чтобы новый правильный директор набрал правильных людей, выбрал правильную организационную структуру, правильный метод управления проектами, правильный контроль качества – сами понимаете.

Он должен был сделать все.

Мы (компания) предоставили для этого все возможные ресурсы – человеческие и финансовые.

Главное сделать это!!! Остальное мы заработаем.

И.

черт с ним! Через полтора (или два) года почти все разработки пришлось выбросить на помойку.

Новый технический директор создал.

мягко говоря, систему, не совсем отвечающую требованиям коммерческого программного продукта.

Методики управления были скопированы с софт-аутсорсинга, а техническая архитектура продукта построена по канонам корпоративных клиент-серверных приложений.

Вся эта, извините, хрень никоим образом не отвечала требованиям, предъявляемым к коммерческому домашнему антивирусу.

Мало того, что прототип «пятерки» был громоздким и медленным, так еще и количество ошибок в нем не уменьшалось по мере его отладки! Мы начали общаться с нашими старыми программистами, чтобы узнать их мнение.

Говорят: архитектура неправильная.

Получается карточный домик.

Я исправил это здесь, но там оно развалилось.

Поэтому доводить проект до нынешнего состояния не было никакого смысла.

Пришлось его снести и построить заново.



О пользе чешского пива и предметном подходе
Хоть мы этого и не знали, но решение проблемы у нас уже было: уже была разработана архитектура, подходящая для создания антивируса.

Она работала в уголке 4 версии, фильтруя веб-трафик.

Мы задумали это в Праге еще в 1998 году (да, мы искали в Подмосковье более дешевое место для мозгового штурма, но Подмосковье оказалось дорогим, в отличие от Праги), но пока что мы наняли человека, который начал программировать это - Андрей Духвалов - пока он что-то делает написал, век 21 наступил.

«Прага» (так называлась архитектура) писалась в основном для парсинга сложных вредоносных объектов.

Движок 1992 года уже умел обнаруживать Viryo «по тушке» (даже полиморфной).

Но получить «тушку» из любого объекта на компьютере (например, из документа Word внутри архива внутри базы электронной почты) было очень сложной задачей.

Прага знала, как это сделать.

Но чтобы «научить» его этому, нужно было встроить в него такой мощный функционал, которого хватило бы на нечто большее, чем антивирусный движок.

Те, кто использовал Прагу в KAV 4.0, ее очень хвалили, и однажды у меня возник Большой Вопрос.

Как мы все хорошо знаем из учебного курса подготовительной группы любого детского сада, половина решения любой проблемы заключается в правильной формулировке Главного Вопроса.

Если вы правильно задали Главный Вопрос, это означает, что половина бюджета уже потрачена и задача уже выполнена.

Итак, Главный Вопрос! Я спросил Петровича и Графа (Андрей Духвалов и Алексей Де-Мондерик, первый программист LC): можно ли сделать весь продукт в Праге? Граф ответил что-то вроде: «Невозможно, «Прага» создана для других целей», но Петрович промолчал, а на следующее утро пришел с несколькими листами бумаги.

И он сказал: «Слушай, я здесь какой-то случаи использования написал в Праге».

Граф посмотрел и сказал: «Пойдем, поговорим».

Потом ко мне пришли и сказали, что можно попробовать прогнать весь наш скот именно через эту трясину.



Еще немного о Праге
Не уверен, что каждому из нас понравится копаться в «болотистом броде».

А потом стирать джинсы от получаемых ощущений - это вообще дело очень настойчивых рук (погуглите «безумная грязная дорога/поездка/поход»).

Поэтому вот небольшой очерк, который, кстати, не принадлежит моему «перу», но в точности совпадает с моим мировоззрением.

Любая конкретная информация о «Праге» В связи с тем, что Windows и Интернет сильно разнообразили мир угроз, а кроме обычных вирусов в файлах на компьютерах появилось много нового, нам потребовался объектно-ориентированный подход для антивирусного ядра.

То есть движок должен понимать, что любой объект на компьютере представляет собой определённую иерархию, и уметь углубиться в это дерево настолько глубоко, насколько это необходимо, чтобы найти и проанализировать там потенциально опасный код. Казалось бы, ООП было популярно еще в девяностых, инструментов должно быть много! На самом деле, ничего готового нас не устраивало.

Во-первых, построение объектов и все манипуляции с ними должны происходить во время выполнения.

Не каждая объектная среда сохраняет «объективность» на этапах посткомпиляции.

Во-вторых, антивирус должен очень быстро и в больших количествах создавать и уничтожать объекты, экономя при этом память.

По этому требованию начали появляться все обнадеживающие варианты.

В результате возникла идея создать с нуля собственную объектно-ориентированную среду.

Духвалов работал над этой идеей больше года и запрограммировал ее в гибкую архитектуру, которую можно было легко интегрировать в продукт. Объекты могли выполнять практически любую функцию, поэтому помимо разбора иерархии объектов в поисках виря, в «Праге» можно было расширить функционал движка с помощью плагинов.

Фактически, он был основан на очень компактном ядре, которое управляло памятью, наследованием свойств и обменом сообщениями между объектами.

Очень простой API позволил нам использовать «Прагу» везде, где это было необходимо.

Кроме того, он был готов к многопоточности и мультиплатформенности, чего старый движок делать не умел.

Главный недостаток архитектуры был один — в многопоточных приложениях объекты было сложно отлаживать, и на это тратилось довольно много времени разработки.

Мне даже пришлось написать собственный набор инструментов для трассировки исключений.

Но именно благодаря «Праге» в «Шестерке» появилось столько новых функций, которые было легко интегрировать.



Наш СКРАМ
Разработку «Шестёрки» начала буквально горстка психов.

В моем хорошем, истинном понимании термина «сумасшедший!» Архитектура - «Прага».

Задача амбициозная.

Мы хотим делать лучший продукт, вот и все! Основная идея — все успеть, не тормозить и быть приятным на ощупь.

И визуально тоже, чтобы было «ах!» Как подойти к этому масштабному развитию? Для горстки сумасшедших КИМ и другие уже модные в то время методы проектирования не очень подходят. Десять лет назад Agile-методы не были мейнстримом, и нам пришлось самим раскапывать всю тему и подробно ее изучать.

В результате, начитавшись книг и приложив немало усилий, мы взяли в качестве методологии разработки сильно переработанный SCRUM.

Agil по-нашему, или кое-что о российских инновациях в ПО

Из Scrum взяли основы организации процесса: короткие итерации между сборками, разработчики сидят вместе и постоянно общаются, всем всё важно.

Ролевая система, правда, была совсем не Scrum, но у нас она сработала хорошо:

  • Архитектор : человек, который знает как и что строить.

    В Six он также принимал активное участие в самой программе;

  • Технический дизайнер : Более точного названия этой роли никто не придумал, но этот человек отвечает за реализацию конкретных решений и, что более важно, работает «главным спорщиком», умеющим не делать определенных вещей;
  • изобретатель : реализация нестандартных решений конкретных частных задач.

    В «Шестерке» их было полно.

    Ведь оно должно было обеспечить максимальный уровень защиты при минимальном потреблении ресурсов.

    Если что-то нужно было сделать, но никто не понимал, как именно, ему говорили: «Иди домой, разберись к утру, так и должно быть»;

  • Руководитель проекта : как и в классической схватке, наш менеджер не является начальником.

    Он контролирует ресурсы и сроки, но не управляет напрямую, а лишь подталкивает разработчиков проявить инициативу.

    «Коллектив был небольшой, поначалу даже начальника как такового не было.

    Был менеджер, который составлял планы и делал отчеты, но в основном по всем вопросам мы принимали коллективные решения», — вспоминает Духвалов;

  • Менеджер по маркетингу : среди психов должен быть человек, который напомнит им, что товар делается не для себя, а для клиентов.

    В самом широком смысле этого слова.

    Клиент = кто платит деньги, кто партнер, кто техподдержка, кто продает лично - и все остальные тоже! Можно сто раз знать, как сделать антивирусную защиту, но как показать это пользователю, чтобы было удобно, понятно и не напугало – решать маркетологу.

    Отзывы собирались на форуме и непосредственно в личном кабинете.

    Мы регулярно гуляли по офису компании, брали интервью у менеджеров по продажам и технической поддержке, запускали всем бета-версии.

    По результатам опроса сотрудников были внесены необходимые изменения, например, по просьбе техподдержки перешли на английский язык одной кнопкой;

  • Психолог : как сказал наш водитель Андрей Собко, самое сложное в разработке было договориться с коллегами.

    Они все ужасно упрямы.

    Конечно, это все творческие конфликты, и они были очень продуктивными, но все равно – нервы, много работы, мало выходных и сон.

    Кто-то должен следить за тем, чтобы атмосфера оставалась дружелюбной;

  • документатор : Я хочу слово «Документатор» поставить прямо в тройную рамку.

    Мы просто не могли нанять человека на роль Документатора, денег просто не было! А он очень нужен — тот, кто записывает все происходящее.

    Без него через полгода мы уже не знали, почему то или иное было сделано именно так.

Во всей истории с ролями важно помнить, что количество ролей и людей не имеют друг с другом ничего общего.

Одну роль можно распределить между несколькими людьми, при этом каждый член команды выполняет несколько ролей.

Граф хорошо сказал: «У каждого была область, где он был крут, но в то же время 50 процентов — это что-то другое.

Майк мог написать драйвера, если вдруг Собко не объявился, специалисты по интерфейсам могли взять на себя работу над ядром, и наоборот. Я мог что-то нарисовать вместо Макса Юданова, а Коля Гребенников иногда дорисовывал скины».



Agil по-нашему, или кое-что о российских инновациях в ПО

Николай Гребенников и список функций планшетов первой бета-версии И конечно, каждая роль важна на своем этапе проекта.

Вначале архитектор играет первую скрипку.

Изобретатель наиболее важен на этапе разработки, когда придумываются и программируются конкретные функции.

И в конце концов, всю власть необходимо отдать менеджеру, чтобы он довел продукт не до совершенства, а выпустил его в конкретные сроки.

Его можно совершенствовать бесконечно.



О сроках
Проблема сроков и списков дел у нас стояла во время разработки Six, и она стояла очень остро.

С одной стороны, не было фиксированной технической спецификации, а требования к продукту много раз менялись в ходе разработки.

Мы прототипировали, обсуждали, писали списки требований и функций, писали самое важное на желтых бумажках, приклеивали к монитору, забывали, запоминали и так далее.

От альфы до технического релиза прошло пять кварталов! С другой стороны, в результате продукт включил в себя множество функций, о которых мы изначально даже не подумали, и которые сделали его революционным.

Здесь, конечно, большую роль сыграл наш форум.

Хотя с сентября 2003 по март 2006 года, пока делалась «Шестёрка», в ней появилась куча новых задач, а команда выросла почти до тридцати человек, было одно, для чего выделенной команды не хватило.

Это бета-тестирование.

Продукт новый внутри и снаружи, написанный с нуля.

Продукт сложный, поэтому требуется огромное количество испытаний.

Впервые был использован подход регулярных собраний, то есть сначала еженедельно, затем ежедневно.

В итоге мы спорили-спорили и решили провести форумное тестирование.

Благодаря нескольким тысячам форумчан, KAV6 был протестирован очень хорошо! Все разработчики очень активно общались с тестировщиками на форуме.

«Пятьсот человек были очень активны.

Ждали новую сборку, устанавливали ее каждый вечер», — вспоминает Коля Гребенников, который был руководителем проекта КАВ 6.0. Каждый вечер он сидел на форуме по многу часов и иногда даже засыпал прямо над клавиатурой.

Однако вечерами мы все сидели, потому что было столько энтузиазма.

Сверкающие глаза, кипящий котел идей – лучшее время в вашей жизни! Да, возвращаясь к форуму - нам это и помогло, и помешало.

Помогли нам выпустить отличный продукт, но помешали уложиться в сроки :) По результатам форумного тестирования у нас был огромный список улучшений, но в какой-то момент нам пришлось закрыть его для дополнений.

Гребенников поклялся мне выпустить релиз до конца первого квартала 2006 года.

И сделали это вовремя – в 18:30 31 марта!

Успех
За что вы боролись и что получили? У нас получилась настоящая бомба.

Список патентов и уникальных технологий впечатляет. Но обертка для всего этого дела тоже получилась отличная.

Очень компактный установщик по меркам 2006 года.

Быстрая работа.

Красивый интерфейс со скинами — пользователи даже нарисовали окно антивируса на свой вкус.

С Six мы просто начали выходить на западные рынки; Symantec была просто ошеломлена, когда американские журналы начали ставить нам золотые звезды.

И везде, во всех журналах мы получали самые высокие оценки.

И не только в журналах, топы продаж антивирусной продукции от Amazon и других магазинов сразу стали зелеными.

Все это благодаря правильно выбранной архитектуре, подходящей для продукта.

А воплотить это в продукт удалось благодаря процессу разработки, который хорошо подходил небольшой команде сумасшедших энтузиастов.

Здесь!

Вместо заключения
В книге по SCRUM, которую мы тогда читали, я прочитал одно интересное правило, которое помню и которое применяю не только в разработке.

Если что-то мешает развитию, это следует устранить в первую очередь.

Все.

Точка! Неважно, что это такое.

В результате, если разработчику что-то нужно, это нужно ему немедленно дать.

В первый день, когда проект стартовал, я спрашиваю: что вам нужно в первую очередь? «Кофеварка», — ответил Петрович.

На следующий день у них была дорогая и модная кофемашина.



Agil по-нашему, или кое-что о российских инновациях в ПО

Талисман проекта, а также первая кофемашина в ЛК.

Больше не работает :( Проект сработал! И последнее.

Недавно нам пришлось расстаться с одним из ключевых, самых важных людей из «шестерки».

Николай Гребенников пошел своим путем, но компания продолжает идти своим путем.

Это техническое эссе я посвящаю Николаю Гребенникову, который был со мной 10 лет, с которым мы свернули горы и которого я всегда буду помнить до самой смерти.

Евгений Касперский Теги: #Разработка сайтов #антивирус #Лаборатория Касперского #шесть #сумасшедший #было круто #теперь не тормозит

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.