Содержание |
Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе иногда называемом bullpen. Как минимум она включает и «заказчиков» (заказчики которые определяют продукт, также это могут быть менеджеры продукта, бизнес-аналитики или клиенты). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами.
Внедрение в России
2021: Анализ разных сфер экономики на предмет применения Agile
Компания Перфоманс Лаб анализировала разные сферы экономики на предмет популярности и понимания компаниями методик Agile и сделала прогнозы на 2021 год относительно внедрения и успешности этого подхода на российском рынке. Результаты анализа компания сообщила 9 марта 2021 года.
В банках гибкие методологии разработки (Agile) использует большинство (91%) опрошенных банковских организаций. Хотя по опросам некоторые банковские организаций еще не готовы использовать Agile по полной. Например, Илья Кучугин, директор блока информационных технологий банка "Зенит" согласен, что Agile-технологии все активнее проникают в банковскую деятельность. По его словам, со стороны может показаться, что речь идет исключительно о техническом моменте, но на практике эта тенденция влечет за собой коренные изменения на всем ИТ-рынке. С внедрением гибких методологий будут скорректированы подходы к набору и управлению персоналом, придется переосмыслить роль менеджмента.
 | Так, в какой-то момент я осознал, что если мы в банке сможем выстроить работу по принципам Agile, то моя должность перестанет быть необходимой. И это вызов каждому руководителю: какие шаги необходимо предпринять, чтобы остаться востребованным в новых условиях?, - поделился Илья Кучугин. |  |
Из исследования RQR 2020-2021 (Russia Quality Report) Перфоманс Лаб, в котором было опрошено более 350 организаций из телекома, ИТ, финансовой сферы, ритейла, ТЭК, промышленности о ситуации на рынке обеспечения качества ИТ-систем и тестирования рынка ПО в России следует, что гибкие методологии разработки (Agile) популярны не во всех областях экономики, кто-то не знает, что с ними делать, обладаем небольшим опытом или просто пока не готов к использованию. Несмотря на это, гибкие методологии разработки (Agile) продолжают завоевывать симпатии российских компаний и организаций. По данным прошлых отчетов компании, еще четыре года назад такой подход применяли всего 43% опрошенных игроков рынка. В 2020 году их количество увеличилось до 80%.Облачные сервисы для бизнеса: особенности рынка и крупнейшие поставщики. Обзор TAdviser 
Рост популярности Agile в России, впрочем, не означает, что отечественные компании перестали сталкиваться с проблемами при внедрении гибких методологий разработки на практике. Agile не стал для отечественных компаний панацеей: при внедрении гибких методологий организации все еще не застрахованы от проблем.
В ритейле популярность Agile продолжает расти в России. Опрос торговых компаний показал, что большая их часть (60%) использует этот подход. За 2019-2020 года данный показатель вырос на 7%.
Организации, которые работают на рынках ритейла и электронной коммерции, назвали недостаток понимания подходов к тестированию по методологии Agile основной проблемой в 2020 году. Об этом говорили 57% респондентов.
Гибкие методологии разработки (Agile) применяют только 25% опрошенных организаций государственного сектора. Выбор в пользу этого подхода респонденты объясняют повышением прозрачности, управляемости и быстроты разработки продукта.
Основными сложностями при использовании Agile для респондентов являются: недостаток тестовых сред и данных, а также отсутствие опыта тестирования в команде (по 33%). Еще 67% участников опроса не могут назвать актуальные для них проблемы применения Agile, так как не используют эту методологию.
На рынке системной интеграции около 90% системных интеграторов, принявших участие в опросе, применяет Agile.
В телекоме большинство опрошенных телекоммуникационных компаний (80%) применяют гибкие методологии разработки (Agile).
2017: Компании быстро осваивают Agile — исследование
В конце октября 2017 года компания ScrumTrek (Скрамтрек), специализирующаяся на внедрении agile-подходов, опубликовала результаты исследования, показавшие быстрое внедрение Agile в России. При этом технология выходит за пределы ИТ.
В ScrumTrek опросили почти 800 представителей малого, среднего и крупного бизнеса в 50 городах. 61% респондентов — это менеджеры проектов, миддл-менеджеры, скрам-мастера и другие руководители; 21 % от этого сегмента — топ-менеджеры и владельцы предприятий.
Согласно опросу, 40% респондентов, начавших применять Agile не более 1,5 лет назад, уже внедрили гибкие методологии во всей или почти во всей компании. Лишь 20% организаций, применяющих Agile 2-3 года, продолжают пилотные проекты на уровне отдельных команд, но многие успели пойти дальше локальных экспериментов.
Около 50% компаний начали использовать Agile примерно назад. Около 41% организаций познакомились с гибкими методологиями около полутора лет назад.
Чаще всего российский бизнес внедряет Agile для ускорения поставок и вывода продуктов на рынок. Добиться этой цели благодаря использованию гибких методологий на момент составления исследования удалось менее чем половине респондентов (мировой показатель — 81%), говорится в докладе ScrumTrek.
Больше двух третей участников опроса (68%), работающих в компаниях с опытом внедрения Agile, либо представляют ИТ-бизнес, либо активно вовлечены в процесс разработки программного обеспечения. Вместе с тем доля респондентов, никак не связанных с информационными технологиями, достаточно велики и составляет 32%.
Почти половина этих опрошенных (40%) работают в страховых и финансовых компаниях, в том числе в банках, которые часто называют главным драйвером применения agile-подходов в последние несколько лет.
SAFe - Scaled Agile Framework
SAFe (ScaledAgile Framework) – база знаний проверенных, интегрированных принципов, практик и компетенций для Lean,Agile, DevOps в масштабе
.jpg)
Преимущества SAFe
- Спроектирован для крупных Enterprise-организаций
- Основан на реальном опыте мировых компаний
- Базируется на близких нам принципах
- Включает в себя выравнивание на всех уровнях от стратегии, сохраняя гибкость организации
- Есть практический опыт в России
- Уделяет внимание техническому долгу, архитектуре и DevOps
4 базовые концепции Agile
Agile, гибкая методология разработки ПО, предоставляет ряд преимуществ перед более консервативной и менее подходящей для производителей софтов системы Waterfall, однако некоторые организации не спешат с переходом. IТ-эксперт Боб Ронан (Bob Ronan) в своей статье перечисляет преимущества, которые следует учесть директорам по информационным технологиям (CIO), рассматривающим возможность перехода на Agile[1].
1. Технические и бизнес-подразделения совместно располагаются в открытой зоне
Первые agile-последователи начинали с ключевых сотрудников (менеджер проектов, системные и бизнес-аналитики, разработчики, тестировщики), но со временем процесс охватил всех работников. Например, с технологической стороны сегодня широко распространена практика объединения инженеров по анализу и обработке данных, администраторов баз данных и персонала по технологическим операциям в одном подразделении, даже если они находятся там всего лишь временно.
2. Сценарии тестирования разрабатываются до начала этапа программирования
В случае разработки на основе тестов разработчикам предоставляется возможность сразу проверить работоспособность своего кода. Несмотря на тот факт, что в реальности многие команды пытаются реализовать этот шаг до начала этапа программирования, самое важное – это составление сценариев тестирования, особенно сценариев модульного тестирования, которые часто не используются вообще в каскадной модели.
3. Утренние планерки проводятся каждый день
В ходе таких планерок команда собирается в круг и каждый участник рассказывает о том, что он сделал вчера, что планирует сделать сегодня, и с какими проблемами он столкнулся. Все вопросы, требующие больше времени, чем краткое обсуждение, документируются и рассматриваются позже. При этом, очень важно чтобы все стояли, так как это подчеркивает необходимость быть кратким.
4. Процесс состоит из рабочих циклов продолжительностью от одной до четырех недель, которые называют «спринтами»
На выходе каждого цикла получается рабочий код. Исходя из опыта, можно сказать, что двухнедельные спринты обеспечивают сбалансированную возможность создать что-то действительно ценное при сохранении чувства срочности. Каждый цикл включает в себя:
- «Игровое планирование», позволяющее решить, какие функции будут встроены в текущую версию, исходя из приоритетного списка предварительно собранных «пожеланий пользователей». Пожелания пользователей, представляют собой высокоуровневые описания бизнес-задач, которые должно решать приложение. Изначально они разрабатываются во время рабочего совещания, на котором присутствуют все сотрудники технических и бизнес-подразделений, а затем постепенно обновляются, чтобы гарантировать, что позиции с наибольшей коммерческой ценностью находятся в верху списка.
- Разработку макетов экранов и тестовых сценариев.
- Написание кода и тестирование взаимодействия компонентов системы. Следует отметить тот факт, что часто код приводится к общему основанию, позволяя всем работать с одной и той же версией, что позволяет быстро обнаруживать проблемы интеграции.
- Демонстрацию рабочего кода рабочей группе и руководству технического или бизнес-подразделения.
- Ретроспективное обсуждение того, что в рамках цикла прошло хорошо, а что следует изменить в будущем. Наилучшая практика заключается в разработке пожеланий пользователей для учета всех возможностей, обозначенных в ходе ретроспективного обзора, и их проработки в рамках следующего цикла, так как это подкрепляет концепцию непрерывного совершенствования.
Распределенная гибкая модель
Большинство организаций не могут позволить себе роскошь собрать всех разработчиков в одном физическом месте, поэтому сомневаются, подойдет ли им agile-модель. Она подойдет, но это потребует инвестиций в технологии и командировки.
«Когда я впервые опробовал Agile при которой разработчики находились в разных местах, результаты были не очень радужными. Планерки проводились по телефону, и мы часто испытывали трудности с пониманием того, что говорится в другой локации. Наша первая попытка решить проблему была довольно забавной: мы передавали телефон по кругу говорящему. Это решение было не до конца оптимальным, но оно подтолкнуло нас к более удачной идее использовать гарнитуру, подключенную к единой телефонной системе. Благодаря этому все могли слышать друг друга.
Это было эффективно, но по-настоящему поворотным моментом стало внедрение видеотехнологий. Каждому участнику группы предоставлялось видеоустройство, установленное на рабочем столе, позволяя видеть других участников, работающих по-отдельности, или собравшихся все вместе. Для групп мы приобрели мобильные мониторы с функцией видеоконференции, которые могли перемещаться из одного места в другое, в зависимости от места сбора группы.
Большим шагом вперед стала установка в каждом подразделении разработки мониторов, которые никогда не выключались. Чтобы понять, как это работает, представьте себе комнату, в которой сидят разработчики, с установленным в дальнем конце монитором. Монитор показывает группу, работающую в другой локации, в которой также установлен свой монитор, отображающий ваше помещение для разработки. Люди подходят к монитору и разговаривают, как если бы они находились в одной комнате. Постоянно включенные мониторы обеспечивали более тесное взаимодействие, чем если бы группам приходилось постоянно вызывать друг друга.
Когда рабочие группы находятся в разных местах, очень важно построить личные отношения, а это требует инвестиций в поездки. Мы обнаружили, что когда несколько членов рабочей группы каждый год работают в другой локации в рамках одного из циклов, это приносит положительный результат. Это позволяет им построить личные отношения и, по возращению, такие отношения повышают продуктивность видео-конференций», – отмечает Боб.
10 преимуществ Agile
1. Быстрое выявление неправильных подходов
Есть много документальных подтверждений тому, что в сфере технологий, чем позже обнаруживается неверно выбранный путь, тем сложнее все исправить. Благодаря ежедневному отслеживанию рабочего прогресса, Agile позволяет быстро обнаружить ошибки.
2. Быстрое принятие решений
Большинство решений принимается партнерами, работающими в одном помещении. При возникновении каких-либо вопросов обычная практика подразумевает сбор работников в одном месте для их обсуждения. Очень редко возникает необходимость в проведении официальных собраний, согласование графика которых может занять несколько дней.
3. Сотрудничество выливается в множество преимуществ
Учитывая, что технические и бизнес-группы несут одинаковую ответственность, они одинаково заинтересованы в достижении успеха. Технические сотрудники понимают трудности, испытываемые бизнес-подразделениями с текущей средой, в то время как бизнес-сотрудники понимают технические трудности разработки нового приложения. При возникновении каких-либо проблем они становятся известны всем участникам группы, и очень часто решение находят люди, работающие над совершенно другими задачами.
4. Изменения признаются неизбежными и приветствуются
Понятно, что в самом начале проекта никто не может точно представить, как должна работать система. Многие каскадные проекты сталкиваются с «аналитическим параличом» из-за давления, связанного с необходимостью разработки технических требований, прежде чем можно приступить непосредственно к работе. При гибкой модели разработка системы осуществляется в процессе нескольких циклов и поправки вносятся на ходу.
5. Конечный продукт содержит наиболее полезные функции
Так как бизнес-сотрудники принимают непосредственное участие в развитии продукта, они эффективно определяют функции, которые повышают его ценность. Напротив, определение всех требований на начальных этапах проекта может привести к разработке бесполезных или ограниченно полезных функций.
6. Более привлекательная среда для поколения Y
Сегодня очень популярны разговоры о вовлечении поколения, родившегося в конце XX века. Agile подходит для этого идеально, так как молодым сотрудникам нравится располагающая к сотрудничеству динамичная рабочая обстановка.
7. Более высокое качество кода готового продукта
"Однажды я провел семилетний анализ наших количественных показателей. Оказалось, что проекты, основанные на гибкой модели разработки, отличались существенно меньшим количеством дефектов в производственной среде", – говорит Боб.
8. Бизнес-группа испытывает большее удовлетворение итоговыми результатами
Упомянутый выше семилетний анализ также показал, что в ходе изучения уровня удовлетворенности заказчиков проекты, основанные на гибкой модели разработки, набирали значительно больше баллов, чем каскадные проекты. Собственно, очень редко гибкие проекты набирали меньше пяти баллов по пятибалльной шкале.
9. Составление технической документации занимает меньше времени и содержит меньше ошибок
Учитывая, что документация ограничивается рабочими продуктами, необходимыми для выполнения поставленных задач (пожелания пользователей, тестовые сценарии и т.д.), то в ней отражается то, что было реализовано, а не то, что могло быть запланировано. Возможности отслеживания в процессе аудита гораздо шире, так как согласуются все дискретные функции, в противоположность однократному утверждению нескольких сотен страниц документации. При традиционных подходах к разработке тратится огромное количество времени на составление документации, которая часто не обновляется или не используется. При каскадной модели промежуточные этапы часто связаны с составлением документации, а не с фактически работающим кодом.
10. Более простое обслуживание приложения
Мы все слышали ужасные истории о единой точке отказа кода, когда лишь один человек знает код достаточно хорошо, чтобы вносить в него изменения. Такого никогда не случается в гибкой модели, потому что сразу несколько разработчиков работают над каждой частью системы.
Методологии
Философия Agile сформировала класс методологий управления проектами, который включает в себя:
Направления использования
Agile в управлении госпроектами
Основная статья: Agile в управлении государственными проектами
Если Agile настолько хорош, почему он используется не всеми организациями?
«Во-первых, многие ИТ-руководители не любят рисковать, а изменение процесса разработки связано с резкими переменами. Во-вторых, гибкая модель иногда не срабатывает, после чего от нее отказываются. В основе этих двух причин лежит риск неудачи, но его можно снизить, если избежать двух типичных ошибок применения гибкой модели. По опыту могу сказать, что Agile не срабатывает, когда инициатива по ее внедрению спускается сверху – проектным группам говорят, что теперь они будут использовать гибкую модель разработки и говорят, как именно им с ней работать. Строгая методология противоречит самой сущности Agile. Весь ее смысл заключается в том, чтобы попробовать как можно больше идей и использовать те, которые будут работать.
Чтобы agile-метод заработал, необходимо найти группу, которая не против ее опробовать, и затем предоставить им полную свободу в выборе методов, подходящих для этой конкретной организации. Вы получите результат, проектная группа станет приверженцем метода, и вскоре к вам будут приходить руководители других групп и спрашивать, почему Agile не работает в их проектах», – подчеркивает эксперт.
Agile в банках
Опыт применения
Основное отличие методологии Agile от прошлых методов разработки состоит в понимании того, что в ходе проекта все может изменяться. Поэтому важно и нужно учитывать эти изменения, чтобы результат проекта наиболее полно удовлетворял его бизнес-цели и выполнял поставленные задачи. О самых популярных гибких методологиях разработки и опыте их применения в рубрике TADетали рассказали эксперты ГКС (АО «Группа Систематика»). См. Суперсеты, эстафеты и гонки на скоростных спорткарах – спортивный agile подход к процессу выполнения проекта
Смотрите также
- DevOps Методология
- DevSecOps
- Agile в управлении государственными проектами
- Value Stream Management (VSM, управление потоком создания ценности)
- Scrum
- Канбан (Kanban)
- Lean
- Суперсеты, эстафеты и гонки на скоростных спорткарах – спортивный agile подход к процессу выполнения проекта
