Scrum-ban


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

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

    Исходные данные:
    Отличительными особенностями являлись:
    • На момент принятия проекта он был в разработке уже более двух лет;
    • Реализована внушительная часть функционала;
    • Разработано множество как востребованных, так и не актуальных решений.

    Нашей команде предстояло завершить финальный этап проекта.

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

    Условие:

    1. Планирование

    В процессе планирования (Planning Poker, с картами и относительными единицами измерения трудоемкости S, M, L, XL, XXL), несмотря на то, что задачи были детально проработаны, и сформированные требования не вызывали никаких дополнительных вопросов, практическая оценка оказалась далеко не прозрачной, нижеследующие условия сформировали первую проблему:

    Проблема №1 — Планирование, которое быстро теряет свою актуальность:
    • Отсутствие информации о способах и методах разработки ранее реализованного функционала;
    • Наличие незавершенных задач;
    • Невозможность оценить стадию и процентное выполнение задач без детального длительного погружения в исходные материалы;
    • Проведение многочасового планирования нерационально.

    Планирование не рационально, по той причине, что «подводные камни» спрятанные в унаследованном коде и сотнях зависимостях, невозможно предвидеть на начальных этапах работы с кодом.

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

    Проблема №2 — Много срочных внеплановых задач

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

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

    Проблема №3 — Изменения приоритетов задач в ходе итерации.

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

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

    Решение:

    Для этого было принято решение разобрать две Agile методологии (Scrum и Kanban) на инструменты, взять только необходимое, поставить разработку на конвейер.

    За основу взяли подход организации процесса разработки, предлагаемый методологией Kanban и оставили несколько инструментов от Scrum — для прозрачности анализа по проделанной работе:


    • Аналитик осуществляет документирование и разбор задач по поступлению, складывает их в backlog.
    • Product Owner корректирует приоритеты задач.
    • Предварительное планирование не осуществляется.
    • Разработчик берет в разработку задачу с высшим приоритетом из backlog .
    • Завершенная задача поступает в тестирование.
    • Проводятся необходимые проверки.
    • Принимается решение о возможности выноса задачи на боевые сервера, или повторного возвращения в разработку.
    • При отсутствии замечаний задача выносится на stage сервер, где повторно проверятся на регресии или ожидает другие задачи, без которых ее вынос на боевой сервер не возможен.
    • Весь жизненный цикл проекта разделен на 2-х недельные итерации. Они носят лишь формальный характер для возможности оценить динамику производительности, а также хронологически упрощают отслеживание выполненных задач.
    • Проведения демонстрации по итогам каждой итерации по упрощенной схеме, демонстрируются только те задачи, которые требуют дополнительных комментариев, остальное заказчик в состоянии просмотреть сам.
    • Каждая итерация заканчивается ретроспективой.

    Основные инструменты, используемые нами в этом проекте:
    Scrum Kanban
    • Роли (Product Owner / Scrum Master / Команда)
    • Приоритезированный Product Backlog
    • Ограниченные по времени итерации.
    • Демонстрации по окончанию итерации
    • Daily Stand-up

    • Как основная метрика для планирования и улучшения процессов используется время выполнения задачи.
    • Оценки задач опциональны
    • Можно добавлять новые задачи, в любой момент времени.
    • Непрерывный поток задач не привязанный к итерации


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

    Результаты:

    Методика показала свои результаты уже при первой итерации:

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

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

    Вывод:

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

    Автор: Сыроваткин Борис — /Инженер тестирования/Департамент разработки Softline
    Softline
    Company

    Comments 17

      +1
      Куда-то пропала проблема 2 :)
      Можн проапгрейдить, добавив количество задач на каждом этапе.
      Картинка красивая.
        0
        А можно поконкретнее по поводу количества задач? Что именно было бы интересно?
          0
          я говорю про то, что у вас не указана основная фича канбана — ограничение по максимальному количеству задач на каждом этапе, штука как мне кажется классная, стоит добавить в вашу систему :)
          а еще перед релизом можно их копить и релизить фичи не постоянно, а пачками по 5-7
            0
            Штука и правда очень хорошая, помогает выявить узкие места, но, по всей видимости, в этом не было необходимости на тот момент.
        0
        Интересная статья. Спасибо автору :)
        А скажите, у вас аналитика включена в канбан-цепочку? С какого момента вы начинаете мерять прохождение задачи? С момента начала проработки требований или тогда, когда выуживаете из бэклога?
        Случалось ли такое, что задача, уже поступившая в разработку, сдвигалась в пользу срочной, более приоритетной задачи?
          +1
          В данном случае был большой запас по аналитике, и в канбан цепочку мы ее не включали. Требования разрабатывались парралельно процессу разработки.
          По поводу срочных задач — да, такое было довольно часто, мы старались не бросать незавршенные задачи, но иногда приходилось что-то ставить на паузу в пользу более срочной задачи.
          0
          Спасибо за статью :)

          К автору есть несколько вопросов.

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

          К примеру, тривиальная система по обработке заказов: клиент регистрируется, формирует заказ,
          отправляет заказ, менеджер его обрабатывает, посылает запрос складу, склад формирует накладные,
          отправляет заказ клиенту, потом менеджер фиксирует факт оплаты и закрывает заказ.

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

          Можно, допустим, предварительно сделать детальное проектирование всего, но,
          как известно, это не круто :)

          Второй вопрос:
          данная система предполагает, что задачи делаются и вычеркиваются из списка последовательно.
          Но часто бывает следующее:
          Задача1, Задача2, Задача3 — связаны.
          И оптимальный, возможно :), путь решения — реализовать 70% функционала каждой задачи, после чего
          выпустить релиз. А остальное доделать в следующей итерации(-ях).

          Как вы поступаете в таких случаях?
            0
            Если релиз какой-то задачи не возможен без другой задачи, она ожидает на stage сервере, пока функционал не будет реализован полностью. После чего есть возможность провести полноценное интеграционное тестирование, затем на боевой сервер выносится группа задач
              0
              Стоит дополнить по первой части вопроса:
              В этом конкретном случае ситуация, описанная в первом примере, не составляла проблем, т.к. проект действующий, с уже реализованными основными возможностями, мы занимались добавлением достаточно небольших улучшений и дополнений, попутно исправляя баги.
              Разработка системы с нуля имеет свои особенности, и подобная схема работы может быть не так эффективна.

              Что касается второй части вопроса, то тут желательно стараться максимально дробить задачи, как раз для того, чтобы иметь возможность сначала реализовать работающий костяк, а потом заниматься улучшениями. А в процесс это вписывается довольно просто — «улучшение задачи№1 — это задача№2»
            +1
            В случае 1-2недельных итераций всегда есть время, чтобы обкатать изменения на боевом сервере. Если обнаруживаем баг в новой версии, то сразу же откатываемся на предыдущую и правим баг. Если нет — считаем версию стабильной.

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

            В результате, никогда нельзя сказать, что есть стабильная версия + вероятность авралов, связанных со срочным исправлением багов, дабы не откатываться. Как считаете?
              0
              Не могу не согласиться, но всегда есть особенности. Систему требовалось построить так, чтобы релиз срочного исправления не был стрессом для процесса и команды. На практике же, работы, ведущиеся по плану, выпускались 1-2 раза в неделю, иногда реже.
              Что касается стабильности релизов, мы традиционно используем CI практику, что, является достаточным для обеспечения необходимого качества.
                0
                Применимость CI во многом обусловлена пригодностью системы к авто-тестирвоанию. Так что тут вас просто повезло в том смысле, что если бы унаследованная система оказалась спагетти — то и от CI было бы мало толку в силу невозможности/неэффективности автотестов
                  0
                  В статье как раз говориться о том, что нужно искать решения для своего проекта на основе его особенностей.
              0
              Посмотрел картинку изобретенного процесса — не совсем понял, что же «нового».
              Кроме того — в тексте формулируются 3 «проблемы» которые возникли перед проектной командой, которые и решил новый способ организации. Не совсем понятно как предложенный способ решает 3ю проблему и в чём преимущество перед традиционными итерационными методами с очередями заданий и обратными связями.
              Сложилось ощущение, что автор находится во власти «предвзятости выжившего», указывая причиной успеха «новую» методику.
                0
                В данной схеме нет ничего нового, все это стандартные инструменты Scrum и Kanban, да и само по себе совмещение этих методологий общепринятая практика. Цель статьи — показать на реальном примере, что может быть причиной для пересмотрения своего процесса разработки, побудить непосредственно участников команд к изучению и использованию новых инструментов.
                По поводу 3-й проблемы — используя данную схему работы мы получили необходимую гибкость для того, чтобы постоянные изменения в плане как можно меньше отражались на работе команды.
                0
                Красиво и понятно расписано. Хорошая статья.
                Работаю по примерно такой же схеме. Но разница с Вашими проектами в том, что изменяемые требования и приоритеты у меня в каждом проекте.
                В большинстве проектов используем Канбановское ограничение по задачам на определенных стадиях в дополнение к Вашему гибриду Скрам-Бан. В контракте эти ограничения прописаны. Лично мое мнение — этот гибрид методологий самый идеальный, разве что можно включить еще коллективное владение кодом (XP) и ревьювинг.
                  0
                  Смысл проделанных ритуальных действий — в отказе от Scrum. Проблема была в том, что вы работали по скраму. Как только перестали — стало хорошо.

                  Only users with full accounts can post comments. Log in, please.