Цель этой статьи — научить вас методологии Agile или процессу Agile простым и легким способом. Основная философия Agile заключается в том, чтобы объединять людей для совместной работы и достижения общей цели. Здесь мы фокусируемся на том, как команда может работать вместе, планировать, выполнять и поставлять качественное ПО в соответствии с гибким мышлением.
Agile также является типом современного SDLC. В этой статье вы познакомитесь с базовой концепцией методологии Agile, ее принципами и философией, различными приемами и способами их использования на работе. Сфера применения Agile не ограничена разработчиками программного обеспечения, но и распространяется на технических руководителей, инженеров, менеджеров по продуктам, тестировщиков и всех, кто связан с разработкой программного обеспечения. Agile процесс является гибким, быстрым и способствует непрерывной разработке и улучшению качества продукта.
Потребность в гибкой методологии
Прежде чем вы адаптируетесь к Agile процессу, вы должны сначала признать, что у устаревшего способа разработки программного обеспечения «Waterfall» было много пробелов, которые нужно заполнить. Последовательность «Планировать, Проектировать, Выполнять, Проверять, Выкладывать» может работать для создания мобильных приложений или инфраструктурных проектов, но не для создания Программных приложений. В динамичной бизнес-среде, где затраты и конкуренция ведут к изменениям, методология Agile успешно смогла найти тонкий баланс между ожиданиями и исполнением.
Зачем нужен Agile бизнесу? Agile что это такое простыми словами? Артур Нек
Что такое Agile методология?
Agile методология — это современный метод разработки программного обеспечения для выполнения проекта от начала до конца. Он вводит концепцию быстрого отказа, что означает лишь быструю обратную связь о проделанной работе. Выполняя таким образом, он ожидает снижения риска неудачи после нескольких месяцев, проведенных в разработке проекта, или позднего обнаружения несоответствия в требованиях. Agile определяет систему ценностей, в которой команды и отдельные лица получают больше прав на планирование, проектирование, разработку и выполнение. Это внушает доверие, уверенность и доброжелательность среди них.
Успех гибкого процесса зависит от команды и каждого участника, который будет работать напрямую с клиентом, чтобы понять реальную картину и предложить решения. Ниже приведены важные факторы методологии Agile.
Короткие итерации
Унаследованные процессы разработки программного обеспечения, такие как Waterfall, имели такие фазы, как сбор требований, планирование, проектирование, кодирование, тестирование и выпуск.
Методология Agile, напротив направлена на предоставление всего выпуска в виде приращений за пару недель и полностью функциональной версии за несколько месяцев.
Коммуникация, общение внутри команды
В Agile, команды ежедневно встречаются, обмениваются информацией, обсуждают препятствия на каждом этапе проекта. Такое сотрудничество и обмен идеями гарантируют, что релиз останется на ходу, даже если требования немного изменится.
Обратная связь
Так как команда предоставляет функциональность небольшими порциями, они получают быструю обратную связь от Dev, QA, PO и клиентов. Именно так методология Agile помогает регулярно отслеживать ход цикла разработки.
Доверие
В Agile команде, каждый участник самоорганизуется. Процесс, поддерживаемый руководством, дает им возможность понять цели и определить их соответствующие пути для достижения успеха.
Согласование
Гибкая команда может быстро выровнять и настроить процесс в зависимости от необходимости. Принцип KIS или Keep It Simple — это то, чем они должны руководствоваться.
Сроки разработки гибкого программного обеспечения
Индустрия программного обеспечения пережила небольшой кризис в начале 1990-х годов. Некоторые назвали это «кризисом разработки приложений», а некоторые назвали его «задержкой доставки приложений». Проблема заключалась в неспособности удовлетворить потребности клиентов. Кроме того, процессы в то время занимали много времени.
Они использовали подход, основанный на временной шкале, когда процесс разработки был последовательным, и клиентам приходилось ждать до самого последнего шага. Чем больше время доставки, тем больше у клиентов шансов изменить свои потребности. Таким образом, к тому времени, когда заявка была готова, первоначальные требования утратили бы актуальность.
Следовательно, профессиональные лидеры индустрии программного обеспечения должны были придумать новый подход к решению вышеуказанных проблем. В 2001 году некоторые из этих лидеров встретились в Юте и составили концепцию идеи Agile. Все они были синхронизированы, чтобы материализовать этот процесс и признали его на отраслевом уровне. Они также разработали основные гибкие принципы и назвали документ Agile манифестом.
Что такое Agile манифест?
Agile манифест — это рекомендация, в которой изложены ценности и принципы, которым необходимо следовать в методологии Agile.
Он включает в себя четыре основополагающие ценности и двенадцать принципов. У каждого есть цель, чтобы помочь исследовать лучшие способы разработки программного обеспечения.
Agile манифест подразумевает четкую и измеримую структуру и поощряет итеративную разработку, совместную работу и принятие изменений.
Вы можете прочитать о ценностях и принципах Agile манифеста ниже:
- Доверяйте людям и предпочитайте взаимодействие, а не процессы и инструменты
- Сосредоточьтесь на предоставлении рабочего программного обеспечения, а не написанию документации
- Больше вовлечения клиентов, чем просто обсуждения условий
- Готовность приспосабливаться к изменениям вместо того, чтобы быть жестко идти по плану
- Короткие циклы разработки, быстрая доставка и довольный клиент
- Принять изменения объема, пересмотреть цели
- Непрерывная поставка рабочего программного обеспечения
- Сотрудничество между всеми заинтересованными сторонами на протяжении всего проекта
- Показать доверие к вовлеченным людям
- Разрешить прозрачные взаимодействия
- Рабочее программное обеспечение определяет прогресс
- Agile процессы для нормализации скорости разработки
- Связь между дизайном и технической реализацией
- Простота
- Самоорганизация — ключ к хорошей архитектуре, требованиям и дизайну.
- Пересмотр, как стать более эффективным
Люди, следующие методологии Agile, должны соответствовать этим ценностям и принципам. Agile манифест дает общее понимание о методах жизненного цикла гибкой разработки.
Agile Управление проектами
Гибкое управление проектами — это проверенный метод для своевременного создания сложных проектов. Он подчеркивает следующие аспекты.
- Сотрудничество,
- Гибкость,
- Постоянное улучшение и
Качественные результаты.
Он использует шесть основных «результатов» для мониторинга прогресса и выпуска продукта.
Видение продукта
Резюме, которое определяет цели продукта.
Дорожная карта продукта
Общий обзор требований к реализации.
Backlog продукта
Полный список возможностей, которые будут добавлены в проект.
План выпуска
Графический документ, показывающий ход релиза.
Backlog cпринта
Список пользовательских историй, выбранных в последнем спринте.
Инкремент
Рабочий продукт с функциями, реализованными в текущем цикле спринта.
Существует множество платформ для управления Agile-проектами, которые вы можете выбрать и начать разработку продукта. Каждый из них имеет уникальный набор функций и терминологию. Но все они следуют одним и тем же принципам и практикам.
Наиболее известные из них — Scrum и Kanban, поддерживающие жизненный цикл разработки Agile.
Подводя итоги
Действительно, Agile методология — это мощный инструмент для групп разработчиков программного обеспечения, которые ищут гибкую стратегию для разработки продуктов. Доказано, что Agile также относится к индустрии программного обеспечения. Любой ИТ-бизнес, которому нужен быстрый план действий, может использовать Agile для улучшения взаимодействия с клиентами, эффективной командной работы, осознанных изменений и, тем не менее, качественных результатов.
Источник: dev-gang.ru
Что такое гибкая методика?
Agile — это термин, описывающий подходы к разработке программного обеспечения, которые подчеркивают добавочную доставку, совместную работу команды, непрерывное планирование и непрерывное обучение. Термин Agile был введен в 2001 году в манифесте Agile. Манифест установил принципы для более эффективного подхода к разработке программного обеспечения. В основном манифест объявляет четыре оператора value, которые представляют основу движения Agile. Как записано, манифест заявляет:
Мы пришли к значению:
- Лица и взаимодействия над процессами и инструментами.
- Работающее программное обеспечение важнее, чем подробная документация
- Сотрудничество с клиентами важнее, чем переговоры по контракту
- Реагирование на изменение после выполнения плана.
Манифест не подразумевает, что элементы в правой части этих инструкций не являются важными или необходимыми. Скорее, элементы слева просто более ценны.
Гибкие методы и методики
Важно понимать, что Agile не является вещью. Вы не делаете Agile. Скорее, Agile — это менталитет, который управляет подходом к разработке программного обеспечения. Поскольку нет единого подхода, который работает для всех ситуаций, термин Agile пришел к представлению различных методов и методик, которые соответствуют инструкциям значения в манифесте.
Гибкие методы, которые часто называются платформами, являются комплексными подходами к этапам жизненного цикла DevOps: планирование, разработка, доставка и операции. Они назначают метод для выполнения работы с четкими рекомендациями и принципами.
Scrum является наиболее распространенной платформой Agile, и той, с которую начинается большинство людей. С другой стороны, гибкие методики — это методы, применяемые на этапах жизненного цикла разработки программного обеспечения.
- Planning Poker — это практика совместной оценки, которая призвана поощрять участников команды поделиться своим пониманием того, что значит. Многие люди находят процесс весело, и это оказалось, чтобы помочь способствовать командной работе и лучшим оценкам.
- Непрерывная интеграция (CI) — это распространенная практика гибкой разработки, включающая частое интеграцию изменений кода в основную ветвь. Автоматическая сборка проверяет изменения. В результате наблюдается сокращение задолженности по интеграции и постоянно отправляемая основная ветвь.
Эти методики, как и все методики Agile, несут метку Agile, так как они соответствуют принципам манифеста Agile .
То, что agile не является
По мере того как Agile получила популярность, многие стереотипы и неправильные интерпретации бросили отрицательную тень на ее эффективность. Легко сказать: «Да, мы делаем agile», без какой-либо ответственности. Учитывая этот момент, рассмотрим несколько вещей, которые Agile не является.
- Agile не является ковбойского кодирования. Гибкий подход к разработке программного обеспечения не следует путать с подходом «мы посмотрим, как мы идем». Такая идея не может быть дальше от истины. Для гибкой разработки требуется определение готового и явного значения, которое доставляется клиентам в каждом спринте. Хотя гибкие ценности автономии для отдельных лиц и команд, она подчеркивает согласованную автономию, чтобы обеспечить повышенную автономию.
- Agile не без строгости и планирования. Напротив, гибкие методологии и практики обычно подчеркивают дисциплину в планировании. Ключевым фактором является непрерывное планирование всего проекта, а не просто планирование заранее. Непрерывное планирование гарантирует, что команда может учиться на работе, которую они выполняют. Благодаря этому подходу они максимизируют рентабельность инвестиций (ROI) планирования.
«Планы бесполезны, но планирование все». — Дуайт Д. Эйзенхауэр
- Agile не является оправданием отсутствия стратегии развития. Это неправильное заблуждение, вероятно, причинило наибольший вред гибкому движению в целом. Организации и команды, которые следуют гибкому подходу, абсолютно точно знают, куда они идут, и результаты, которые они хотят достичь. Распознавание изменений в рамках процесса отличается от поворота в новом направлении каждую неделю, спринт или месяц.
- Agile не является разработкой без спецификаций. В любом проекте необходимо обеспечить соответствие вашей команды тому, почему и как это происходит. Гибкий подход к спецификациям включает обеспечение правильного размера спецификаций и правильное отображение того, как последовательности команд и обеспечивает работу.
- Agile не может поддерживать незапланированную работу и другие прерывания. Важно выполнить спринты по расписанию. Но только потому, что проблема возникает, что разработка побочных дорожек не означает, что спринт должен завершиться неудачей. Teams может планировать прерывания, назначая ресурсы заранее для проблем и непредвиденных проблем. Затем они могут решить эти проблемы, но следить за развитием.
- Гибкие подходы не подходит для крупных организаций. Распространенная жалоба заключается в том, что совместная работа, ключевой компонент методологий Agile, сложна в крупных командах. Другая хватка заключается в том, что масштабируемые подходы к Agile вводят структуру и методы, которые компрометации гибкости. Несмотря на эти недоумения, можно успешно масштабировать принципы Agile. Сведения о преодолении этих трудностей см. в статье Масштабирование гибкой разработки для крупных команд.
- Гибкий подход не является неэффективным. Чтобы адаптироваться к изменяющимся потребностям клиентов, разработчики вкладывают время в каждую итерацию для демонстрации рабочего продукта и сбора отзывов. Это правда, что эти усилия сокращают время, которое они тратят на развитие. Но включение запросов клиентов на ранних этапах экономии значительно экономит время позже. Когда функции остаются в соответствии с видением клиента, разработчики избегают крупных капитальных ремонтов вниз по линии.
- Agile не подходит для современных приложений, которые часто ориентированы на потоковую передачу данных. Такие проекты обычно включают в себя больше рабочих нагрузок моделирования данных и извлечения,преобразования и загрузки (ETL), чем пользовательские интерфейсы. Этот факт затрудняет демонстрацию пригодного программного обеспечения в согласованном и жестком графике. Но путем корректировки целей разработчики по-прежнему могут использовать гибкий подход. Вместо выполнения задач каждой итерации разработчики могут сосредоточиться на выполнении экспериментов с данными. Вместо представления рабочего продукта каждые несколько недель они могут стремиться лучше понять данные.
Зачем гибко?
Так почему бы кто-нибудь рассмотреть гибкий подход? Ясно, что правила взаимодействия вокруг создания программного обеспечения существенно изменились за последние 10-15 лет. Многие действия выглядят похожими, но ландшафт и среды, в которых мы применяем их, заметно отличаются.
- Сравните то, что это похоже на покупку программного обеспечения сегодня с начала 2000-х годов. Как часто люди ездят в магазин, чтобы купить бизнес-программное обеспечение?
- Рассмотрите способ сбора отзывов от клиентов о продуктах. Как команда поняла, что люди думали о своем программном обеспечении перед социальными сетями?
- Рассмотрим, как часто команда хочет обновить и улучшить программное обеспечение, которое они доставляют. Ежегодные обновления больше не станут возможными в отношении современных конкуренций.
Forrester Диего Lo Guidice говорит, что лучше всего в своем блоге, Преобразование доставки приложений (октябрь 2020 г.).
«Все резко изменилось. Устойчивость, помимо зеленого и чистого, означает, что то, что мы строим сегодня должны быть легко и быстро изменены завтра. Стратегические планы являются краткосрочными, и планирование и изменение являются непрерывными». — Диего Ло Гвидис, Форрестер
Правила изменились, и организации по всему миру теперь адаптировать свой подход к разработке программного обеспечения соответствующим образом. Гибкие методы и методики не обещают решить каждую проблему. Но они обещают создать культуру и среду, где решения появляются через совместную работу, непрерывное планирование и обучение, и желание поставлять высококачественное программное обеспечение чаще.
Следующие шаги
Решение принять гибкий маршрут к разработке программного обеспечения может представить некоторые интересные возможности для улучшения процесса DevOps. Один из ключевых рекомендаций посвящен тому, как гибкая разработка сравнивает и контрастирует с текущим подходом организации.
Источник: learn.microsoft.com