Agile для новичков: как устроена работа в IT-компаниях

Если вы недавно в IT-сфере и как раз ищете свою первую работу в большой компании, скорее всего, Agile — а тем более Scrum, Kanban и Scrumban — вам незнакомы. Этот материал для вас, если вам интересно, зачем компании переходят на гибкие методологии, чем они отличаются и как будет выглядеть ваша работа по ним.

Гибкие методологии отличаются по своим целям, сферам применения и правилам — но все они строятся на одних идеалах Agile. Благодаря им они и называются гибкими. Вот основные:

• Люди и их взаимодействие важнее процессов и инструментов.
• Важнее сделать продукт, который работает, чем составить исчерпывающую документацию.
• Сотрудничать с клиентом и решать его задачи важнее, чем неукоснительно соблюдать условия контракта.
• Реагировать на изменения важнее, чем следовать первоначальному плану.

Джим Хайсмит, один из самых известных адвокатов Agile, описал его так: «Мы принимаем моделирование, но не чтобы положить какую-то диаграмму в пыльный корпоративный репозиторий. Мы принимаем документацию, но не сотни страниц правил, которые никогда не обновляют и редко используют. Мы планируем, но принимаем, что наши возможности ограничены турбулентным окружающим миром».

Для IT-компании главное отличие работы по Agile от работы без него — это сроки планирования. Представим ситуацию: нам нужно запустить сервис по вызову такси, интегрированный с доставкой еды и лекарств. Без Agile мы распишем подробное ТЗ и запустим сервис только через год, когда будут готовы все функции. По Agile — мы уже через два месяца выпустим первую версию, в которой будет только такси. Потом обговорим с заказчиком, что запускаем дальше — это может оказаться что-то неожиданное, например, доставка зоотоваров. Если бы мы работали по ТЗ на год, то не смогли бы гибко изменить функционал продукта и «попасть» в рынок.

Чем хорош Agile:

• С ним получается управлять постоянно меняющимися приоритетами. Мы не составляем ТЗ на полгода работы, а каждый месяц решаем, какая функция актуальна сейчас, и запускаем её. Так можно подстраивать продукт под моду и состояние рынка, и он получается более успешным.
• Мы быстрее выпускаем на рынок готовый продукт. Не работаем год над приложением, пока не выполним все функции — а создаём версию, которая работает, и наращиваем её постепенно.
• Состояние дел на проекте наглядное и прозрачное. Мы регулярно синхронизируемся всей командой по нашим задачам, расставляем приоритеты, и каждый сотрудник знает, на чём именно он сейчас фокусируется.

Agile — магия, которая точно поможет создать что-то великое? Нет, это не так. Например, великие египетские пирамиды строились без него. Agile — это всего лишь свод работающих правил. Это не единственный верный способ, но он проверен в деле и работает.

У нас в Dunice, как и в большинстве IT-компаний, в ходу Scrum, Kanban и их гибрид — Scrumban. Давайте разберёмся, зачем в одной компании целых 3 методологии, как мы выбираем между ними и как выглядит работа по ним.

Мы используем Scrum на проектах, где в команде 3-10 разработчиков. Всю работу мы делим на задачи, которые можно уложить в спринт — одну или две недели. Каждый день мы проводим 15-минутный daily scrum, на котором отмечаем наш прогресс. В конце спринта мы собираемся на sprint review, чтобы оценить работу, которую проделали, и понять, как мы можем работать продуктивнее.На проектах, которые мы ведём по Scrum, есть специальные люди, которые помогают его придерживаться. Со стороны клиента — это Product Owner, с которым мы согласовываем задачи по проекту. Со стороны команды — Scrum Master. Он отвечает за то, чтобы ни один фактор не мешал команде работать, следит, чтобы разработчики использовали scrum-фреймворк, организует собрания и общается с Product Owner`ом.

Мы используем его, когда у нас небольшая проектная команда. Например, занят только один разработчик — для самоорганизации он будет использовать Kanban.

Суть методологии в том, что для понятного и прозрачного рабочего процесса мы используем доску. На ней есть колонка для будущих задач, откуда разработчик забирает себе одну и потом перемещает её в колонку выполненных. Заниматься можно не больше, чем одной задачей — и сколько задач пришло, столько и должно уйти клиенту. Так мы проверяем, что нигде нет узкого места, и рабочему процессу ничего не мешает.

Некоторым командам удобнее использовать гибрид Scrum и Kanban. В этом случае работа организуется вокруг доски, как и в Kanban. Есть колонки To Do, Doing и Done, и каждый разработчик может быть занят только одной задачей в момент времени.

Планирование в Scrumban происходит не ежедневно, как в Scrum, а по мере необходимости — когда в To Do остаётся меньше определённого числа задач. Какое это число, зависит от числа людей в команде и проекта.

В Scrumban нет фиксированных ролей, как в Scrum, и нам не нужен отдельный Master, который будет назначать задачи. Как только разработчик освобождается, он сам выбирает, над чем работает дальше. Так мы создаём равномерную занятость в команде.

Команда обычно работает по Scrumban, когда у нас нет Product Owner`а со стороны клиента и Scrum Master`а с нашей.

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