Технология эджайл: методология, метод или философия? — статья в блоге ScrumTrek

Методология Agile: что это, отличия гибкой методологии

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

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

Что такое Agile

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

Термин Agile употребляют в двух разных смыслах:

● Философия и система ценностей, которой придерживается команда.

Тут речь не о конкретных инструментах и практиках, а скорее о принципах, по которым строится работа.

● Собирательное название нескольких разных гибких методологий, для которых общими являются ценности Agile.

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

Подход Agile возник после того, как в сфере IT устали от излишней бюрократии и строгости. Разработчики поняли, что создавать инновационные продукты по старым строгим методологиям просто нельзя, поэтому в 2001 году в американском штате Юта 17 разработчиков со всего света собрались и подписали манифест о новых передовых принципах разработки, которые и легли в основу Agile.

Манифест и принципы Agile

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

1. Удовлетворение клиентов — приоритетная задача при разработке продукта. Клиенты должны своевременно и в полном объёме получать качественное программное обеспечение и его обновления.
2. Изменения в процессе разработки приветствуются. Гибкие процессы позволяют наделить продукт конкурентными преимуществами для клиентов.
3. Рабочее ПО нужно доставлять клиенту часто, в рамках 2–16 недель.
4. Руководители и разработчики должны трудиться вместе на протяжении всего рабочего процесса.
5. В основе проекта — мотивированные люди. Обеспечьте им необходимые условия работы, поддержку и доверие.
6. Лучший способ передачи информации в команде — личная беседа.
7. Основное мерило прогресса — работающее ПО. А не часы, трудозатраты и другие критерии.
8. Гибкие процессы — основа устойчивого развития. Они позволяют поддерживать нужный рабочий темп как на спринтерской, так и на марафонской дистанции.
9. Важно уделять внимание техническому совершенству и качественному дизайну продукта.
10. Важно сокращать до минимума лишнюю работу и не переусложнять проект и рабочие процессы.
11. Самые лучшие продукты рождаются у самоорганизующихся команд. Нет микроменеджменту, да — свободе управления.
12. Команда должна регулярно оценивать работу и корректировать своё поведение.

Из этих двенадцати принципов выделяют четыре ценности системы Agile:

● Люди и взаимодействия важнее процессов и инструментов.

● Работающий продукт важнее точной и подробной документации.

● Сотрудничество с заказчиком важнее условий договора.

● Готовность к изменениям важнее следования изначальному плану.

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

Материал по теме:

Проджект-менеджер: всё, что нужно знать о профессии и о том, как её получить

Отличия Agile от других методологий

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

Но если говорить не об основных инструментах, а именно об основополагающих принципах, у Agile есть несколько отличий от классических строгих методологий вроде Waterfall:

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

● На аналитику и планирование нужно тратить меньше времени, поскольку позже их потребуется проводить снова. Лучше уделить больше внимания техническому совершенству продукта.

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

● Новые требования к продукту обязательно должны быть учтены и добавлены в следующих рабочих циклах.

● Сроки проекта должны быть гибкими, с запасом на задержки и изменения.

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

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

Преимущества и недостатки Agile

Плюсы:

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

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

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

● Большая вовлечённость команды. Отсутствие микроменеджмента, тесная работа с руководством и самоуправление помогают разработчикам работать эффективнее и видеть своё влияние на проект.

● Высокая скорость реакции на проблемы. Если появится баг — его можно быстро устранить в новом цикле. Не нужно полностью перекраивать проект, сдвигать сроки или откладывать исправление ошибки на потом.

● Минимум рутины. Разработчики тратят меньше времени на документацию и отчёты — то, что они обычно не любят больше всего.

Минусы:

● У проекта нет чёткого плана и структуры. В конце может получиться совсем не то, что в начале. Это минус скорее для заказчиков, которым важна определённость и чёткое следование определённым требованиям. Например, для государственных компаний.

● Потребность в тесном общении. Заказчику нужно постоянно общаться с командой, обновлять требования, смотреть промежуточные результаты.

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

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

● Сложности с внедрением. Если в компании работали по другой методологии, построить Agile может быть сложно. Потребуется отдельный сотрудник либо менеджер проекта, который хорошо разбирается в гибких методологиях. И переход может занять много времени.

Где используют гибкие методологии

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

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

Если говорить о сферах бизнеса, то изначально Agile создавали именно для применения в командах разработки ПО, игр и интерфейсов. Сейчас его используют Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe и большинство других IT-компаний, как гигантов индустрии, так и совсем мелких стартапов.

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

Гибкие методологии Agile — стандарт для большинства современных проектов. На курсе Яндекс Практикума «Менеджер проектов» мы знакомим студентов с популярными вариациями этой методологии, разбираем основные инструменты и учим вести проект от старта до завершения.

Записаться на бесплатную часть можно уже сейчас.

Зарабатывайте, управляя проектами

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

Методы, средства и технологии управления проектами по Agile

В семейство Agile входит несколько разных гибких методологий управления проектами, которые ещё называют методами управления. В России наибольшей популярностью пользуются две — Scrum и Kanban.

Сначала владелец продукта, обычно заказчик, формирует набор требований к продукту. Он передаёт его разработчикам. Те делят работу на этапы — спринты, обычно длиной от одной до четырёх недель. За один спринт команда выполняет конкретный пласт работ, который приводит к результату — цели спринта. Работы берутся из бэклога проекта — списка этапов, которые необходимо выполнить. На его основе составляют бэклог спринта.

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

Выполнять задачи и не отклоняться от цели помогают события: ежедневные синки, приоритизация, работа с бэклогом, планирование. За всем этим следит scrum-мастер — он помогает команде договариваться и планировать. Подробно все это описано в Scrum-гайде — главном документе методологии.

Примерная схема ведения проекта по Scrum

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

В отличие от многих других гибких методологий семейства Agile, Scrum дружит с квартальным планированием и отчётами. Он позволяет обещать бизнесу конкретные результаты в чёткие сроки.

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

«В одном из стартапов, где я работала, мы использовали Scrum. Это была работа над внутренним продуктом — мы собрали команду с необходимой экспертностью и не зависели от внешних факторов. Для себя мы поставили ограничение — делать релиз в конце спринта, раз в три недели. В Scrum требований к обязательному релизу в конце спринта нет, но мы решили его добавить. В итоге знание того, что, если не успеем за три недели, релиз придется откладывать, помогало — мы тщательно декомпозировали и приоритизировали, а в момент релиза все вместе накидывались на проверку задач. Так у нас получился Scrum четко по Scrum-гайду. ».

Валерия Данильченко, наставник Яндекс Практикума на курсе «Менеджер проектов»

Kanban

Многие компании сейчас используют инструмент этой методологии — Kanban-доску, например Trello. Но на самом деле сама методология гораздо шире. Работа над проектом в ней состоит из шести принципов:

1. Визуализируйте все задачи на специальной Kanban-доске. Если появляется новая задача — сразу добавляйте на доску.
2. Ограничьте количество работы в процессе — в каждом столбике доски должно быть не больше определённого количества задач.
3. Управляйте потоком работы — отслеживайте, как задачи движутся по доске.
4. Используйте только явные правила добавления и движения задач, понятные всем участникам.
5. Вводите петли обратной связи — наборы встреч, помогающие лучше понимать процесс работы.
6. Улучшайте процессы везде, где это возможно.

Пример Kanban-доски

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

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

Недостаток Kanban в том, что он плохо согласуется с квартальным планированием. Задачи в нём выполняются единым потоком, и сложно назначить конкретные сроки и предоставлять чёткие результаты и отчёты. Требуются отдельные усилия менеджера команды.

В Яндекс Практикуме мы внедряли Kanban в сервисной команде, где как раз была очередь задач:

1. Визуализация прошла как по маслу. Задачи получилось чётко определить, и после визуализации команда сама увидел все узкие горлышки и была готова над ними работать.
2. Ограничить объём работы в процессе было сложнее, но с этим мы справились. Помогло то, что это была команда дизайна, — любой участник мог подхватить задачу в любом статусе.
3. А вот управлять потоком и приоритетами не получилось. Заказчики привыкли жить двухнедельными спринтами, и каждый хотел получить задачу срочно. Мы не могли понять, когда приносить задачу, чтобы всё точно успеть. Каждый заказчик повышал приоритет своих запросов, и всё разваливалось.

В итоге пришлось вернуться к чему-то похожему на Scrum. Остались двухнедельные спринты, но отдельные задачи кочевали из спринта в спринт. И заказчиков это устраивало — в итоге создавалось впечатление, что задача выполняется, и не кажется, что её приоритет понижен.

Можно было сделать иначе — изнутри поставить процесс по Kanban, а наружу транслировать двухнедельные циклы. Потому что, не считая проблем с коммуникацией наружу, внутри команде было комфортно работать именно по Kanban. У такого подхода даже есть отдельное название — Scrumban. Нахождение таких компромиссов и наилучшее применение инструментов из разных методологий — как раз задача менеджера проекта.

Статью подготовили:

Поделиться 

Читайте также:

Методологии управления проектами: топ современных подходов и методов управления проектами

Перейти в статью

Управление проектами: что такое проектный менеджмент, его задачи, этапы — как управлять проектом

Перейти в статью

Учитесь на майских и получайте скидку 7%. Пройдите первый бесплатный урок с 1 по 14 мая и получите промокод на скидку.

Что такое Agile и подойдет ли он вашей компании

Тренды

Телеканал

Pro

Инвестиции

Мероприятия

РБК+

Новая экономика

Тренды

Недвижимость

Спорт

Стиль

Национальные проекты

Город

Крипто

Дискуссионный клуб

Исследования

Кредитные рейтинги

Франшизы

Газета

Спецпроекты СПб

Конференции СПб

Спецпроекты

Проверка контрагентов

РБК Библиотека

Подкасты

ESG-индекс

Политика

Экономика

Бизнес

Технологии и медиа

Финансы

РБК КомпанииРБК Life

РБК Тренды

Фото: Shutterstock

В 2021 году исполнилось 20 лет «Манифесту Agile». Подход зародился как бунт разработчиков против неповоротливых ИТ-корпораций. Разбираемся, что происходит с Agile сейчас и как его применяют в российских компаниях

1

Что такое Agile

Agile, или Agile software development — гибкий подход к разработке программного обеспечения (ПО), который часто применяют в небольших командах.

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

Термин Agile употребляют в двух основных значениях:

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

Как правило, agile-команды включают разработчиков, тестировщиков, менеджеров проектов, дизайнеров интерфейсов, технических (UX) писателей. Все они равноценны в иерархии и работают в одном офисе или коворкинге. За счет личного общения они экономят время на обсуждении текущих процессов. Сторону заказчика представляет менеджер или руководитель — product owner, от которого команда регулярно получает обратную связь.

Agile возник в противовес устаревшим подходам и излишней бюрократии в сфере ИТ. Резиденты Кремниевой долины (и не только) поняли, что невозможно создавать инновационные продукты в консервативной среде. Поэтому в феврале 2001 года в штате Юта (США) 17 разработчиков из разных стран мира создали свой манифест, в котором объединили самые передовые подходы и принципы.

2

«Манифест Agile» и основные принципы

Agile-манифест базируется на четырех главных ценностях:

1. Люди и их взаимодействие важнее процессов и инструментов.

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

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

2. Работающий продукт важнее документации и отчетности.

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

3. Сотрудничество с заказчиком важнее соблюдения формальных условий.

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

4. Готовность к изменениям важнее, чем следование плану.

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

Agile не исчерпывается четырьмя ценностями [1]. В манифесте есть также 12 принципов, которые уточняют и дополняют их. Их можно свести к следующему:

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

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

3

Что такое Scrum и Kanban

Scrum, или «подход структуры» — метод на основе Agile, при котором работа над проектами разбивается на спринты — короткие, одинаковые по времени итерации. Команда тоже небольшая — до десяти человек. В нее входят разработчики, product owner (владелец продукта) и scrum-мастер. Product owner — куратор группы, который следит за тем, чтобы конечный продукт отвечал его целям и задачам. Scrum-мастер — человек, который отвечает за правильное применение scrum-метода: организует встречи и обмен сообщениями между всеми участниками. В процессе работы все участники ежедневно обсуждают каждое решение, планы и приоритеты, а также распределяют задачи.

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

В отличие от scrum, kanban:

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

В kanban принято визуализировать все детали процесса. Обычно это доска со стикерами, надписями или task-менеджер вроде Trello, где указаны все задачи, этапы и их статус. Часто задачи помечают разными цветами, чтобы обозначить, к какому этапу они относятся или на какой стадии исполнения находятся. Это помогает каждому участнику проекта видеть всю картину целиком, вовремя замечая, если что-то провисает или кому-то нужна помощь.

Пример доски Trello, созданной по принципам agile.

Если вы только подступаетесь к философии Agile и хотите попробовать отдельные элементы, проще начать с kanban. Небольшим стартапам и командам, которые только планируют запуск проекта, подойдет scrum.

4

В каких компаниях используют Agile

Когда Agile только появился, его использовали, в основном, разработчики ПО, игр и интерфейсов. Среди них — Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis.

Теперь же сфера применения расширилась: Agile используют, например, Saab для производства новых истребителей, General Electric и John Deere — ведущий американский производитель сельхозтехники.

5

Существует ли Agile в России

В Россию Agile пришел на несколько лет позже, но уже сегодня его активно используют в ИТ-секторе, ретейле, банках, онлайн-сервисах, промышленных предприятиях. Среди них — ПО-разработчик First Line Software, гипермаркет электроники «М.Видео», служба доставки Dostаевский, онлайн-кинотеатр ivi, бренд одежды 12 Storeez, металлургический концерн НМЛК.

ScrumTrek проводит ежегодное исследование Agile в России. В прошлом году в нем приняло участие более 1 тыс. компаний из 80 городов. Вот главные цифры за 2020 год [3]:

1. География: 41% Agile-команд, участвующих в исследовании, находятся в Москве, 14% — в Санкт-Петербурге, 6,4% — в Перми, 5,5% — в Казани и Иннополисе (ИТ-кластер), 5,4% — в Новосибирске.
2. Отрасли: ИТ — 42% участников, финансы — 18%, промышленность — 8%, ритейл — 7%, телеком — 4,8%, энергетика — 3,2%, консалтинг — 2,8%.
3. 33% применяют гибкие подходы во внутренних проектах и услугах для клиентов.
4. 41% используют scrum (на 7% меньше, чем год назад и на 9% — по сравнению с 2018 годом), 23% — kanban (на 8% больше, чем в 2019 году и на 13% — по сравнению с 2018-м): то есть, kanban постепенно догоняет scrum по популярности. При этом в мире доля kanban в три раза ниже, чем в России: за год она выросла с 5% до 7%; доля scrum при этом выросла с 54 до 58%.
5. 60% компаний применяют несколько подходов одновременно. Доля собственных или комбинированных agile-методик в компаниях составляет 30%.
6. 22% компаний оценили свой уровень компетенции в Agile как высокий — это на 9% больше, чем годом ранее. Если год-два назад многие только планировали применять гибкие методики, то сейчас уверенно внедряют их, комбинируя разные методы и даже изобретая свои. Однако три года — период, в который проводятся исследования — все еще слишком малый срок, чтобы говорить о зрелости в плане agile-подходов.

6

Нужен ли вашей команде Agile

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

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

Другими словами, Agile идеален для инновационных стартапов, но мало подходит корпорациям с отлаженными процессами и сложной структурой. Для таких компаний лучше работают методы с отдельными элементами Agile, которые проще масштабировать — SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).

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

Чтобы протестировать новую идею, не проходя все этапы разработки, подойдут Customer Development, Design Thinking и другие продуктовые методики.

Наконец, есть более широкий подход, который включает в себя agile-методики — Business Agility («гибкость в бизнесе»). Он распространился позже — два-три года назад — и включает не только ускорение разработки и выпуска продукта, но и быструю реакцию на внешние изменения, гибкое целеполагание и распределение ресурсов.

7

Книги про Agile

• «Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban». Авторы: Роб Коул, Эдвард Скотчер. Для тех, кто только планирует перейти от классического проектного менеджмента к гибкому.
• «Эпоха Agile. Как умные компании меняются и достигают результатов». Автор: Стивен Деннинг. Описывает работу гибких методов управления на разных уровнях, как правильно ставить цели и как их достигать.
• «Scrum. Революционный метод управления проектами». Автор: Джефф Сазерленд, основатель фреймворка scrum. Необходима скрам-мастерам и тем, кто хочет применять этот метод и понять, в чем его польза и преимущества.
• «Scrum и Kanban: выжимаем максимум». Авторы: Хенрик Книберг, Маттиас Скарин. Сравнение двух методов с практическими примерами, плюсами и минусами.
• «Канбан и «точно вовремя» на Toyota. Менеджмент начинается на рабочем месте». Сборник статей от специалистов Toyota, посвященных внедрению kanban в компании, синтезе американского и японского подходов и как это повлияло на внутренние процессы.
• «Agile: Оценка и планирование проектов». Автор — Майк Кон. Оценка и планирование критически важны для успеха любого проекта. Однако процесс планирования сложен, и наши планы часто оказываются далекими от реальности. Майк Кон, гуру в области Agile, дает инструменты, необходимые для оценки, планирования и управления agile-проектами любого масштаба.

Обновлено 23.03.2022

Текст

Ася Зуйкова

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

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

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

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

Узнайте больше о Agile на opensource.com

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

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

Авторы разъясняют, что все пункты в приведенном выше списке имеют некоторую неотъемлемую ценность. Однако они предполагают, что оценка элементов слева (выделены жирным шрифтом) выше элементов справа может привести к лучшим результатам в разработке продукта. Agile-манифест не претендует на то, чтобы предписывать набор практик; это руководство для нового образа мышления о разработке программного обеспечения.

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

Agile-подходы к работе были созданы для устранения предполагаемых ограничений методологии водопада, которая была получена из производственного метода сборочной линии Генри Форда 1913 года и позже применена к разработке программного обеспечения. С момента своего основания в 2001 году гибкая разработка процветала в индустрии программного обеспечения и управлении проектами, хотя и имеет множество вариаций.

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

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

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

DevOps как концепция разрушает старую стену между разработкой программного обеспечения и эксплуатацией. SRE — это реализация DevOps, в которой программное обеспечение используется как инструмент для управления системами и автоматизации операционных задач. Методы CI/CD признают, что программное обеспечение будет постоянно меняться, и предоставляют разработчикам инструменты для ускорения развертывания нового кода.

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

Agile-фреймворки для разработки программного обеспечения, такие как Scrum, kanban или экстремальное программирование (XP), формируют основу для популярных процессов разработки программного обеспечения, таких как DevOps и непрерывная интеграция/непрерывное развертывание (CI/CD).

Scrum, пожалуй, самая популярная гибкая структура, используемая сегодня, но не все agile — это Scrum, и, честно говоря, не весь Scrum agile. Scrum — это фреймворк для управления работой, предназначенный для небольших межфункциональных команд из 5–9 человек, которые разбивают свою работу на действия, которые могут быть выполнены в течение определенного периода времени, называемого спринтом. Scrum-команды состоят из членов команды, Scrum-мастера и владельца продукта. Как правило, Scrum применяется, когда большой проект можно разбить на 2–4-недельные спринты. Scrum фокусируется на петлях обратной связи посредством церемонии, называемой «ретроспективой». Неофициальным девизом Scrum может быть «проверка и адаптация».

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

Узнайте, как гибкие фреймворки могут способствовать инновациям, с Red Hat Open Innovation Labs

Если вы хотите в полной мере воспользоваться преимуществами гибкости и оперативности DevOps, ИТ-безопасность должна играть роль на протяжении всего жизненного цикла ваших приложений.

CI/CD обеспечивает постоянную автоматизацию и непрерывный мониторинг на протяжении всего жизненного цикла приложений, от этапов интеграции и тестирования до доставки и развертывания.

Инженер DevOps обладает уникальным сочетанием навыков и опыта, которое обеспечивает совместную работу, инновации и культурные сдвиги внутри организации.

Продукты

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

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

Связанные статьи

• Понимание DevOps

• Облачная CI/CD в Red Hat OpenShift

• Что такое автоматизация развертывания?

• Что такое автоматизация DevOps?

• Кто такой инженер DevOps?

• Что такое конвейер CI/CD​?
• Что такое гибкая методология?

• Что такое управление жизненным циклом приложений (ALM)?
• Что такое сине-зеленое развертывание?
• Что такое CI/CD?
• Что такое непрерывная доставка?
• Что такое DevSecOps?
• Что такое GitOps?
• Что такое SRE (проектирование надежности сайта)?

Ресурсы

Герои командной строки, сезон 1, эпизод 4:

«DevOps: разрушьте эту стену»

Автоматизация предприятия с помощью методологии DevOps

Оптимизация конвейеров CI/CD с помощью Red Hat Ansible Automation Platform

Управление инфраструктурой и конфигурациями приложений с помощью Red Hat® OpenShift® GitOps 

КОНТРОЛЬНЫЙ СПИСОК

5 способов, которыми инженеры по обеспечению надежности могут помочь вам

КОНТРОЛЬНЫЙ СПИСОК

6 преимуществ безопасности сред облачных вычислений

АНАЛИТИЧЕСКИЙ МАТЕРИАЛ

451 Отчет Research Pathfinder: Достижение Intelligent DevOps 9 0003

АНАЛИТИЧЕСКИЙ МАТЕРИАЛ

Управление автоматизацией DevOps

Что такое гибкая методология? Инструменты, лучшие практики и многое другое

Что такое Agile-методология? Как это работает, рекомендации, инструменты

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

 | 5 марта 2023 г.

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

Как это работает

Это работает, если сначала признать, что старый «водопадный» метод разработки программного обеспечения оставляет желать лучшего. Процесс «планируй, проектируй, строй, тестируй, доставляй» подходит для создания автомобилей или зданий, но не для создания программных систем. В бизнес-среде, где оборудование, спрос и конкуренция являются быстро меняющимися переменными, agile работает, балансируя на тонкой грани между слишком большим количеством процессов и недостаточным объемом .

Обзор Agile-методологии

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

• Быстрее, меньше. Традиционная разработка программного обеспечения основывалась на таких этапах, как определение требований, планирование, проектирование, сборка, тестирование и поставка. Гибкая методология, напротив, предполагает развертывание первого инкремента за пару недель, а всей части программного обеспечения — за пару месяцев.
• Связь . Agile-команды внутри бизнеса ежедневно работают вместе на каждом этапе проекта посредством личных встреч. Это сотрудничество и общение гарантируют, что процесс не изменится даже при изменении условий.
• Обратная связь . Вместо того, чтобы ждать этапа поставки, чтобы оценить успех, команды, использующие методологию Agile, регулярно отслеживают успех и скорость процесса разработки. Скорость измеряется после подачи каждого приращения.
• Траст . Agile-команды и сотрудники самоорганизуются. Вместо того, чтобы следовать манифесту правил от руководства , предназначенного для получения желаемого результата, они понимают цели и прокладывают собственный путь для их достижения.
• Настройка . Участники постоянно настраивают и корректируют процесс, следуя принципу KIS или Keep It Simple .

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

3 C Agile

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

Карточка

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

Беседа

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

Подтверждение

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

Примеры Agile-методологии

Наиболее популярными и распространенными примерами являются Scrum, экстремальное программирование (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Crystal и Lean Software. Развитие (ЗСД). Команды обычно выбирают один или два метода. Наиболее широко используемыми методологиями являются Scrum и XP, которые хорошо сочетаются друг с другом.

Scrum — это практическая система, состоящая из простых взаимосвязанных шагов и компонентов:

• Владелец продукта составляет список приоритетных пожеланий, известный как бэклог продукта.
• Скрам-команда берет один маленький кусочек из верхней части списка пожеланий, называемый невыполненной задачей спринта , и планирует реализовать его.
• Команда завершает свою невыполненную задачу спринта в спринте (период 2–4 недели). Они оценивают прогресс на собрании, называемом ежедневным схваткой .
• ScrumMaster позволяет команде сосредоточиться на цели.
• По окончании спринта работа готова к отправке или показу. Команда закрывает спринт обзором, затем начинает новый спринт.

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

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

Вот пример того, как работает XP: Билл составляет список требований клиентов, заставляя клиентов рассказывать «пользовательские истории», в которых описываются функции. Из них он строит план выпуска программного обеспечения. Программное обеспечение будет доставляться итерациями, по одной доставке каждые пару недель. Команда работает в парах программистов, используя ежедневные встречи для устранения препятствий. Клиент предоставляет обратную связь в виде большего количества пользовательских историй. Цикл повторяется до тех пор, пока программное обеспечение не будет доставлено.

Дополнительные примеры см. в этой статье.

[adinserter block=”33″]

Преимущества методологии Agile

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

• Быстрее . Скорость — одно из самых больших преимуществ Agile-методологии. Более быстрый жизненный цикл разработки программного обеспечения означает меньше времени между оплатой и получением оплаты. Что, в свою очередь, означает более прибыльный бизнес.
• Повышение удовлетворенности клиентов . С Agile клиенты не ждут месяцами или годами только для того, чтобы получить именно то, чего они не хотели. Вместо этого они очень быстро получают итерации чего-то очень близкого к тому, что им нужно. Система быстро адаптируется для улучшения успешного решения клиента, адаптируясь к изменениям в общей среде.
• Ценности сотрудников . Сотрудники, чьи идеи ценятся, гораздо более продуктивны, чем те, которым предписано следовать набору правил. Методология Agile уважает сотрудников, ставя перед ними цель, а затем доверяя им ее достижение. Поскольку именно они держат в руках элементы управления и видят препятствия, возникающие каждый день, сотрудники находятся в лучшем положении, чтобы реагировать на вызовы и достигать поставленных целей.
• Исключает доработку. Благодаря привлечению заказчика не только к этапам требований и поставки, проект остается в рамках задачи и соответствует потребностям заказчика на каждом этапе. Это означает меньшее количество возвратов и меньшее время ожидания между моментом, когда мы выполняем работу, и моментом, когда заказчик предлагает исправления.

Лучшие практики

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

• Установить приоритеты . Бэклог продукта — это список приоритетных задач, который ведет владелец продукта .
• Поддержка небольших циклов выпуска. Продукт должен выпускаться постепенно каждые 2–4 недели, при этом заинтересованные стороны должны оставлять отзывы перед тем, как продолжить.
• Использовать парное программирование. Два программиста работают бок о бок за одним компьютером. Этот метод на самом деле приводит к той же степени производительности, что и раздельное программирование, но обеспечивает более высокое качество.
• Рефакторинг. Регулярно перерабатывайте код для достижения того же результата с большей эффективностью и ясностью.
• Используйте разработку через тестирование. Сначала напишите модульный тест, чтобы поддерживать проект в рабочем состоянии. Разработка через тестирование как передовая практика Agile также повышает вовлеченность сотрудников, поскольку превращает тестирование из скучной рутинной работы в задачу кодирования.

Инструменты методологии Agile

В приведенном ниже списке перечислены некоторые из лучших предлагаемых инструментов. Полный список смотрите в этом посте.

• ActiveCollab . Доступный по цене инструмент для малого бизнеса, ActiveCollab прост в использовании. Это средство разработки программного обеспечения требует небольшого обучения и обеспечивает отличную поддержку.
• Агило для Скрама . Заинтересованные стороны автоматически получают информацию о ходе проекта с помощью Agilo for Scrum. Включает отчеты о спринтах и ​​диаграммы выгорания для лучшего анализа данных.
• Atlassian Jira + Agile . Этот мощный инструмент управления проектами упрощает разработку за счет включения Scrum, Kanban и настраиваемых рабочих процессов.
• Основной трекер . Этот инструмент методологии предназначен специально для мобильных проектов. Немного жаргонный, он удобен для пользователя после краткого ознакомительного периода.
• Префикс. Этот бесплатный инструмент от Stackify обеспечивает мгновенную обратную связь для обнаружения и исправления ошибок до их развертывания.
• Возврат . Чтобы получить более надежное решение с мониторингом, ошибками, журналами и т. д., Stackify Retrace предоставляет информацию о производительности приложений от интеграции до контроля качества и производства на уровне кода.

Дополнительные ресурсы

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

• Agile-манифест. Это оригинальный документ, положивший начало Agile-движению. Он содержит все 12 ключевых принципов методологии в целом.
• Диаграммы выгорания. Это визуальное представление оставшейся работы по сравнению с оставшимся временем. Загрузите шаблон Excel с сайта SmartSheet.com.
• Гибкий план проекта. Это инструмент для отслеживания хода всего Agile-проекта.

  No related posts.