Саммит разработчиков Лаборатории Касперского

22-23.11.2010 прошел 1-ый саммит разработчиков ЛК. И т.к. я случайно оказался одним из архитекторов, у кого нашелся непросроченный загран паспорт, мне удалось в нем поучавствовать.

Хотелось бы отметить наиболее интересные факты.


Гибкие методологии (agile)

На саммите было аж 2 доклада, посвященных гибким методам разработки. И целый круглый стол, посвященный готовности компании к применению гибких методологий. Это очень важный момент. Всего было 9 круглых столов, на которых поднимались такие вопросы, как качество продуктов, процессов, команд, инноваций. И среди них был agile.

Мне это показалось знаковым стечением событий. Почему?

Некоторое время назад контора начала двигаться в сторону повышения уровня CMMI. Была продекларирована концепция компонентной разработки и продуктовых линеек.
Все это привело к вполне законному удлинению сроков исполнению фич, повышению бюрократии, задницеприкрывательству. Особенно в тех областях, которые касаются компонент. Качества продукту это пока(!) не добавило.

А теперь появилась надежда, что у руководства имеется понимание того, что текущая ситуация врядли позитивно отразится на бизнесе. И возможно гибкая разработка сможет нам помочь.

Если говорить о моем личном мнении, то здесь главное - не увлекаться (эта мысль, кстати, была одним из результатов работы круглого стола). Сами продуктовые линейки не нуждаются в гибкой разработке, т.к. у нас нет возможности общаться с нашими заказчиками и требования к продуктам в целом не будут меняться часто и в последний момент.

А вот компонентная разработка ОЧЕНЬ нуждается в гибких методологиях. Процесс трансляции требований из продукта в компоненты - это хороший пример часто меняющихся требований. Связано это с тем, что для правильной трансляции требований на компоненты с первого раза необходимо иметь не только продуктовые требования, но еще и архитектуру продукта. Причем не общую (2 процесса, 1 сокет), а достаточно детальную. Чтобы компонентным архитектору, аналитику, разработчику было понятно, в какое место продукта будет втыкаться компонент, и как он будет там жить.

Это важно!
Компонентные требования зависят от продуктовых требований и архитектуры продукта!

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

Сделать всю архитектуру продукта сразу и детально - это сложная задача. Ее проще делать итеративно совместно с разработкой компонент, зато интеграцию надо делать как можно раньше. При этом надо менять систему управления компонентами. Принцип continious improvement должны стать нормой для всех (особенно для менеджеров). Рефакторинг должен стать частью обычного процесса разработки.

ICFP Contest

Очень привлекла внимание презентация Андрея Рубина про участие команды ЛК в
ICFP Programming Contest http://icfpcontest.org.
Андрей с таким огоньком рассказывал про мероприятие и про процесс участия в нем, что захотелось прямо сразу пойти и записаться добровольцем. Жаль, что записываться пока некуда: следующая игра только летом. Хорошо бы донести этот огонь, пронеся его через тернии работы, жены, детей и так далее. И вообще, может быть еще не возьмут :)
Отличная мысль про тимбилдинг и оценку новых сотрудников.

No comments: