На Хабре существует огромное количество информации, с описанием гибкой методологии. Существуют тексты, описывающие, как это здорово, когда в вашей команде все идет по скраму. Но когда дело доходит до введения модных методологий, информация в статьях ограничивается парой предложений в ключе «заполните беклог, проведите планирование, радуйтесь возросшей эффективности работы команды»
Данная статья предназначена для тех, кто уже что-то слышал про гибкие методологии, знаком с некоторой терминологией agile и уверен, что в вашем отделе внутри компании, действительно необходим подход скрам.
Как узнать, что IT отдел в моей компании действительно нуждается в скраме?
Признаком неоптимального процесса в работе является множественные жалобы со стороны других подразделений. Именно так было и у нас. Каждый отдел внутри компании выливал вину на смежный отдел и обязательно на IT.
Касательно IT всегда говорили, что разработка «простых» вещей затягивается. В понятие «простые» обычно вкладывали разработку целых проектов, на которые даже у хорошо отлаженной команды разработки уходит больше 2-х месяцев
Симптомы же были видны внутри команды:
- Тимлид не знал, чем занимался каждый программист, потому что…
- …потому что программисты принимали задачи в коридоре, от руководителей других департаментов или руководства компании
- Приоритет задач измерялся в диапазоне от срочно до «не уходим пока не сделаем»
- Сроки задач никогда не соблюдались
- Информация о проектах передавалась из уст в уста
Картинка с https://pikabu.ru/story/zamknutyiy_krug_rossiyskogo_biznesa_4270437
Если бизнес-процессы внутри вашей компании похожи на эту картинку, а разработчики находятся в вечном стрессе, то ваша ситуация сильно похожа на ту, в которой находилась наша компания. Дальнейшие шаги описывают один из вариантов решения данной ситуации. Надеюсь, следующие 10 итераций введения скрама смогут сдвинуть бизнес и команду с мертвой точки и пойдут на пользу.
Инструменты тимлида
Для решения комплексной проблемы управления командой, необходимо вооружиться следующими инструментами:
- Jira или ее аналог для проведения спринтов
- Gitlab / github / bitbucket или подобный инструмент версионности кода
- Confluence или любой другой сервис хранения информации
- Google drive
- IT директор
- Генератор ретроспективы
И.1 формализация процессов
Обычно, первый шаг введения скрама в команде во многих статьях выглядит так: заполните беклог, распределите роли, начните спринт, снимайте сливки, теперь вы крутой руководитель, а ваш отдел превосходит команду Google, Apple и Tesla вместе взятых. Но сработают ли эти шаги в жизни? Что значит распределить роли, если в скраме нет роли «Тимлид»?
Вопросов, действительно, много, а ответы брать неоткуда.
Как поступили мы в самом начале?
- Составили список всех задач, над которыми ведется хоть какая-то работа, включая поддержку, обработка заявок и прочее.
- Выделили из списка задач проекты, к которым эти задачи относятся. Проектов оказалось около 10 штук на команду из 5 разработчиков.
- Планирование первого спринта.
Здесь, конечно, уже не первый наш спринт, но оцените количество проектов на 4-х программистов
Первый спринт был недельным. Задачи выбирались из принципа «что необходимо доделать из того, что уже давно делали»
В течение этого спринта IT директор прошелся по всем заказчикам каждого из проектов с попыткой выставить приоритеты. Удалось договориться и из 10 проектов выделить 2. Чтобы остальным заказчикам было «не обидно», было решено брать по одной задаче из каждого проекта, если это возможно.
Программисты получили установку всех «коридорных» заказчиков посылать к IT директору.
Ценность: Руководство в курсе всей работы, и всех заявок на разработку.
И.2 Приоритизация беклога
Первая итерация дала команде возможность поработать без стресса, но добавила стресса руководству. Поскольку идти назад всегда проще, чем вперед, то усложним задачу. Пусть теперь IT директор выбирает приоритеты для задач всего беклога. Важно знать, что для того, чтобы задача попала в работу, у нее должно быть однозначное описание, понятные критерии выполнения, задача не должна зависеть от других задач. То есть просто оцененную на 100 из 100 задачу мы брать не будет, а будем указывать на зависимость от других задач/отделов/процессов.
Ценность: другие люди могут даже и не знать, что без их участия невозможно доделать целый проект.
В команду же мы введем обязательные утренние стендапы. Стендап удобнее всего назначать на время Т+2часа от времени прихода на работу. Это позволит влиться в рабочий ритм, доделать какие-то вчерашние дела, а вечно опаздывающим — не опоздать на планирование.
Все последующие спринты сделаем двухнедельными, так мы сможем экономить время на планированиях.
И.3 Сторипоинты
Оценка задач и планирование — всегда отдельная боль в команде. Обычно уходит много времени на обсуждение, оценку задач по сторипоинтам. Оценки не совпадают, дискуссия, обсуждение, вновь оценка… Было одно планирование, на которое мы потратили целый рабочий день, с 10 до 19 и так и не пришли к консенсусу. Я не раз слышал о проблемах с планированием в других командах.
Снижаем времязатраты на планирование:
В jira добавляем 4 поля для оценки задачи по приоритету от бизнеса: «ценность для бизнеса», «снижение рисков», «срочность» и cost of delay, которое считается, как среднее арифметическое от предыдущих трех.
Добавим еще 4 поля для оценки задач командой: «неизвестность», «объем», «сложность» и storypoint — как среднее арифметическое предыдущих?
Как команде разработки, так и людям, принимающим решения от бизнеса, гораздо проще ответить на три вопроса, чем поставить абстрактную оценку в попугаях.
Ценность: люди не умеют планировать и это факт. Бюджет, время, задачи — не важно. Но планирование должно быть и должно вызывать минимум сложностей.
А еще выделим из команды наиболее заинтересованного в скраме человека и поручим ему проводить стендапы. Так мы сделаем их менее формальными.
И.4 Планирование вслепую
Прежде чем перейти к описанию этой части, прошу ответить на простой вопрос: какая высота башни эволюция из комплекса Москва-сити?
- Больше 100 метров
- Больше 150 метров
- Меньше 200 метров
Если ваш ответ не отличается от представленных цифр больше, чем на 10%, поздравляю, вы попались на крючок с опорными цифрами.
В оценке задач случается аналогичная проблема: стоит кому-то одному вслух назвать цифру, как большинство начнет привязываться к ней. Нам нужна объективность, поэтому планировать будем вслепую. Для организации удобного для всех планирования, выгрузим задачи в таблицы гугл и разрешим редактировать только 3 колонки.
Себе же сделаем таблицу с результатами оценок. Добавим окрас и разброс.
Таблица для каждого программиста

Таблица для сводного планирования. Можем посмотреть оценки каждого человека
Ценность: теперь при планировании мы экономим время на оценку задач, а на обсуждение выносим только те моменты, где возникает большой разброс оценок или где оценки переваливают за определенный максимум, что говорит нам о сложности в понимании задачи.
И.5 Рост беклога
И вроде процессы входят в привычку, заказчики научились не дергать исполнителей, а приходить к руководству, заполнять беклог. Но что делать, когда задач становится слишком много и на оценку уходит очень много времени?
Ответ прост: темп команды.
Чтобы команде не оценивать весь беклог из сотни задач, дадим им на оценку список, равный количеству текущих задач + 50%, а бизнес пусть так и оценивает весь беклог.
Ценность: бизнес в курсе всей картины и приоритетов, команда разработки видит и оценивает сразу столько задач, сколько сможет решить. Запас позволяет нам дозаполнять беклог, если кто-то остается недогружен исходя из оценки по сторипоинтам (мы же следим за велосити каждого из команды?)
И.6 Добавим артефактов
Когда с оценкой все более-менее устаканилось, утренние стендапы вошли в привычку, добавим в команду ретроспективу. К этому моменту уже накопился определенный опыт, позитивный и негативный. Вы его могли не замечать за суетой планирования и совещаний, но соседа Васю изрядно достали задачи по проекту А и он с завистью смотрит на его проект В. Да и Петя косится на А.
Как раз для этого и пригодится ретроспектива. Подбирайте «конкурсы» исходя из командного духа в команде. Далеко не все может понравится команде. Что-то может быть утомительным, а что-то наоборот пойдет исключительно на пользу.
Расскажите, как важно в течение ретро быть честным друг с другом, донесите полезность.
Ценность: работа с коллективным духом даст возможность поднять проблемные места и устранить их в ближайшие недели.
И.7 Оценка вновь узкое горлышко
Да, мы растем и вместе с тем растет наш беклог. Он уже перевалил за сотню задач, а это огромное количество!
Решение напрашивается само собой: дадим бизнесу оценивать приоритет эпиков, а сами возьмем на себя оценку задач. Оцененные задачи отдадим на утверждение руководству.
Кажется, что это пин-понг, но поверьте, пробежаться глазами и кивнуть головой занимает намного меньше времени, чем проставить циферки в сотне клеточек.
Ценность: мы выиграли время и снизили нагрузку с лиц, принимающих решения. Теперь оценка по приоритету занимает не более одного дня.
И.8 Организация статусов задач и буфер
Статусы задач в джире это всегда отдельная песня.
Кто-то не понимает смысла сотни статусов и согласен только на цепочку из 3-х — TODO-IN PROGRESS — DONE
Но статусы это удобный инструмент из которого мы выжмем максимум.
Во-первых в промежутке между текущим спринтом и будущим будем держать буфер из нескольких спринтов. Туда будем кидать задачи с пометкой срочно-завтра или те задачи, которые не уместились в текущий спринт, но уже имеют высокий приоритет и их мы точно возьмем в работу в ближайшем будущем.
На заметку: если не делать горящую задачу прям сейчас, то с вероятностью в 90%, окажется что она не такая уж и горящая и вполне может потерпеть пару недель, а то и вовсе отмениться.
Во-вторых — касательно значений самих cтатусов. Задачу, состоящую из заголовка будем держать в статусе беклог. Задачи, оцененные и гарантированно идущие в ближайший спринт будем держать в статусе реди. Задачи, попадающие в спринт будут мигрировать в статус туду, ну а дальше по колонкам.

Чтобы в таблицах не выпадали все задачи из буферов, поправим фильтр, отсеяв задачи в статусе беклог.
Ценность: задач на оценку становится меньше, что снижает стресс и страх перед грядущим спринтов. Буфер позволяет смотреть в будущее… ну вы поняли
И.9 Автоматизация
Да, поменять статус у 10-15 задач это плевое дело. 5 минут. Но ведь мы из программистов. Пусть думает компьютер, а не голова. Идем в раздел автоматизации в джире и настраиваем автоматическое перемещение в статус todo всех задач из статуса ready. А еще выставим в каждую задачу дату окончания спринта, чтобы на почте видеть уведомления о задачах, которые могут быть просрочены.
Ценность: рутинные действия выполняются автоматически и мы теперь не забудем сделать какую-то мелочь.
И.10 Демо
Весьма сложный и очень полезный пункт, который можно реализовать тогда после успешного выполнения всех предыдущих и при условии, что механизм работает, а не держится на честном слове.
Введение демо для команды позволяет достигать авторизации результата и мотивировать, а заказчику заполнять беклог на основе увиденного результата работы.
Так же на пользу идут семинары, подготовленные командой для команды. Это такое интересное явление, когда копаясь над задачей, кто-то ушел настолько глубоко в тему, что может подготовить интересную лекцию на 15 минут и повысить грамотность всего коллектива. Поощряйте такое.
Вместо заключения
Проведя 9 непростых шагов, вы смогли внести ясности в работу целого отдела в компании, возможно увеличив его эффективность в несколько раз, но со сколькими болями вы столкнулись — не счесть. На некоторые итерации могли уходить месяцы, а иногда без должного напора мог произойти откат к предыдущим шагам, ведь назад идти всегда проще. Но если вы уже здесь, то рад поздравить с прохождением сего тернистого пути.
