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

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

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

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

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

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

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

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

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

Как мы выстраиваем процесс разработки

Kanban-доска

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

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

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

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

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

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

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

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

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

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

Варанкин Дмитрий, руководитель отдела разработки

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

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

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

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

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

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

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

Евгений Викторов, руководитель отдела внедрения

Эталонная оценка задач

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

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

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

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

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

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

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

Бэклог спринта

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

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

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

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

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

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

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

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

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

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

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

График продуктивности команды

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

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

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

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

Ретроспектива

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

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

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

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

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

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

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

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

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

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

Светофор

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

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

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

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

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

Клиентские «боли»

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

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

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

Вместо заключения

С самого начала работы над продуктом мы придерживались agile-подхода. И по мере роста компании вынуждены были пробовать новые методы, чтобы поддерживать продуктивность на хорошем уровне.

Раньше это были отдельные инструменты, но последние полтора года мы активно практикуем scrum со всеми его ритуалами и артефактами.

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

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

Александр Грицай, CEO
0
32 комментария
Написать комментарий...
Артем Богданов

Больше тысячи слов.

Ответить
Развернуть ветку
Forecast NOW!
Автор

Мы ждали этого комментария :)

Ответить
Развернуть ветку
Pavel Zhirnov

Первое же, что заметил в статье))

Ответить
Развернуть ветку
Артем Богданов
Ответить
Развернуть ветку
Forecast NOW!
Автор

:)

Ответить
Развернуть ветку
Стас Попов

Forecast NOW! - классное решение, но цена уж очень кусается. Только крупные предприятия могут потянуть такое. У нас среднего размера компания, и мы долго искали для себя оптимальное решение. И в итоге остановились на min-max.pro. 
Эта система встраивается прямо в 1С, имеет кучу функций и примерно раз в 50 дешевле вашей разработки. Очень довольны) 

Ответить
Развернуть ветку
Forecast NOW!
Автор

Да, вы правы, наше решение рентабельно для складов от 50-100 млн рублей. Если у вас такой склад, то мы можем на ваших данных в режиме моделирования показать, как изменились бы показатели при использовании нашей системы. По нашему опыту это снижение остатков от 10% минимум до 20-30% в среднем без потери (и даже с увеличение уровня сервиса) продаж. Соответственно, окупаемость достигается за +-  1 год.

Ответить
Развернуть ветку
Dmitry Ree

Очень доходчиво и полезно! Видно, что писалось с воодушевлением, чувствуется энергетика. Немного знаком с agile/scrum, все никак понять не мог, при чем тут числа Фибоначчи.. Спасибо, что поделились практическим применением!

Ответить
Развернуть ветку
Forecast NOW!
Автор

Спасибо за ваш отзыв! Рады, что полезно. Еще больше энергетики в видео - статья за 7 минут.

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

Вы настолько подробно это описываете, будто схему progress plans problems изобрели только сейчас в вашей компании :)

Про scrum и канбан туда же. Это звучит так же как покупка молотка и описание как им заколачивать гвозди

Ответить
Развернуть ветку
Forecast NOW!
Автор

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

Ответить
Развернуть ветку
Ksenia Van De Kamp

У вас в списке клиентов числится сеть АЗС Татнефть. Что-то я не встречала у них подобного продукта. Расскажите подробнее о внедрении в этой заправочной сети, раз уж разместили их лого среди своих клиентов.

Ответить
Развернуть ветку
Forecast NOW!
Автор

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

Ответить
Развернуть ветку
Ksenia Van De Kamp

Поняла, спасибо. Информации более чем достаточно)

Ответить
Развернуть ветку
Aleksandr Talalaev

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

Прям приятно видеть/читать подобное, уж слишком часто встречается Agile по книжке, где не понимают сути и то что нужно выстраивать свои процессы, а не условно по бумажке кого-то копировать.. ох больная тема.

Ответить
Развернуть ветку
Саня Карташов

Очень интересная тема! А ваши клиенты принимают и оплачивают продукты с вами на одной scrum-волне (к примеру по часам за один спринт) или всё происходит по старинке: оценка тз, предложение, договор, предоплата и т.д.?

Ответить
Развернуть ветку
Forecast NOW!
Автор

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

Ответить
Развернуть ветку
Jack Shterne

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

Ответить
Развернуть ветку
Forecast NOW!
Автор

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

Ответить
Развернуть ветку
Forecast NOW!
Автор

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

Ответить
Развернуть ветку
Aleksandr Talalaev

100% удобно, начнем с того что здесь их(разработчкиов) слышат, именно слышат наконецто доугие члены команды/менеджеры/отдел продаж. 

Почти все скептики/интроверты затем меняют свое мнения, прихнают что подход работает. Главное делать это не в показательном режиме для галочки.

Ответить
Развернуть ветку
Sofron Vagankov

А почему в тестировании так мало задач? Можете подробнее рассказать как у вас тестирование осуществляется? Сколько в команде тестировщиков и разработчиков?

Ответить
Развернуть ветку
Forecast NOW!
Автор

Это был уже конец спринта. Про тестирование, наверное, напишем отдельную статью. Есть что рассказать. Есть и ручное тестирование, конечно же, но много и автоматического. Автоматические тесты графического интерфейса, юнит тесты, регрессионные тесты, синхронизационные, бенчмарк, интеграционные, тесты дымовые, все это вертится на TeamCity. Мы придерживаемся (стараемся) подхода разработка через тестирование и TDD. Выделенный тестировщик у нас один на ручное тестирование. Мы предпочитаем автоматические тесты (в т.ч. граф. интерфейса), так как они не одноразовые. За их написание отвечают разработчики. Команда разработчиков состоит из семи человек. Это, пожалуй, верхний предел для одной скрам команды по числу разработчиков.

Ответить
Развернуть ветку
Forecast NOW!
Автор

Спасибо за ваши отзывы!

Ответить
Развернуть ветку
Aleksey Krenvalk

Прямо как серию "Кремниевой долины" пересмотрел))

Ответить
Развернуть ветку
Forecast NOW!
Автор

Спасибо, если еще добавить наши инвестиционные истории, все фейлы за 8 лет, то вполне себе получится серия :)

Ответить
Развернуть ветку
Who Am-I

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

Ответить
Развернуть ветку
Forecast NOW!
Автор

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

Ответить
Развернуть ветку
Igor Artamonov

спасибо, очень позновательно, как это работает в "живой среде"

Ответить
Развернуть ветку
Alexey Sorokin

Единственное что интересно. Вы реально сильно потратились ради одной статьи на vc с более-менее избитой темой?

Ответить
Развернуть ветку
Denis Fedorez

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

Ответить
Развернуть ветку
Forecast NOW!
Автор

Спасибо за ваше мнение. Всегда кого-то что-то будет бесить, это нормально, и нам не важно лофт это или не лофт, нам важно, что это нравится самой команде, ведь именно они проводят здесь 8 часов рабочего времени. 

Ответить
Развернуть ветку
29 комментариев
Раскрывать всегда