Адаптивная разработка программного обеспечения: как команды создают продукты, учитывая возможность изменений

Основные моменты

• Методология адаптивной разработки ПО (Adaptive software development, ASD) помогает командам управлять неопределенностью, корректируя планы и непрерывно совершенствуя свою работу на основе обратной связи.

• Подход ASD основан на трех повторяющихся этапах: предположениях, совместной работе и получении выводов.

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

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

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

Если команда придерживается жестких планов, то им, возможно, придется трудно, когда подобные изменения возникнут в середине проекта.

Адаптивная разработка ПО предполагает иной подход. Согласно ему, изменения — это не нарушение процесса разработки, а его неотъемлемая часть. 

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

Что такое адаптивная разработка программного обеспечения (ASD)?

Адаптивная разработка ПО (ASD) — это подход к разработке ПО, предназначенный для проектов, в которых требования, приоритеты и технические знания могут со временем меняться.

Методология ASD появилась как результат работы Джима Хайсмита и Сэма Байера в период бурного развития практик разработки приложений в 1990-х годах. Эта методология предназначалась для сложных программных проектов, в которых команды не могли заранее предусмотреть все требования.

В отличие от более жестких моделей, методология ASD основана на том, что неопределенность в ходе цикла разработки ПО неизбежна. Это отражено в циклическом повторении трех этапов ASD. 

1. Предположения

2. Совместная работа

3. Выводы 

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

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

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

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

Ключевые особенности методологии ASD

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

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

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

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

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

• Гибкость. Команды регулярно пересматривают объем работ, приоритеты, риски и зависимости по мере развития проектов, сохраняя при этом ответственность за результат.

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

Принцип действия адаптивного подхода в разработке ПО

Ниже приведен краткий обзор содержания каждого из трех повторяющихся этапов ASD, за которым следуют подробные пояснения.

Предположения: планирование с учетом неопределенности

Этап предположений ориентирован на реалистичное планирование в условиях, когда не все требования заранее известны.

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

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

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

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

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

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

Совместная работа: решение проблем с участием разных ролей

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

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

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

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

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

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

Выводы: повышение качества на основе отзывов

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

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

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

Кроме того, они могут улучшать продукт, анализируя его внедрение клиентами и технические показатели.

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

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

Преимущества и недостатки адаптивной разработки ПО

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

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

Адаптивная разработка ПО в сравнении с другими методологиями

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

Когда лучше использовать адаптивную разработку программного обеспечения

Адаптивная разработка ПО целесообразна в тех случаях, когда у команды есть четкая цель, но пути ее достижения могут меняться. Преимущества ASD, как правило, реализуются, когда:

• Вероятно, что требования будут меняться в ходе проекта.

• Отзывы клиентов могут повлиять на принятие решений в процессе разработки.

• Выпуск, тестирование и улучшение продуктов осуществляются короткими циклами.

• Приоритеты могут меняться под влиянием различных заинтересованных сторон.

• Из-за технической сложности продукта возникают непредвиденные риски или зависимости.

• Команды создают новые продукты или продукты для незнакомых рынков.

• Успешную поставку определяют короткие итерации и использование новой информации.

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

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

Помогите команде адаптироваться к меняющимся требованиям к ПО

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

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

Попробуйте Jira и узнайте, как этот инструмент помогает командам, работающим по методике адаптивной разработки, управлять меняющимися требованиями, растущими ожиданиями клиентов и сложными средами поставки.

Часто задаваемые вопросы об адаптивной разработке программного обеспечения

Кто придумал адаптивную разработку программного обеспечения?

Идею этой методики предложили Джим Хайсмит и Сэм Байер. Они развили концепции быстрой разработки приложений, чтобы помочь командам управлять сложными проектами с меняющимися требованиями.

Требуются ли для адаптивной разработки ПО короткие циклы релизов?

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

Какой объем документации необходим при адаптивной разработке программного обеспечения?

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