Что такое гибкая методика?

Agile — это термин, описывающий подходы к разработке программного обеспечения, которые подчеркивают добавочную доставку, совместную работу команды, постоянное планирование и постоянное обучение. Термин Agile был введен в 2001 году в манифесте Agile. Манифест установил принципы для более эффективного подхода к разработке программного обеспечения. В основном манифест объявляет четыре оператора значения, которые представляют основу движения Agile. Как написано, манифест утверждает:

Мы пришли к значению:

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

Манифест не означает, что элементы справа от этих инструкций не важны или необходимы. Скорее, элементы слева просто более ценны.

Гибкие методы и методики

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

Гибкие методы, которые часто называются платформами, являются комплексными подходами к этапам жизненного цикла DevOps: планирование, разработка, доставка и операции. Они назначают метод для выполнения работы с четкими рекомендациями и принципами.

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

• Планирование Покера — это совместная оценка практики, которая призвана поощрять членов команды поделиться своим пониманием того, что делается . Многие люди находят процесс весело, и это доказало, чтобы помочь помочь команде и лучше оценки.
• Непрерывная интеграция (CI) — это распространенная практика гибкой разработки, которая включает в себя интеграцию изменений кода в основную ветвь часто. Автоматическая сборка проверяет изменения. В результате наблюдается сокращение задолженности по интеграции и постоянно отправляемая основная ветвь.

Эти методики, как и все методики Agile, несут метку Agile, так как они соответствуют принципам манифеста Agile .

Что такое Гибкий подход не является

По мере того как Agile получила популярность, многие стереотипы и неправильное толкование бросили негативную тень на ее эффективность. Легко сказать: "Да, мы делаем гибкий", без какой-либо ответственности. Учитывая этот момент, рассмотрим несколько вещей, которые Гибкий не является.

• Agile не является кодированием ковбоя. Гибкий подход к разработке программного обеспечения не следует путать с "мы посмотрим, как мы идем". Такая идея не может быть дальше от истины. Для гибкой работы требуется определение готового и явного значения, которое поставляется клиентам в каждом спринте. В то время как гибкость значений для отдельных лиц и команд подчеркивает согласованную автономию, чтобы обеспечить увеличение автономии.
• Гибкий подход не без строгости и планирования. Напротив, гибкие методологии и методики обычно подчеркивают дисциплину в планировании. Ключ заключается в постоянном планировании в рамках проекта, а не только планирования заранее. Непрерывное планирование гарантирует, что команда может учиться на работе, которую они выполняют. Благодаря этому подходу они максимизируют отдачу от инвестиций (ROI) планирования.

"Планы бесполезны, но планирование все". - Дуайт Д. Эйзенхауэр

• Agile не является оправданием отсутствия стратегии. Это неправильное представление, вероятно, нанесло наибольшее вред движения Agile в целом. Организации и команды, которые следуют гибкому подходу, абсолютно знают, где они собираются, и результаты, которые они хотят достичь. Распознавание изменений в рамках процесса отличается от сводки в новом направлении каждую неделю, спринт или месяц.
• Гибкий подход не является разработкой без спецификаций. В любом проекте необходимо обеспечить соответствие вашей команды по тому, почему и как работает работа. Гибкий подход к спецификациям включает в себя обеспечение правильного размера спецификаций, а также правильное отражение того, как последовательности команд и обеспечивает работу.
• Agile не может выполнять незапланированную работу и другие прерывания. Важно завершить спринты по расписанию. Но только потому, что проблема возникает, что побочные дорожки разработки не означает, что спринт должен завершиться ошибкой. Teams может планировать прерывания, назначая ресурсы заранее для проблем и непредвиденных проблем. Затем они могут решить эти проблемы, но оставаться на пути к разработке.
• Гибкий подход не подходит для крупных организаций. Распространенная жалоба заключается в том, что совместная работа, ключевой компонент методологий Agile, сложна в крупных командах. Еще один сцепление заключается в том, что масштабируемые подходы к гибкой структуре и методам, которые компрометирует гибкость. Несмотря на эти неправильные представления, можно успешно масштабировать принципы Agile. Сведения о преодолении этих трудностей см. в статье Масштабирование гибкой разработки для больших команд.
• Гибкий подход не является неэффективным. Чтобы адаптироваться к изменяющимся потребностям клиентов, разработчики вкладывают время каждой итерации для демонстрации рабочего продукта и сбора отзывов. Это правда, что эти усилия сокращают время, которое они тратят на развитие. Но включение запросов клиентов в начале экономии значительно экономии времени позже. Когда функции остаются в соответствии с видением клиента, разработчики избегают крупных капитальных ремонтов вниз по линии.
• Гибкий подход не является плохим для современных приложений, которые часто сосредоточены на потоковой передаче данных. Такие проекты обычно включают больше рабочих нагрузок моделирования данных и извлечения-преобразования (ETL), чем пользовательские интерфейсы. Этот факт затрудняет демонстрацию пригодного программного обеспечения в согласованном, жестком графике. Но путем корректировки целей разработчики по-прежнему могут использовать гибкий подход. Вместо выполнения задач каждой итерации разработчики могут сосредоточиться на выполнении экспериментов с данными. Вместо представления рабочего продукта каждые несколько недель они могут лучше понять данные.

Почему гибкая?

Так почему бы кто-нибудь рассмотреть гибкий подход? Ясно, что правила участия вокруг создания программного обеспечения существенно изменились за последние 10-15 лет. Многие из действий выглядят похожими, но ландшафт и среды, где мы применяем их, заметно отличаются.

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

Форрестер Диего Lo Guidice говорит, что лучше всего в своем блоге, преобразование доставки приложений (октябрь 2020 г.).

"Все резко изменилось. Устойчивость, помимо зеленого и чистого, означает, что то, что мы создадим сегодня должны быть легко и быстро изменены завтра. Стратегические планы являются краткосрочными, а планирование и изменение являются непрерывными" — Диего Ло Guidice, Форрестер

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

Следующие шаги

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