Scrum-ban

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

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

Исходные данные:
Отличительными особенностями являлись:

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

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

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

Условие:

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

Проблема №1 — Планирование, которое быстро теряет свою актуальность:

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

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

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

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

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

Решение:

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

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

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

Основные инструменты, используемые нами в этом проекте:

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

Результаты:

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

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

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

Вывод:

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

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

Автор: Softliner