Введение

Мышление, определяющее практики разработки программного обеспечения

Гибкая разработка программного обеспечения – это подход к разработке, основанный на ценностях, сформулированных Agile Alliance, объединением из 17 практиков в области разработки программного обеспечения в 2001 году. Как задокументировано в их Манифесте гибкой разработки, эти практики отдают приоритет:

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

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

История

Итеративные и инкрементальные методы разработки программного обеспечения можно проследить еще в 1957 году, а эволюционное управление проектами и адаптивная разработка программного обеспечения появились в начале 1970-х годов. В 1990-х годах ряд облегченных методов разработки программного обеспечения развивался в ответ на преобладающие тяжеловесные методы (часто называемые водопадной моделью), которые критики описывали как чрезмерно регламентированные, спланированные и микроуправляемые. Эти облегченные методы включали: быструю разработку приложений (RAD) с 1991 года; унифицированный процесс (UP) и метод разработки динамических систем (DSDM), оба с 1994 года; Scrum, с 1995 года; Crystal Clear и экстремальное программирование (XP), оба с 1996 года; и разработку, управляемую функциями (FDD), с 1997 года. Хотя все они возникли до публикации Agile Manifesto, они теперь коллективно называются гибкими методологиями разработки программного обеспечения. Уже с 1991 года аналогичные изменения происходили в производстве и управленческом мышлении, основанном на принципах бережливого производства (Lean management). В 2001 году семнадцать разработчиков программного обеспечения встретились на курорте в Сноуберде, штат Юта, чтобы обсудить облегченные методы разработки. Среди них были: Кент Бек (Extreme Programming), Уорд Каннингэм (Extreme Programming), Дэйв Томас (PragProg, Ruby), Джефф Сазерленд (Scrum), Кен Швабер (Scrum), Джим Хайсмит (адаптивная разработка программного обеспечения), Алистер Кокберн (Crystal), Роберт С. Мартин (SOLID), Майк Бидл (Scrum), Ари ван Беннекум, Мартин Фаулер (OOAD и UML), Джеймс Греннинг, Эндрю Хант (PragProg, Ruby), Рон Джеффрис (Extreme Programming), Джон Керн, Брайан Марик (Ruby, TDD) и Стив Меллор (OOA). Группа, The Agile Alliance, опубликовала Манифест гибкой разработки программного обеспечения, чтобы направлять управление программными проектами в соответствии с гибкими методологиями разработки. В 2009 году группа, работавшая с Мартином, разработала расширение принципов разработки программного обеспечения – Манифест мастерства разработки программного обеспечения, чтобы направлять гибкую разработку в соответствии с профессиональной этикой и мастерством. В 2011 году Agile Alliance создала Руководство по гибким практикам (переименованное в Agile Glossary в 2016 году) – постоянно развивающуюся открытую базу рабочих определений гибких практик, терминов и элементов, а также интерпретаций и рекомендаций от мирового сообщества практикующих гибкость.

Итеративный, инкрементальный и эволюционный

Большинство методологий гибкой разработки разбивают работу над созданием продукта на небольшие инкременты, минимизируя объем предварительного планирования и проектирования. Итерации, или спринты, – это короткие временные интервалы (timeboxes), обычно длящиеся от одной до четырех недель. Каждая итерация предполагает работу кросс-функциональной команды по всем направлениям: планированию, анализу, проектированию, кодированию, модульному тестированию и приемочному тестированию. В конце итерации работающий продукт демонстрируется заинтересованным сторонам. Это минимизирует общий риск и позволяет продукту быстро адаптироваться к изменениям. Одна итерация может не содержать достаточно функциональности для выпуска на рынок, но цель – иметь готовый к выпуску продукт (с минимальным количеством ошибок) в конце каждой итерации. Благодаря инкрементной разработке продукты получают возможность "часто и рано выявлять и исправлять ошибки" на протяжении каждого итеративного цикла, а не сталкиваться с серьезными проблемами непосредственно перед датой финального релиза. Для выпуска продукта или новых функций может потребоваться несколько итераций. Рабочее программное обеспечение является основным показателем прогресса. Это способствует непосредственному общению, желательно у доски, что сокращает время, обычно затрачиваемое на обмен вопросами и ответами по телефону, в чате, вики или электронной почте. С широким распространением удаленной работы во время пандемии COVID-19 и развитием инструментов было проведено больше исследований, посвященных совместной работе в одном офисе и распределенной работе, которые показывают, что физическое совместное расположение становится все менее значимым. Независимо от выбранной методологии разработки, в каждой команде должен быть представитель заказчика (известный как Product Owner в Scrum). Этот представитель утверждается заинтересованными сторонами для представления их интересов и берет на себя личное обязательство быть доступным для разработчиков, чтобы отвечать на вопросы в течение всей итерации. В конце каждой итерации заинтересованные стороны проекта вместе с представителем заказчика анализируют достигнутый прогресс и переоценивают приоритеты с целью оптимизации возврата инвестиций (ROI) и обеспечения соответствия потребностям заказчика и целям компании. Важность удовлетворения заинтересованных сторон, обеспечиваемая частым взаимодействием и обзором результатов в конце каждого этапа, является причиной, по которой данный подход часто называют клиентоориентированной методологией.

Информационный радиатор

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

Очень короткий цикл обратной связи и адаптации

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

Ориентация на качество

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

Философия

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

Крупномасштабные, оффшорные и распределенные

Широко признано, что гибкая разработка программного обеспечения особенно хорошо подходит для определенных условий, таких как небольшие команды экспертов, работающие над новыми проектами. Проблемы и ограничения, возникающие при внедрении гибких методологий разработки в крупных организациях с устаревшей инфраструктурой, хорошо задокументированы и понятны. В ответ на это был разработан ряд стратегий и подходов для преодоления сложностей, связанных с крупномасштабной разработкой (более 20 разработчиков) или распределенными (не находящимися в одном месте) командами, среди прочих. В настоящее время существует несколько общепризнанных фреймворков, направленных на смягчение или предотвращение этих проблем. Существует множество противоречивых точек зрения относительно эффективности этих фреймворков и их соответствия определению гибкой разработки, и эта область остается предметом активных исследований. Применение гибкой разработки в распределенной среде (когда команды находятся в разных офисах или локациях) обычно называют распределенной гибкой разработкой. Цель состоит в том, чтобы использовать уникальные преимущества каждого подхода. Распределенная разработка позволяет организациям создавать программное обеспечение, стратегически размещая команды в разных частях мира и, по сути, осуществляя разработку круглосуточно (чаще называемую моделью "следуй за солнцем"). С другой стороны, гибкая разработка обеспечивает повышенную прозрачность, непрерывную обратную связь и большую гибкость при адаптации к изменениям.

Опыт и принятие

Хотя на практике гибкие методологии разработки программного обеспечения могут применяться с любой парадигмой программирования или языком, изначально они тесно ассоциировались с объектно-ориентированными средами, такими как Smalltalk, Lisp и впоследствии Java, C#. Первыми, кто начал использовать гибкие методологии, обычно были небольшие и средние команды, работающие над принципиально новыми системами, требования к которым было сложно окончательно сформулировать и которые, вероятно, изменялись в процессе разработки. В этом разделе описываются типичные проблемы, с которыми сталкиваются организации при внедрении гибких методологий разработки программного обеспечения, а также различные способы оценки качества и эффективности гибких команд.

Внутренние оценки

Индекс измерения гибкости, в частности, оценивает разработки по пяти параметрам разработки продукта (длительность, риск, новизна, трудозатраты и взаимодействие). Другие методики основаны на измеримых целях, и одно исследование показывает, что скорость разработки может служить метрикой гибкости. Также существуют инструменты самооценки гибкости для определения, использует ли команда практики гибкой разработки программного обеспечения (тест Nokia, тест Karlskrona, тест из 42 пунктов).

Общественные опросы

Одним из первых исследований, сообщивших о росте качества, производительности и удовлетворенности бизнеса благодаря использованию гибких методологий разработки программного обеспечения, стал опрос, проведенный Shine Technologies с ноября 2002 года по январь 2003 года. Аналогичный опрос, "Состояние Agile", проводится ежегодно, начиная с 2006 года, с участием тысяч представителей сообщества разработчиков программного обеспечения. Он отслеживает тенденции в восприятии преимуществ гибкости, полученные уроки и лучшие практики. Каждый опрос демонстрировал растущее число респондентов, утверждающих, что гибкая разработка программного обеспечения помогает им быстрее выпускать продукты, лучше адаптироваться к меняющимся приоритетам заказчиков и повышать производительность. Опросы также последовательно показывают лучшие результаты при использовании гибких методологий разработки продукта по сравнению с классическим управлением проектами. Однако есть и сообщения о том, что некоторые считают гибкие методологии разработки еще недостаточно зрелыми для проведения масштабных академических исследований их эффективности.

Общие ловушки в разработке гибкого программного обеспечения

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

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

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

Добавление историй к текущей итерации

В гибкой разработке программного обеспечения истории (похожие на описания вариантов использования) обычно используются для определения требований, а итерация – это короткий период времени, в течение которого команда берет на себя обязательства по достижению конкретных целей. Добавление историй к текущей итерации негативно сказывается на эффективной работе. Эти истории следует добавлять в бэклог продукта и расставлять приоритеты для последующей итерации, либо, в редких случаях, итерацию можно отменить. Это не означает, что историю нельзя детализировать. Команды должны учитывать новую информацию, которая может привести к появлению дополнительных задач в рамках истории. Если новая информация препятствует завершению истории в течение итерации, её следует перенести на следующую итерацию. Однако, её приоритет следует пересмотреть относительно всех остальных историй, поскольку новая информация могла изменить первоначальный приоритет.

Отсутствие спонсорской поддержки

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

Недостаточная подготовка

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

Роль владельца продукта не заполнена должным образом

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

Команды не сосредоточены

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

Чрезмерная подготовка/планирование

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

Решение проблем в повседневной жизни

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

Назначение задач

Одним из ожидаемых преимуществ гибкой разработки программного обеспечения является наделение команды полномочиями принимать решения, поскольку именно они наиболее близки к проблеме. Кроме того, решения должны приниматься как можно ближе к моменту реализации, чтобы использовать наиболее актуальную информацию. Если членам команды назначают задачи другие или делают это слишком рано в процессе, преимущества локализованного и своевременного принятия решений могут быть утрачены. Назначение задач также закрепляет членов команды в определенных ролях (например, член команды А всегда выполняет работу с базой данных), что ограничивает возможности для взаимного обучения. Многозадачность со стороны Scrum Master может привести к слишком частым переключениям контекста и снижению продуктивности. Более того, поскольку Scrum Master отвечает за устранение препятствий, мешающих команде двигаться вперед, выгода от продвижения отдельных задач может не компенсировать отложенные препятствия из-за нехватки ресурсов.

Отсутствие автоматизации испытаний

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

Разрешает накопление технической задолженности

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

Фиксированное время, ресурсы, объем и качество

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

Изгорание разработчиков

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

Приложения вне разработки программного обеспечения

По словам Жана Лупа Рише (исследователя Института стратегических инноваций и услуг ESSEC), "этот подход может быть эффективно использован для не программных продуктов и для управления проектами в целом, особенно в областях инноваций и неопределенности". Результатом является продукт или проект, который наилучшим образом соответствует текущим потребностям клиентов и реализуется с минимальными затратами, отходами и во времени, позволяя компаниям быстрее получать прибыль по сравнению с традиционными подходами. Методы гибкой разработки программного обеспечения широко применяются при создании программных продуктов, и некоторые из них используют специфические характеристики программного обеспечения, такие как объектно-ориентированные технологии. Однако эти методы могут быть применены и к разработке не программных продуктов, таких как компьютеры, медицинское оборудование, продукты питания, одежда и музыка. Методы гибкой разработки программного обеспечения также использовались при развертывании и миграции ИТ-инфраструктуры, не связанных с разработкой. Некоторые общие принципы гибкой разработки программного обеспечения нашли применение и в общем управлении (например, в стратегическом планировании, корпоративном управлении, управлении рисками и финансами) под названиями "бизнес-гибкость" или "гибкое управление бизнесом". Принципы гибкой разработки программного обеспечения могут быть использованы и в других сферах жизни, например, при воспитании детей. Их успех в развитии ребенка может быть обусловлен базовыми принципами управления: коммуникацией, адаптивностью и осознанностью. В своей лекции TED Брюс Фейлер рассказал о том, как он применял основные принципы гибкости к управлению домашним хозяйством и воспитанию детей.