поддержки — те самые ребята, которым мы так любим звонить в экстренной ситуации (и слушать успокаивающую музыку, пока они там, за кадром, делают что-то загадочное). В зависимости от продукта, системы или сервиса служба поддержки может ранжироваться до трех линий:
● Первая линия (или 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 — еще одна гибкая методология. Основные принципы
