+7 (499) 638-64-11
Попробовать
Постановка и автоматизация процессов разработки ПО

Дисциплинированная гибкая поставка - Disciplined Agile Delivery

23.11.2015 14:48

Скотт Эмблер является старшим методологом по IT в IBM Rational. Недавно у меня была возможность пообщаться со Скоттом о масштабировании Agile для промышленных предприятий, о том, как Agile влияет на руководство проектом и требования в больших командах, и о его фреймворке DAD (Disciplined Agile Delivery).

Хизер Шанхольтцер (ХШ): В чём причины того, что промышленные предприятия всё чаще обращаются к Agile-разработке?

Скотт Эмблер (СЭ): Компании применяют техники Agile, которые могут помочь им увеличить возврат инвестиций (ROI) вложенных в IT, увеличить ценность, поставляемую заказчикам, увеличить качество и улучшить время поставки. В среднем, по факту, Agile способен приносить все эти выгоды. Я каждый год устраиваю опрос об успешности IT-проектов, и с 2006 года он показывает, что гибкие методологии опережают традиционные подходы, даже по масштабу.

ХШ: В чём самые большие трудности применения Agile в масштабе большой команде, и как вы можете помочь команде их преодолеть?

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

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

Есть и другие аспекты масштабирования Agile, как я объяснял в работе «Модель масштабирование Agile». Помимо размера команды вы масштабируете и такие факторы, как географическая удалённость, нормативные требования, сложность предметной области, техническую сложность, организационное распределение, организационную сложность и дисциплину предприятия, - всё это в той или иной степени применимо к каждой команде разработки.

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

ХШ: Как на применение предприятием практик Agile влияют руководство и управление требованиями?

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

Если говорить об управлении требованиями, Agile-команды могут выбирать себе подходящий метод из широкого ряда техник - это может быть и формальное управление требованиями, и бэклог из скрама, и более дисциплированный «стек элементов», и пул элементов, как в Lean, а можно даже не применять никакой особой стратегии вообще. У каждого подхода есть свои преимущества и недостатки, нет одного метода, который подошел бы всем командам.

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

ХШ: Вы разработали гибридный фреймворк Agile-ориентированного процесса под названием Disciplined Agile Delivery (DAD). Расскажите о нем в двух словах. Что вдохновило вас расширить существующие Agile-процессы?

СЭ: Фреймворк DAD - это фреймворк гибридного процесса для Agile-разработки. Его функционал включает в себя покрытие полного цикла разработки от самого начала процесса до боевого релиза, с поддержкой осведомлённости предприятия в явном виде и подхода, ориентированного на цели.

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

«Осведомлённость предприятия» включает в себя деятельность в тесном сотрудничестве с профессионалами предприятия, в том числе архитекторами и инженерами по повторному использованию (если они у вас есть), Agile-управление в явном виде, а также в явном виде поддержку DevOps на протяжении всего жизненного цикла.

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

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

Таким образом, вместе того, чтобы предполагать, что каждый человек является экспертом по процессам и может с лёгкостью внедрить такие методы, как скрам и XP, или изменить под свои нужды такие методы, как RUP, DAD занимает позицию посередине этого всего и описывает, какие у вас есть варианты и какие они сулят выгоды. Эти варианты исходят из множества источников, в том числе скрама, XP, Agile-моделирования, UP, канбана и ещё многих других.

ХШ: Я знаю, что вы регулярно устраиваете опросы по практикам Agile применительно к предприятиям. И как? Были ли результаты, которые вас удивили?

СЭ: Я постоянно запускаю такие опросы, новые объявляются на www.ambysoft.com/surveys. Там же публикуются и результаты, и исходные данные. Опросы полностью открыты, а их результаты не раз использовались выпускниками в дипломных работах. Всякий раз, как я запускаю опрос, это всегда интересно, а результаты неожиданны.

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

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

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

ХШ: Как могут наши читатели узнать больше об этих опросах или принять в них участие?

СЭ: Я бы очень хотел, чтобы читатели приняли участие в опросах, поскольку это один из лучших способов сократить количество риторики вокруг методологий Agile (как в положительном, так и в отрицательном ключе). Самый простой способ сделать это - подписаться на мой твиттер @scottwambler и пройти по ссылке, когда я объявляю новый опрос. Или же можно просто следить за обновлениями моей страницы с опросами.

 

Автор: Хизер Шанхольтцер

Источник: http://www.agileconnection.com/print/int[...]ed-agile-delivery-interview-scott-ambler

Перевод: Александра Родсет

Еще интересные статьи на эту тему: