Суть методологии agile сводится к тому что

Agile: что это такое и где используется, принципы и методология

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

Что такое Agile

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

Чем отличается от других методологий

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

OpenUP – преемница RUP. В этой методологии проект делится на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Методология недостаточно гибкая в сравнении с Agile, применима больше в IT-сфере.

Где используется Agile

Методика применялась в IT-индустрии и использовалась для разработки ПО. Суть сводилась к внедрению адаптивных методов, которые ускоряют создание продуктов через микропланирование и короткие производственные циклы. Однако впоследствии Agile стала использоваться и в других прикладных областях. Agile сейчас применяют компании: Netflix, Spotify, Magna International, General Electric, Accenture, М.Видео.

Подобные технологии стали достоянием команд, работающих над созданием клиентских продуктов.

Плюсы и минусы Agile

Манифест Agile

Идеи Agile

Ценности Agile говорят, что:

Гибкость методологии

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

Принципы методологии

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

Работа над мини-блоками

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

Маленькие кросс-функциональные команды

Сотрудники работают в небольших командах. Задача каждой в реализации одной из функций, которая важна для клиента. Численность и состав команд отличаются в зависимости от их задач. Число сотрудников в одной команде до 12 человек.

Ограничение объема незавершенной работы

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

Автономность команд

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

Достижение стадии готовности

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

Беспрерывная работа

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

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

Полная прозрачность и использование досок со стикерами

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

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

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

Ключевые моменты в применении

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

Какие существуют роли по Agile

Иерархия компетенции в Agile

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

Что такое пропускная способность

Пропускная способность – реализованное количество «пользовательских историй». Это пожелания клиентов, которые формируются в задачи. Например, установка фильтров поиска в приложении, улучшение обратной связи с клиентами, работа над службой техподдержки. Пропускная способность измеряется количеством отработанных пользовательских историй в неделю.

Как определить последовательность и приоритетность задач

Приоритетность задач зависит от направления компании. Например:

Как составить график решения задач

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

Внедрение Agile

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

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

Распространенные проблемы при реализации

Основные проблемы при внедрении Agile:

Популярные методы и средства управления проектами

Scrum

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

Kanban

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

Заключение

Источник

«Гибкая разработка»: кратко о методологиях Agile

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

Но все принимаемые решения нужно как-то «синхронизировать». Один из резидентов Hacker News отметил, что ему приходилось наблюдать за тем, как пяти сотням разработчиков в одной крупной компании разрешили самостоятельно принимать некоторые решения в «отрыве» от команды. По его словам, это был хаос. И хотя команда начала работать быстрее, она двигалась в никуда, потому что позднее возникали проблемы на этапах поддержки ПО.

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

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

Scrum

Scrum — это фреймворк гибкой разработки ПО, который считается методологией «по умолчанию». Для многих является синонимом Agile. По статистике за 2016 год, предоставленной VersionOne, Scrum используют 58% «гибких» компаний. При этом её поддерживают многие SaaS-платформы. Например, решение ServiceNow, частью которого является инструмент Agile Development.

Методология была разработана в конце 80-х — начале 90-х годов. Процесс управления состоит из фиксированных коротких итераций — спринтов (sprints).

Используя методологию Scrum, представитель заказчика плотно работает с командой разработки, расставляя приоритеты в списке требований к продукту (Product Backlog). Этот список состоит из баг-фиксов, функциональных и нефункциональных требований — из всего, что нужно сделать для реализации рабочего приложения.

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

На основании списка требований заказчика команда определяет функции, которые хочет реализовать, и начинает свой спринт. Обычно он длится 30 дней. В конце подсчитывается общее количество очков, набранных командой за спринт (скорость). Это позволяет более четко планировать следующие спринты.

За последние десять лет программисты Кен Швабер (Ken Schwaber), Майк Бидл (Mike Beedle) и Джефф Сазерленд (Jeff Sutherland) приложили множество усилий для развития Scrum. Кен Швабер — наиболее активный сторонник фреймворка, и его сайт — хорошее место, чтобы начать свое знакомство с методологией. Он также выпустил книгу.

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

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

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

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

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

Extreme Programming

Особенность Scrum заключается в том, что этот фреймворк уделяет мало внимания практикам разработки. Поэтому некоторые agile-компании (порядка 10%) комбинируют его с экстремальным программированием (XP).

Экстремальное программирование привлекло к себе внимание в конце 90-х. Концепция зародилась в сообществе Smalltalk, а её авторами считаются разработчики Кент Бек (Kent Beck) и Уорд Каннингем (Ward Cunningham), которые хотели сформировать новые практики в разработке ПО, сделанные для людей.

Первым проектом, созданным по методологии Extreme Programming, стала система контроля платежей Chrysler Comprehensive Compensation (C3) в середине девяностых. Сам термин «экстремальное программирование» появился в 1997 году.

Концепция строится на основании двенадцати приёмов:

Однако Extreme Programming делает сильный упор на тестирование, что отличает её от Scrum. Методология гласит, что разработчик не может сказать, что код написан правильно до тех пор, пока не пройдут все модульные тесты. Поэтому часто XP идет рука об руку с техникой разработки Test Driven Development (TDD), когда сперва пишется тест, а затем логика для его прохождения.

Но такая «тестоориентированность» одновременно и недостаток подхода. Чтобы адаптировать XP, нужно инвестировать в создание инфраструктуры автоматизированных тестов и непрерывного развертывания ПО.

При этом, если в случае Scrum компания может послать менеджеров проектов на двухдневные курсы, то в случае с экстремальным программированием приходится тренировать всю команду разработчиков. Что гораздо более затратно. Нужно менять культуру в организации, объединяя несколько отделов: XP требует, чтобы тестировщики, UI-дизайнеры, программисты, архитекторы и пользователи работали сообща.

/ Flickr / U.S. Army / CC

Канбан

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

Однако сегодня многие команды рассматривают иные варианты и обращают внимание на другие методологии. Одной из них стал канбан. CTO ConvertKit Грант Аммонс (Grant Ammons) говорит, что компании сперва адаптируют Scrum, который учит их необходимым дисциплинам для разработки ПО, а затем ищут более удобную альтернативу и обращаются к канбану.

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

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

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

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

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

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

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

Источник

Обзор Agile. Что это: методология, метод или философия?

В русскоязычных книгах и статьях Agile (Аджайл) часто называют гибкой методологией разработки. Если считать методологией семейство разных методов и методик разработки программного обеспечения, то это почти правда: Agile действительно создан как обобщение разных подходов к разработке ПО. Однако …

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

Этот обзор Agile предназначен скорее для «чайников», которые начинают свое знакомство с темой. Но если вы уже знакомы с Аджайлом, используйте эту статью как навигатор: в каждом ее разделе есть ссылки для углубления: детальные статьи, учебные видео, литература.

Чем Agile отличается от методологий

Термин «методология» применяется к Agile по аналогии с предшествующими подходами к организации разработки программного обеспечения: RAD, RUP, XP и другими.

Однако те, кто сталкивался с Аджайлом, понимают: он не похож на предшествующие подходы, которые описывали процесс разработки в деталях. Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий. RUP (Rational Unified Process) включает разбиение жизненного цикла разработки на 4 фазы, рекомендованные соотношения объемов работы по 9-ти потокам (workflows) на каждой фазе, а также конкретные инструменты для каждого потока. OpenUP — последняя методология-наследница RUP — короче и гибче, но все равно до краткости Agile ей далеко.

Методология — это совокупность методов и приемов, которые используются в разных сферах деятельности.

Метод — это способ достижения какой-либо цели.

Agile сам по себе не дает алгоритмов, способов и приемов. При этом входящие в Agile «гибкие» подходы нередко предписывают конкретные приемы:

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

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

Показанная выше условная схема гибких подходов взята из книги Бориса Вольфсона «Гибкие методологии разработки». Этот краткий справочник по огромному числу гибких управленческих инструментов весьма неплох для своего времени (2012), когда Agile применялся лишь в той индустрии, где он появился — в разработке программного обеспечения. Если же вы не связаны с этой индустрией, для углубления читайте более современные книги без IT-специфики.

Ценности Agile простыми словами

Ценности Agile родились в 2001 году в Agile-манифесте — в результате обобщения многих тогдашних «методологий разработки» их авторами.

Ценности — это то общее, что определяет приоритеты в работе, независимо от конкретного процесса и предмета работы. Каждая из 4-х ценностей Agile сформулирована в виде «X важнее Y», где X — это:

Посмотрим, зачем нужны эти ценности Agile.

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

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

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

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

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

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

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

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

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

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

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

Чтобы не откладывать риски проектов на последние стадии разработки (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.

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

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

Agile — философия, Scrum — ее реализация

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

Ценности эти настолько общие и даже абстрактные, что Agile часто называют философией.

Также встречается термин «гибкий образ мышления» (от английского Agile Mindset), который означает понимание человеком ценностей Agile.

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

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

Поэтому Agile и Scrum обычно изучают совместно. На нашем сайте десятки статей по гибкому управлению собраны в рубрику Аджайл и Скрам.

Исторически к Agile относится также и метод Kanban. Поэтому самый универсальный международный сертификат по Agile — ICAgile Certified Professional — включает не только Scrum, но и Kanban.

Agile сложнее, чем 4 ценности

Во-первых, помимо ценностей, в Agile-манифесте есть также 12 принципов, которые уточняют и дополняют ценности.

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

Эти 6 признаков характерны для многих гибких подходов, если они правильно применяются. Рассмотрим теперь чуть подробнее, что это за гибкие подходы.

Кратко о том, что входит в Agile сегодня

К гибким «методам управления» относятся, в частности, фреймворк Scrum и метод Kanban. Согласно исследованию Agile в России, Канбан сейчас занимает прочное второе место по популярности после Скрама (если не считать самопальных гибких подходов, которые любят изобретать в российских компаниях).

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

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

Kanban — это метод повышения качества сервиса: набор принципов и практик, которые делают сервис (или разработку продукта) более быстрым и лучше соответствующим ожиданиям потребителей.

Канбан отличается от Скрама по многим параметрам, в частности:

Наиболее широко применяется первая из 6 практик Kanban: визуализация процесса — в том числе, с помощью так называемой Канбан-доски. Это физическая или электронная доска со стикерами, обозначающими разные задачи. В отличие от Скрам-доски с 3-мя столбцами, в Канбане принято визуализировать на доске каждый этап процесса, а также делить каждый столбец на две части — «в работе» и «готово к следующему этапу»:

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

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

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

Область применения Agile

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

Судя по числу участников исследования Agile в России 2019, IT-отрасль теряет свою монополию на Agile, имея долю менее 50% от общего числа людей, вовлеченных в Agile-трансформации.

Agile — это уже давно не только про разработку программного обеспечения.

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

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

Про область применимости Agile и про основные проблемы, которые влечет за собой Agile, смотрите в 5-минутном видео Алексея Пименова:

Подробнее о том, зачем и когда нужны гибкие подходы, вы узнаете из бесплатных видеоуроков про Agile (11 видео, 65 минут).

Книги об Agile по-русски

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

Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban.

Авторы: Роб Коул, Эдвард Скотчер

Книга ориентирована в первую очередь на тех, кто планирует переходить от классического проектного менеджмента к гибкому.

Эпоха Agile. Как умные компании меняются и достигают результатов.

Автор: Стивен Деннинг

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

Scrum. Революционный метод управления проектами.

Автор: Джефф Сазерленд

Книга от основателя фреймворка Scrum. В русском переводе название книги неточное (Scrum — не про управление проектами), но все равно она считается обязательной для прочтения скрам-мастерами. Книга хорошо читается и раскрывает пользу от каждого элемента Cкрама.

Scrum и Kanban: выжимаем максимум.

Авторы: Хенрик Книберг, Маттиас Скарин

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

Резюме. Место Agile среди родственных управленческих подходов

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

Это слово сейчас имеет два основных значения:

Agile фокусируется именно на разработке — точнее, на реализации и поставке готовых продуктов. Тогда как для генерации и проверки идей новых продуктов Agile следует дополнить различными продуктовыми подходами: Customer Development, Design Thinking и т.п.

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

Agile помогает решить две основные задачи, типичные для современного бизнеса:

Для подходов к ускорению на уровне программ и портфелей проектов (в крупных организациях) грамотнее применять термин Enterprise Agility, хотя во многих контекстах их тоже относят к Agile.

Что же касается подходов к повышению гибкости/скорости принятия решений на уровне всего бизнеса, то это намного шире Agile. Так что для обозначения таких подходов следует использовать термин Business Agility, получивший распространение в конце 2010-х годов. В гибкость бизнеса входит не только быстрая поставка ценности клиентам и быстрая реакция на изменения, но также гибкость целеполагания и распределения ресурсов в организации.

Среди 12 доменов бизнес-гибкости, показанных на рисунке, Agile полностью покрывает домен «Гибкость процессов», но также связан в той или иной степени с 5-ю другими доменами, по меньшей мере.

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

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

Источник