Поток, что это? Это быть в моменте, здесь и сейчас, каждому участника проекта. Есть ты, рабочее пространство и 100% фокус. Рабочее пространство — это стены офиса или уголка в доме, если ты на удалёнке, твои коллеги очно, либо в мессенджерах, задачи, безумные идеи и яркие цели.

Мы в IT часто сталкиваемся или столкнёмся с тем, что надо запилить нечто такое, в короткие сроки, с учётом таких-то деталей и интеграции новшеств, не потеряв в скорости. В общем сделать так, чтобы всё было хорошо :). Вполне обычная задача, приступая к которой, засучиваешь рукава, хватаешь маркер, карандаши с ручками, собираешь или входишь в команду, проектируешь, визуализируешь, генерируешь идеи, варишь, варишь, варишь и идёшь стучать по клавишам, реализуя крутые вещи.

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

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

В первую очередь, всегда говорил и говорю команде — мы делаем общее дело, все вместе. Так было 12 лет назад, когда занимался сопровождением продуктов, так было 9 лет назад, когда занимался системным и бизнес анализом и 7 лет назад, руководя производством, и вот уже на протяжении 4-х лет, руководя проектами. Лично для меня, нет должностных вертикалей, есть команда, которая на равных в своей компетенции, делает продукт. Такой подход стирает границы формальностей, бюрократии и самое главное, временных ожиданий. Любой участник имеет право голоса тогда, когда он считает нужным. И кстати, под словом команда, я имею в виду и заказчика, который является полноправным участником и входит в состав наших Scrum-команд.

Что такое гибкая методология разработки?

Гибкость в IT сейчас повсюду и философия Agile с набором ценностей, сформулированных в манифесте из 4-х ключевых идей и 12 принципов также, у всех на слуху, на виду и возможно в обойме вашего проекта, в котором вы участвуете. Мы полностью поддерживаем Agile в части взаимодействия людей внутри команд, топим за работающий продукт вместе с заказчиком, который как указал ранее, является частью команды и конечно же, мы 24/7 готовы к любым изменениям, абсолютно любым.

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

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

Итак, Scrum методология/фреймворк, что мы взяли и как у нас есть

1. Product owner (PO) — Заказчик

В нашем случае это внешний заказчик, IT-технологи (в каждой команде 1-2 технолога), которые полностью участвуют в наших процессах разработки выставляя и транслируя требования/задачи своего бизнес-заказчика. Бизнес-заказчик, кстати, временами участвует в показах и грумингах команд, что очень полезно на стадии сбора первичных требований глобальных задач, фиксации промежуточных и конечных результатах.

2. Scrum master (SM) — Lead в команде + фасилитатор

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

• SM — действует согласно методологии, проводит совещания, организует коммуникацию внутри команды, следит за выполнением задач, корректирует вектор, если того требует ситуация
• Фасилитатор — двигает и следит за всеми процессами, реагирует на любые показатели/хотелки команды и максимально оперативно закрывает львиную долю орг. вопросов
• Тестировщик, аналитик, разработчик или рук. проекта.Да, это компетенции, напрямую относящиеся к проекту. Адаптация совмещения компетенций в Scrum очень удачна в нашем случае. Например, у меня 2 команды (Архитектура и Системное администрирование), у начальника тестирования свои функциональные команды, у аналитика своя и т. д.

3. Команда

Рекомендуемое методологией количество участников одной команды 5-9 человек. Состав наших команд от 6 до 12 человек. В сравнении с командой из 6 человек, проблем с увеличением времени митингов или каких-либо коммуникаций, в команде из 12 человек, не наблюдаем.

Команды делятся по функциональности продукта. В общей сложности у нас 7 команд, суммарной численностью 50+ человек в компетенциях: Аналитики, Разработчики разных направлений (Front, Back, Integration), Архитекторы, Тестировщики, Системные администраторы и Сопровожденцы.

Практически в каждой команде 100% автономность, покрывающая функциональность продукта. Но и тут есть адаптация Scrum методологии. Например, архитекторы участвуют во всех командах и точечно подключаются, когда зовут, для участия в митингах, грумингах и решении каких-либо задач. Точечное подключение касается команд администрирования и сопровождения. Также, участник команды в любой компетенции, может привлекаться к другим командам для решения задач, например, доработки модуля, который срочно нужно внедрить в предстоящий релиз. Такие привлечения согласовываются между SM команд, которые анализируют задачи спринтов и возможность отдачи компетенции, на срок, позволяющий максимально сохранить покрытие запланированного объёма задач, в рамках текущего спринта. Финальное решение переключения зависит от исполнителя компетенции, т. к. он берёт на себя ответственность, помимо закрытия задач своего спринта, закрыть дополнительно задачу спринта другой команды. Бывают ситуации, когда сами заказчики в командах, понимая важность рабочего модуля для проекта в целом, жертвуют компетенцией исполнителя/ей, перенося свои незавершённые задачи на следующий спринт. Но как показывает практика, все «жертвы» не напрасны. Мы получаем рабочий продукт в установленный релиз, клиенты довольны, мы довольны что клиенты довольны, ну, а взаимопомощь всегда хорошо, и кто знает, когда какой-то из функциональных команд, потребуется доп. помощь компетенции другой функциональной команды?

С ролями, надеюсь, всё понятно. Давайте рассмотрим предметно, что к чему.

Организация процесса

1. Boards — доски

Какое-то первичное понимание ведения досок у нас было. Мы знали, что можно брать стикеры, писать на них задачи и двигать бумажки по ячейкам, ровно так, как мы делали на Kanban доске. Kanban доска была классной, такой красивой, огромной и пробковой. У задач был свой жизненный цикл (ЖЦ) и до какого-то момента, стикеры помещались все. Но с наращиванием команды, оптимизации процессов разработки, прокачке компетенций, задач стали брать больше и больше. Как итог, десятки стикеров с задачами, которые попросту перестали умещаться на доске. И это глобальные задачи, детализация которых велась в Jira.

Scrum-методология тоже рекомендует стикеры, доску на которую их можно лепить, маркеры и стоящую вокруг доски, активно обсуждающую задачи, команду. Окай, сформировали пилотную команду и начали проводить данный обряд в митингах, грумингах и ретроспективах. Практически на каждом обряде очно присутствовал заказчик. Опыт неоценимый и очень результативный. Благодаря чему, команда сплотилась, выстроила чёткий вектор развития, прозрачно, объективно и с понятным (в Story Point?ах) сроками.

ЖЦ скрам доски стандартный:
 

• Нужно сделать
• Разработка
• Тестирование
• Выполнено

Параллельно физической доске, мы продолжали вести задачи в Jira, для удобства обмена информацией, историчности, оперативного поиска, обращения к вложениям и прочим благам цифровизации, а также заделом на будущее, для региональных и работающих удалённо участников будущих команд. Спустя какое-то время, стикеры, маркеры, флипчарты стали доставлять неудобства из-за объёма информации. Было принято решение, в той же Jira, сформировать Scrum доску. Это очень правильно решение, с него и надо начинать.

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

Начали формировать команды, децентрализация по России сотрудников которых, составляет 45%. У каждой функциональной команды появилась своя доска в Jira, со своим SM, списком задач и сроками.

2. Коммуникации

Децентрализация команды, временами, ограничение возможности присутствия заказчика, а также необходимость в бизнес-заказчике, потребовало наладки VoIP коммуникации. Начали со Skype, но результат не отвечал нашим требованиям в части видеопотока, да и звука. Думаю, вы понимаете, о чём я, видя, как шевелят губами, роботом говорящие ребята. Это была проблема, т. к. большинство сотрудников заказчика, подключаются с мобильных устройств с плохим интернет-каналом.

В поисках решений, кто-то предложил Zoom клиент. Попробовали. Зашло. Аудио и видео потоки не прерывались, даже со слабым интернетом-каналом. Каждый участник команды, подключаясь на встречу, обязательно включает камеру, тем самым, частично компенсируя своё физическое отсутствие. Да и продуктивнее общаться online, видя собеседника и всю команду в целом.

SM команды, на каждом митинге шарит доску, вводя команду в единое инфополе.

Также, мы запустили Confluence, что позволило избавиться от тонны пересылаемых документов, с кучей разных версий, ожиданием пока кто-то почистит ящик, чтобы принять документ и прочими неудобствами. Confluence вывешен во вне и в моменте, все могут видеть единую версию документа, либо осуществлять правки в online, прям по ходу груминга например. Подключили плагин версионности публикуемых документов, с ним куда проще работать, особенно имея релизность продукта. Прям советую.

3. Backlog — список задач

Сформировать первичный бэклог труда нам не составило. После создания Scrum-доски в Jira, все незакрытые задачи публикуются в бэклоге. За несколько лет накопилось неплохое количество незакрытых задач, которые как ни кстати требовалось проштудировать и в целом понять, что актуально, что нет.

Оставив «жмых» из более чем сотни задач, стали распределять по командам, там-же, в бэклогe, путём создания новых спринтов с припиской «Backlog». Данные спринты никогда не берутся в работу, а служат только для хранения историй/задач для последующего взятия в спринт. Такой подход очень удобен тем, что все задачи на виду у всех участников множества команд. Бывают случаи, что кто-то цепляет взглядом какую-то интересную, по его мнению, задачу из другой команды, лезет чуть глубже и понимает, что она плотно коррелирует с тем, над чем он сейчас работает. Такие задачи переходят в команду интересующегося участника и как правило оперативно закрываются. Также, полная картинка бэклога мне даёт оперативный срез по объёмам производства и понимание динамики задач.

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

Как наполняется Backlog:
 

• Из еженедельных грумингов
• По итогу демонстрации функциональности
• По итогу ретроспективы спринта
• В ходе выполнения спринта
• В ходе сопровождения продукта

Выше упоминал о релизности продукта. Всю историю и будущее планирование выпуска релизов мы также, ведём в Jira. Количество и частота релизов с каждым годом увеличивается примерно в два раза. Все связи задач, историй, epic?ов и версий релизов, ведётся в бэклоге.

Релиз в Jir?e декомпозируем следующим образом:
 

1. Релиз = версия продукта. 10+ штук в год. Каждая версия содержит множество глобальных задач бизнеса
2. Глобальная задача бизнеса = Epic в Jir?e
3. Epic дробится на множество историй с подзадачами
4. Подзадача = задача для участника команды

4. Оценка задач (подзадач)

Само собой, у всех нас была в голове одна оценка (ну ладно, две, вторая: сложно, не сложно) задач, в днях и в часах (для самых мелких задач). Тут снова приходит Agile и говорит, возьми не временную оценку, а оценку усилий, заложи туда всё, что может произойти с задачей и назови Story Point (SP). Было не просто уйти от привычного мерила, но шаг за шагом мы двигались, формировали в головах новые нейронные связи и пришли к градации 3, 6, 9, 12. Где 3 самая простая задача, 12 самая сложная. Кто-то использует шаг в 2 SP, кто-то ряды Фибоначчи или размеры одежды и даже размеры животных, мы же остановились на шаге в 3 SP, как самым оптимальным.

Для оценки задачи, субъективно, самой распространённой или скорее более точной техникой является Planning Poker. Тут вновь отходим от правильной методики оценки SP. В каждой нашей команде как минимум, есть 2 сотрудника одной компетенции, например аналитик. Да, они могут быть с разными скиллами, но это не мешает выходить на диалог при оценке задач. SM называет задачу, участник из команды, в рамках своей компетенции, откликается в качестве исполнителя, погружается (хотя в большинстве своём, команда предметно знает свои задачи бэклога из грумингов и рабочего процесса) детально в задачу и оглашает свою оценку в SP. Если SM или сотрудник в схожей компетенции, имеют вопросы или предположение своей оценки, отличной от озвученной, начинается дискуссия и раскладка задачи по полочкам, для более детальной и объективности оценки. Когда все вопросы дискуссии проработаны, фиксируется проговоренная между участниками команды SP задачи. Исполнитель финально подписывается под оценкой.

Задача = подзадача истории. Для удобства контроля выполнения подзадач и историй в целом, мы немного доработали Jira, включив суммарное отображение SP открытых подзадач в истории. Если подзадача закрывается, SP подзадачи вычисляется из общего SP истории. Оценки видны в бэклоге, что позволяет оперативно реагировать на «застрявшие» задачи. К примеру, если история взята в 2-х недельный спринт с оценкой 150 SP, то в соответствии с диаграммой погашения задач, в середине спринта, остаток открытых задач должен составлять примерно 75 SP ±. Видя сильное отклонение от цифры, на командном митинге, можно более детально углубиться в причины и скорректировать действия для успеха исполнения истории в текущий спринт.

Вся оценка историй и Epic?ов строится из оценки подзадач. Со временем, ты понимаешь продуктивность своей команды в SP. Даже при планировании спринта, накидывая историй с подзадачами, ориентируешься на средний показатель спринта. Продуктивность каждого участника команды также видно в SP. Это дополнительный инструмент SM, которым аккуратно можно балансировать нагрузку.

5. Sprint

Временной отрезок, включающий в себя полный цикл разработки продукта, с готовым функционалом на выходе. Спринт состоит из:
 

• Ежедневных митингов
• Грумингов
• Демонстрации функционала
• Ретроспективы

Временной отрезок, как правило, задаётся длинной в 1 — 2 недели или месяц. Этого более чем достаточно для потребностей большинства команд. Мы взяли 2-х недельный отрезок, как самый оптимальный и вот почему:
 

1. 10 рабочих дней достаточно для разработки чего-то стоящего, что можно продемонстрировать заказчику
2. 40 часов в месяц одной команды на орг. мероприятия приемлемы для достигаемого/достигнутого результата. 40 часов это демонстрация спринта и обсуждение вопросов (от 1 часа), ретроспектива и формирование спринта порядка 30 минут на каждое мероприятие. Получаем в среднем 2 часа одного участника команды * 2 спринта в месяц * кол-во участников команды
3. Баланс задач и требований бизнеса в соотношении с количеством компетенций в команде, гармоничен. Заказчику достаточно видеть двухнедельную динамику, при необходимости вносить правки и получать результат ещё через 2 недели (кроме исключительных случаев, когда предрелизная ситуация, например)

Как упоминал ранее, у нас 7 команд. Каждая команда использует компоненты спринта в удобные для себя дни и время. У кого-то спринт может стартовать/завершаться в середине недели, у кого-то со вторника. Время на груминги и ретроспективы, команда тоже определяет сама. Далее буду описывать работу на примере команды архитекторов.

Новый спринт у нас формируется каждый второй понедельник, после отчётного митинга за минувший рабочий день.

Отличие отчётного митинга от ежедневного митинга только в одном — участник команды не говорит о том, что будет делать сегодня.

В ежедневном митинге, каждый участник команды отвечает на 3 вопроса:

• Что делал вчера?
• Что будет делать сегодня?
• Какие проблемы возникли по ходу решения задач/задачи?

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

1. Проблема критична? Заводим доп. задачу в текущий спринт на реализацию. Из команды, согласно компетенции, берёт задачу и ответственность один и участников. Проводим оперативную оценку SP, приоритезируем задачи исполнителя и возможность всё успеть, что было ранее запланировано в спринт. Ну куда без этого.
2. Проблема терпит решения до следующего спринта. Тогда в бэклог заводится новая задача, которая в будущем, будет определена в спринт

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

Груминг (Grooming) проводим каждую неделю, иногда чаще, в зависимости от потребности обсуждения/проработки задач. Стандартная встреча раз в неделю в запланированное время (например, каждый вторник в 16:00). На грумингах мы обсуждаем:

 

• Задачи бэклога
• Новые/текущие глобальные задачи
• Планирование состава будущих спринтов
• Оценки задач

Продолжительность проведения груминга от 30 минут до нескольких часов.

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

Demo зачастую проводит тестировщик, он как никто, знает, что показывать и как показывать. Знает, что работает, что нет, знает где есть костыль и как обойти багу. Шучу. Показ нацелен на результат команды, а вы помните, что заказчик является частью команды и прекрасно знает, если что где-то не так, знает, что не успели сделать и знает почему. Все успехи и неудачи делятся поровну, на всех участников команды. Методология скрама этим и хороша — все процессы настолько прозрачны, что в голове и мысли нет, чтобы тратить время на какие-то костыли и варианты демонстрации «красивой картинки». Мы оперируем фактами в текущем моменте, открыто принимаем ситуацию как есть и вместе ищем пути решения.

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

Поначалу, команде было не очень комфортно высказываться. Вроде всё нормально, спринт закрыли, всё показали, да и пятница, выходные уже вот-вот, что ты от меня хочешь? В какой-то степени это нормально, когда привык делать своё дело и делать его хорошо, да даже отлично. Но сейчас всё иначе. Сформировавшаяся сплочённость, персональная ответственность, открытость в процессах, меняет мышление. Это должно было произойти. Даже интроверты выходят за привычные им рамки и начинают «бомбить» идеями, предложениями, адресованными отзывами, проявляя открытость. Если вначале, мы могли слышать фразы — Вась, твой скрипт навернул мне процесс, что привело к нескольким часам поиска проблемы и как результат, я чуть не зафакапил свои задачи. И Вася начинает ещё больше напрягаться, ведь уже в ходе спринта всё проговорили, поправили, а сейчас опять тему поднимаем. То сейчас, мы говорим так — Вась, твой скрипт навернул мне процесс, мы с тобой потратили много времени на поиск и исправление, я тут прикинул, как в будущем уберечь нас от таких проблем, слушай.

В команде выстраивается открытый диалог, который нацелен на решение проблемы на уровне проекта, а не на уровне личных задач.

Пожалуй, это все процессы, которые мы ежедневно используем в рамках Agile философии и Scrum методологии. Возможно есть ещё какие-то вещи, но они кажутся настолько очевидными за 3 года применения и использования, что я попросту мог их не упомянуть выше.

Теоретическая применимость фреймворка ясна. В следующей статье рассмотрим практическое применение.

Автор: Константин Гусев
Руководитель проектов
Компания ОТР