Применение принципов Agile на практике

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

Возможности

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

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

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

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

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

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

  • ¾ – быть самоорганизующейся,
  • ¾ – быть кросс-функциональными, обладать всеми необходимыми навыками,
  • ¾ – нести коллективную ответственность за создание Инкремента.

Рекомендуемый размер
команды, согласно Agile, – 7 (плюс-минус 2)
человек. С
учетом требований к команде были выбраны следующие сотрудники компании:

  • ¾ – представитель отдела продаж;
  • ¾ – представитель колл-центра;
  • ¾ – системный администратор компании;
  • ¾ – представитель отдела маркетинга и рекламы.

Таким образом, размер
команды составил 5 человек.

Что дальше?

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

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

Таблица 1 – Бэклог продукта
Таблица 1 – Бэклог продукта
  • ¾ – планирование спринта не более 2 часов;
  • ¾ – спринт с периодичностью 1 неделя;
  • ¾ – ежедневный Scrum-митинг не более 15 минут;
  • ¾ – ретроспектива спринта не более 1 часа.
Рисунок 1 – Схема продвижения команды разработки к спринту
Рисунок 1 – Схема продвижения команды разработки к спринту

Наибольшей
детализацией подверглась задача №2, которая была разбита на более мелкие задачи
с предварительной их оценкой по времени выполнения: анализ того, как это
происходит сейчас; запрос статистики наиболее распространенных вопросов-ответов
на тему запросов у колл-центра; проведение анализа вопросов в колл-центре; запрос
поведенческой статистики по сайту компании; разработка матрицы для анализа
статистики сайта компании и т.д. Решение перечисленных подзадач было
сопоставлено с трудозатратами и результатами выполнения этапов (подготовка карты
существующего процесса, оформление отчета, формирование карты цепочек наиболее
часто возникающих вопросов и ответов, подготовка таблиц со статистическими
данными о незавершенных покупках туров клиентами и т.д.).

Ретроспектива спринта по реализации 2-й задачи бэклога представлена в таблице 2.

Таблица 2 – ретроспектива спринта по реализации 2-й задачи бэклога
Таблица 2 – ретроспектива спринта по реализации 2-й задачи бэклога

Например, на первой ретроспективе
было обсуждено, что будет сделано и как будет выполнена работа, а также цель спринта. С
учетом общего доступного за один спринт времени работы команды (4 человек * 8
часов * 5 дней = 160 часов) и по приоритетности задач для первого
спринта, был выбран ряд задач из бэклога. Бизнес-целью от владельца продукта на
этом этапе стало сокращение времени реакции на вопросы клиентов, увеличение
количества завершенных сделок и т.д.

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

Таблица 3 – Первый спринт по реализации ряда задач бэкл
Таблица 3 – Первый спринт по реализации ряда задач бэкл

Последние штрихи

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

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

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

Итог

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

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

Делаем выводы

Рассмотренный пример
касался разработки несложного программного продукта. Компания-разработчик
использовала собственные наработки, а также известные на рынке решения. Можно
ли было в данном случае отказаться от использования Agile? Вполне. Более того, в чисто маркетинговых целях для
компании-разработчика использование традиционного «водопада» было бы наилучшим
решением более понятным для заказчика.

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

Константин
Добрянский, к.э.н.

Специально для сайта ITWORLD.UZ. Новость взята с сайта Библиотека программиста