Гибкие методологии требуют развития soft skills у IT-специалистов. Если при каскадной разработке программист имел возможность длительное время работать в одиночку и никто его не трогал, то в условиях аджайла с регулярными планерами, демо и код-ревью ему необходим навык эффективного общения и работы в команде.
Среди плюсов аджайла также можно упомянуть тот факт, что минимизируется разработка «в стол»: небольшие фичи уходят к пользователю сразу после выпуска. Кроме того, постоянная обратная связь о качестве кода обеспечивает быстрый профессиональный рост специалистов.
Однако все эти плюсы могут стать минусами в случае, если разработчик не привык к динамичной работе, болезненно воспринимает обратную связь на свой код и общение с коллегами дается ему нелегко. В таком случае стоит задуматься, подходит ли ему работа в аджайл-команде.
В семейство Agile входят следующие методологии: Scrum (скрам), Kanban (канбан), XP, Scrumban (скрамбан). Каждая из них имеет некоторые особенности, которые важно знать, если вы нанимаете персонал под проект.
Scrum — гибкая структура процессов для небольших команд (обычно до 10 человек), которые разбивают свою работу на промежуточные цели. Эти цели выполняются в рамках временных итераций (спринтов) продолжительностью от одной до трех недель, стандартный спринт идет две недели. В качестве подготовки к нему сперва выбирается список задач из бэклога — своеобразного журнала проекта, в котором указываются задачи по приоритетам и отмечается этап их выполнения.
Команда разработки проводит ежедневные 5–20-минутные митинги (совещания), которые позволяют отслеживать ход проекта, быстро выявлять возникающие проблемы и оперативно на них реагировать.
Kanban — еще одна гибкая методология. Основные принципы канбан были унаследованы от подхода, разработанного на заводе Toyota в 1950-х годах. Особенности этой методики заключаются в том, что разработка визуализирована: разделена на задачи, этапы их выполнения маркируются специальными отметками. Количество работ, производящихся одновременно, ограничено. Измеряется и оптимизируется время на выполнение одной задачи.
Extreme Programming, XP. Если описанные выше методологии применимы не только в разработке ПО, то XP — это подход, созданный специально для IT-бизнеса. Его идея проста: взять лучшие практики из других гибких подходов и довести их до экстремально высокого уровня. Например, в рамках данной методологии используется парное программирование: два разработчика на одной машине пишут одну фичу и регулярно (раз в несколько минут) меняются местами. Когда один пишет код, второй его анализирует.
Здесь возникает вопрос, как соотносятся Agile и Scrum. Мне очень понравился ответ, который я увидел где-то на просторах Facebook: примерно так же, как газировка и кока-кола.
Важно понимать, что далеко не во всех компаниях внедрен чистый Scrum или Kanban. Зачастую компания пишет, что работает по скраму, когда у них тупо итерационная разработка, а все прочие условия скрама не соблюдены. Кроме того, на рынке появляются всякие гибридные варианты, которые создают компании. Тот же Сберджайл, например (думаю, не стоит объяснять, в какой компании он применяется, да?).
Развитие гибких систем разработки привело к появлению таких специалистов, как, например, Agile Coach (аджайл-коуч) и Scrum Master (скрам-мастер). Они знают, как создавать, запускать и выстраивать процесс гибкой разработки. Причем их функционал в основном не технический: их сильная сторона — soft skills, за счет чего они становятся одновременно и преподавателями (обучают технологии гибкой разработки), и фасилитаторами (облегчают общение внутри команды), и специалистами по устранению системных препятствий на пути к реализации и продвижению продукта, и выполняют много других функций, благодаря чему проект «едет» в соответствии с принципами Scrum или Agile.
Общаясь с кандидатом и спрашивая у него про методологию, вполне логично поинтересоваться, чистый ли скрам, например, был у них в компании и какие его элементы были внедрены, кто был скрам-мастером. Важно понимать, что количество людей в команде скрам-мастера тоже должно быть ограничено (в канонической версии), а значит, если кандидат говорит о том, что у них все канонично, но один скрам-мастер на 300 человек, он не до конца прав.
Глава 9
Управление в IT
Итак, мы разобрали методологии, по которым разрабатывается продукт. Есть те, кто будет следить за соблюдением канонического скрама, но есть ведь и те, кто будет непосредственно управлять процессами, да? Давайте рассмотрим тему, которая вызывает много сложностей у рекрутеров: Product— и Project-менеджеры. Чтобы понять суть этих специальностей, давайте определимся с разницей между проектом и продуктом.
Продукт — это конечный результат, который предоставляется пользователям или клиентам. Продуктом может быть готовый софт, сервис, приложение и т. д.