IT-рекрутмент. Как найти лучших специалистов, когда все вокруг горит - Егор Яценко Страница 15

● Первая линия (или HelpDesk) — решают самые простые задачи пользователей: выключите и включите компьютер — заработало? Поздравляю!

● Вторая линия — здесь в работу включаются системные администраторы. Они решают вопросы управления доступом и могут корректировать настройки системы.

● Третья линия — специалисты, решающие сервисные вопросы. Они могут поправить ошибку в коде.

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

Я привел «усредненный» вариант этапов разработки, характерный больше для каскадных методологий. В зависимости от задачи, а также от выбранной методологии работы этапы могут меняться местами, некоторые — исключаться или заменяться другими. Но в целом, по классической схеме, события должны развиваться в описанной последовательности.

Глава 8

Методологии разработки в IT

Работая в сфере IT, невозможно не столкнуться с терминами типа Scrum (скрам) и Agile (аджайл/эджайл). Но именно из-за того, что они постоянно на слуху и вроде бы все знают, что это такое, появляется масса недопониманий. Как говорил Марк Твен, «все проблемы не от незнания, а от уверенности в собственном знании». И к пониманию Agile в среде HR-специалистов это относится в полной мере.

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

И начнем мы, вопреки ожиданиям, с описания «негибкой» системы разработки: как строился процесс создания ПО еще несколько лет назад? С чего, как говорится, все начиналось?

Waterfall, или «Водопад», — традиционный подход к работе над ПО. Для него характерна последовательная разработка: первый этап, второй, третий и т. д. Каждый следующий начинается только после того, как закончился предыдущий.

Преимущество «Водопада» заключается в том, что мы можем более-менее точно рассчитать стоимость разработки и сроки ее завершения.

Основной же минус — при долгосрочном планировании мы рискуем получить на выходе технически и морально устаревший продукт.

Вот как схематически выглядит Waterfall-методология разработки:

В стародавние времена, когда производственные и бизнес-модели не менялись годами, каскадная разработка была вполне оправданна. Сегодня же бизнес не может отдать в разработку глобальную задачу и вернуться за результатом, скажем, через полгода. За это время бизнес-идея может потерять свою актуальность, технологии — измениться, кризис — грянуть (привет, ковид!), биткоин — упасть. Поэтому на смену «Водопаду» пришли так называемые гибкие методологии.

Они позволяют на лету менять требования к продукту, добавлять новые модули и отказываться от ненужных. У каждого типа методологий есть свои особенности, но объединяет их одно: наличие некоторых непродолжительных циклов, где результат предыдущего цикла (итерации) оказывает влияние на планирование следующего.

Agile — это семейство методик и подходов к управлению, которые фокусируют команду на продукте. Во главе угла — нужды и цели клиента. Для этого необходимо упростить оргструктуру и процессы, работать короткими циклами, активно использовать обратную связь. Для достижения этих целей предполагается повышение полномочий и расширение зон ответственности сотрудника.

В 2001 году 17 представителей различных концепций разработки программного обеспечения собрались на горнолыжном курорте в штате Юта и составили Agile-манифест. Этот документ закрепил основные принципы и ценности гибкой разработки. На http://agilemanifesto.org/ его можно прочитать более чем на 50 языках, а также ознакомиться со списком авторов, которые его составили. На русском манифест выглядит следующим образом:

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

● Люди и взаимодействие важнее процессов и инструментов.

● Работающий продукт важнее исчерпывающей документации.

● Сотрудничество с заказчиком важнее согласования условия контракта.

● Готовность к изменениям важнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева».

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

Каковы же недостатки? Главный из них заключается в том, что разработка может вестись бесконечно. И от этого может быть больно в прямом и переносном смысле: сотрудники находятся в состоянии постоянного тонуса. Требуется скорость в принятии решений и реализации задуманного, но конечного результата не предвидится. Хотя важно признать, что большинство современных компаний все-таки стремятся к внедрению гибких методологий, ведь они больше отвечают реалиям современного мира.

Как выглядит Agile:

Гибкие методологии требуют развития soft skills у IT-специалистов. Если при каскадной разработке программист имел возможность длительное время работать в одиночку и никто его не трогал, то в условиях аджайла с регулярными планерами, демо и код-ревью ему необходим навык эффективного общения и работы в команде.

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

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

В семейство Agile входят следующие методологии: Scrum (скрам), Kanban (канбан), XP, Scrumban (скрамбан). Каждая из них имеет некоторые особенности, которые важно знать, если вы нанимаете персонал под проект.

Scrum — гибкая структура процессов для небольших команд (обычно до 10 человек), которые разбивают свою работу на промежуточные цели. Эти цели выполняются в рамках временных итераций (спринтов) продолжительностью от одной до трех недель, стандартный спринт идет две недели. В качестве подготовки к нему сперва выбирается список задач из бэклога — своеобразного журнала проекта, в котором указываются задачи по приоритетам и отмечается этап их выполнения.

Команда разработки проводит ежедневные 5–20-минутные митинги (совещания), которые позволяют отслеживать ход проекта, быстро выявлять возникающие проблемы и оперативно на них реагировать.

Kanban — еще одна гибкая методология. Основные принципы