Как мы используем agile, scrum и kanban в разработке ПО для управления запасами и прогнозирования спроса

Разработка Forecast Now! изнутри. Наш опыт.

В статье мы хотим рассказать о том, как устроен процесс разработки ПО в нашей компании, какими инструментами пользуемся, с какими проблемами сталкиваемся и как их решаем. Для тех, кто не хочет читать длинный текст, у нас есть 7-минутное видео.

Forecast Now! — программа для управления товарными запасами и прогнозирования спроса. Разработка программы началась в 2011 году с двух человек. Сегодня команда — одна из самых сильных в отрасли на территории РФ. Каждый год выходит четыре-шесть крупных обновления, каждые две недели — минорные версии.

Мы придерживаемся agile-подхода, практикуем scrum и kanban. Вся наша разработка строится на двухнедельных спринтах. У нас есть все стандартные церемонии scrum: ежедневные стендапы, регулярные PBR, покер-планирование и ретроспектива в конце каждого спринта. А также раз в месяц мы проводим внутреннее демо.

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

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

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

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

Это наша kanban-доска. Здесь мы проводим ежедневные стендапы. Каждая строка — отдельный разработчик, стикер — отдельная задача, а столбец — состояние задачи.

В 12 часов разработчики собираются у доски и рассказывают, что было сделано вчера, что планируется сделать сегодня и есть ли какие-то проблемы.

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

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

Но периодически возникали сложности, которые тормозили работу. Например, кто-то мог просто не понимать, что у него есть проблемы с задачей. При реальном общении такие моменты отслеживать легче.

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

Другой положительный эффект — помощь со стороны команды. Когда вся отчетность ведется в онлайне, у людей зачастую нет времени или желания вникать в чужие задачи.

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

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

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

В целом такая визуализация позволяет сделать процессы прозрачными для всей компании. Так как информация всегда на виду в офисе, это влияет и на другие отделы.

Часто сотрудники отдела технической поддержки участвуют в стендапах. В любой момент они могут получить информацию о статусе задачи клиента и ответить на вопросы разработчиков.

Если во время решения задачи возникают какие-то проблемы и нужно дополнительное обсуждение с клиентом, он узнает об этом в тот же день, а не неделю или две спустя.

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

Для этого мы взяли стек решенных задач, сгруппировали между собой схожие по сложности, объемности, затраченному времени и другим параметрам задачи и раздали им метки 1, 2, 3, 5, 8, ..13 и так далее.

Метки увеличиваются как числа последовательности Фибоначчи, потому что с ростом оценки растет и неопределенность. Чем выше оценка, тем выше риск не попасть в эту цифру.

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

Чтобы разработчики не ориентировались друг на друга, сначала проходит скрытое голосование, потом все одновременно показывают результаты. Если оценки участников различаются, владельцы наименьшей и наибольшей оценок подробно поясняют, почему они оценили задачу именно в такое количество story point.

После, с учетом полученной информации, проходит второй этап голосования.

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

Список всех задач по проекту на ближайшее время. Задачи распределены по срочности, важности и времени выполнения. Участник команды, который напрямую взаимодействует с клиентами, может перенести задачу в срочные или, наоборот, убрать ее оттуда.

В спринт попадают два вида задач: внутренние идеи компании по развитию продукта и запросы, которые поступили от клиента.

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

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

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

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

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

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

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

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

Раньше, до перехода на scrum, нередко возникали ситуации, когда срочные задачи растягивались на две-три недели и это было сложно прогнозировать.

Графики показывают продуктивность команды. Каждая линия – отдельный спринт. Цифры — количество story point, которое осталось до конца спринта. Чем их меньше в самом конце спринта, тем лучше отработала команда.

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

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

Анализ общей картины по спринтам дает понимание продуктивности команды в целом. Имея достаточную статистику, мы знаем, на что способна команда, сколько story point сжигает за спринт. А это ключ к повышению качества планирования.

Здесь вся команда собирается, чтобы детально обсудить задачи, спланировать будущие спринты, сделать оценку и провести ретроспективу.

Ретроспектива — это обсуждение и анализ прошедшего спринта всей командой. Мы говорим о том, что произошло за спринт: что было полезно, что было бесполезно, что было вредно.

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

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

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

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

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

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

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

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

Это лицо всей нашей инфраструктуры для контроля качества продукта. Монитор-светофор сигнализирует об отсутствии или наличии ошибок в текущей сборке программы.

Зеленый свет — все в порядке, можно отправлять релиз клиенту. Красный — во время тестов обнаружены проблемы, но пока никто не занялся их исправлением. Желтый — над ошибками уже кто-то работает.

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

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

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

Это последнее нововведение в офисе. На доске мы выписываем актуальных клиентов, их самые большие проблемы, фиксируем наши обязательства перед ними, даты реализации.

Это сделано для того, чтобы у разработчиков было понимание, что они делают, для кого и какие клиентские проблемы они помогают решить.

Так как все остальные инструменты в офисе акцентируют внимание на разработке, такое визуальное соотнесение клиентских болей и разработки позволяет систематизировать информацию в головах людей.

#scrum #agile #спринт