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

С момента публикации в 2001 г. «Манифеста о гибкой разработке программного обеспечения Agile» новый методологический подход успел собрать внушительную армию как сторонников, так и противников.

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

Возможности

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

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

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

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

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

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

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

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

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

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

Что дальше?

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

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

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

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