Agile методологии ведения проектов. Гибкая методология разработки (Agile). Преимущества гибкой методологии проектного управления

Перевод

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
- закон Хофштадтера

Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут - лучшее что я видел. TED отдыхает.

Роли

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

Это заинтересованные лица . Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.

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

У заинтересованных лиц много идей, и Пэт помогает сделать из идей пользовательские истории.

Это команда разработчиков . Те, кто будет строить рабочую систему.

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

Так как команда использует гибкую методологию разработки , они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 4-6 пользовательских историй в неделю. Это их пропускная способность . Ее очень просто измерить - количество пользовательских историй за 7 дней.

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

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

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

Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.

Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.

Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”

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

Kanban рекомендует ограничиться несколькими задачами - WIP limit. Допустим команда решает, что 5 - это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.

Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.

Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.

Есть только один способ держать список задач под контролем - это слово “нет”

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

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

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

Принятие решений

Некоторые истории крайне необходимы, а некоторые просто бонусные фичи. На разработку одних историй уйдет пару часов, на разработку других - месяцы.

Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи - вот что помогает Пэт расставлять приоритеты.

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

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

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

Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.

Владелец ИТ-продукта должен постоянно со всеми общаться

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

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

На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.

Риски

Бизнес риск: «Правильную ли вещь мы делаем?»

Социальный риск: «Сможем ли мы сделать то что нужно?»

Технический риск: «Будет ли проект работать на данной платформе?»

Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»

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

Компромисс между ценностями знания и ценностями для клиента

С точки зрения заказчика кривая выглядит вот так:

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

Компромисс между краткосрочным и долгосрочным мышлением

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

Делать правильные вещи, делать вещи правильно или делать быстро?

В идеале - все три одновременно, но в реальности приходится выбирать.

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

Мы делаем быстро прототип продукта. Для краткосрочной перспективы это неплохо. В долгосрочной - мы получаем технический риск. И скорость разработки снизится до нуля.

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

Между ролями в Scrum существует здоровое противостояние

Владелец продукта фокусируется на построении правильных вещей. Команда фокусируется на том, чтобы строить вещи правильно. Scrum-мастер или agile-тренер фокусируется на сокращении цикла обратной связи.

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

Компромисс между разработкой нового продукта и улучшением старого

Продукт никогда не может быть полностью завершен, потому что ему постоянно нужны изменения. Когда команда начинает работу над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой - очень затратно и рискованно. Обычно команда поддерживает старый продукт, разрабатывая новый. Поэтому скорее понятие “Backlog” относится не к продукту а к команде. Backlog - это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.

График уничтожения историй

Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.

Два тренда - оптимистичный и пессимистичный (можно на глаз). Расстояние между трендами показывает насколько нестабильна скорость работы команды. Со временем эти тренды стабилизируются и конус неопределенности будет уменьшаться.

Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?

Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ - в апреле или мае.

Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.

Заинтересованное лицо спрашивает:«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»

Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное - позже.

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

Примером философии Agile является принцип работы известного завода «Toyota», где любой подчиненный мог остановить конвейер, и внести корректировки. ()

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

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

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

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

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

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

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

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

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

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

История Agile

в 1970 году, д-ром Уинстоном Ройсом была представлена методика «управление разработкой крупных программных систем». С тех пор, стало существовать понятие Agile. Полная история становления проектного управления описана в

Кое что про Scrum метод

Преимущества гибких методов разработки

Повышение качества результатов
Адаптация к изменениям
Очень быстро и эффективно
Более контролируемый график реализации проекта

Основные принципы Agile

Вовлечение пользователей имеет решающее значение;
Чтобы принимать решения, команды должны быть высокоэффективными;
Этапность и цикличность как основа;
Концентрируется на частых представлениях промежуточных результатах проектов;
Применяется правило работы 80/20;
Использование совместного подхода к реализации плана;
Завершения отдельного этапа, для перехода к следующему.

Также мы вывели 12 основных принципов Agile методологии в отдельную инфографику. Посмотреть можно

Характеристики методики:

Итерационная
Модульная
Возрастающая
Адаптивная
ОбъединяющаяОшибки при внедрении гибких методов управления проектами описаны в статье

Зачем использовать Agile?

Прирост денежного потока
Контроль рисков
Снижение времени и накладных расходов
Повышение подотчетностиО том как использовать Agile для развития читайте в статье

Какая методология управления проектами подходит для вас?

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

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

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

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

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

Каскадная методология требует детального планирования в начале проекта

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

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

Лучше всего подходит для проектов, которые имеют дело с физическими объектами – от строительных проектов до проектов по установке оборудования
Требования описываются в начале проекта
Лучше всего для проектов с четко определенными задачами и этапами, которые необходимо выполнить в определенной последовательности (например, построить первый этаж здания до второго этажа)
Не требуется участие заказчика в процессе разработки
Графики проектов можно использовать в будущем, для идентичных или аналогичных проектов
Полный объем требований заранее известен
Определенные в ТЗ результаты снижают вероятность недоделок

Недостатки классической методологии проектного менеджмета

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

Agile – методология управления проектами

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

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

Преимущества гибкой методологии проектного управления

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

Недостатки гибкой методологии проектного управления

Команда все время вовлечена в проект
Не подходит для проектов с четко определенными требованиями и объемами
Неопределенность в объеме и сроках работ могут заставить нервничать Заказчиков и руководство (по началу)
У клиента может не быть времени на вовлечение в проект
Требует постоянного отслеживания работ и ведение документации по управлению задачами команды
Заказчик может пересмотреть объем работ
Быстрый запуск может привести к неполному выполнению задач

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

Удачи в проектах!

Совмещение Agile и поточной методологии

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

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

Процесс оказания услуг

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

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

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

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

4. Разработка решения
Команда разработчиков начинает проработку решения.

Гибкая методология разработки (agile-структура)

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

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

Уникальность совмещенной методологии:

Использование Agile методологи на каждом шаге приводит к экономии средств и ресурсов как клиента, так и исполнителя.

Использование каскадной модели для крупного проекта приводит к контролю над общими результатами.

Обеспечение быстрой обратной связи между клиентом и командой разработчиков.

Быстрое и частое прототипирование .

Подход, ориентированный на клиентов – ориентация на минимизацию общей стоимости владения (TCO) и максимизировать отдачу от инвестиций (ROI).

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

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

История Agile

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

В 1990-х годах был разработан ряд гибких методов разработки программного обеспечения в ответ на преобладающие тяжеловесные методы. К ним относятся: с 1991 года — RAD (быстрая разработка приложений); с 1994 года — метод разработки динамических систем (DSDM); с 1995 года — Scrum; С 1996 года, Crystal Clear и экстремальное программирование (XP); А с 1997 года — Feature driven development (FDD). Хотя они возникли до публикации Манифеста Agile Software Development, они все вместе называются гибкими методами разработки программного обеспечения.

В феврале 2001 года семнадцать разработчиков ПО встретились на курорте Snowbird в штате Юта, чтобы обсудить легкие методы разработки. Вместе они опубликовали Манифест о гибкой разработке программного обеспечения Agile.

Манифест Agile

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

4 идеи Agile

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

12 принципов Agile

Удовлетворенность клиентов за счет ранней и непрерывной поставки программного обеспечения. Клиенты более счастливы, когда они получают рабочее программное обеспечение через регулярные промежутки времени.
Вносить изменения требований к продукту на протяжении всего процесса разработки.
Частая поставка рабочего программного обеспечения (каждый месяц, две недели, неделю и т.д.).
Сотрудничество между заинтересованными сторонами (заказчиком и разработчиками) на протяжении всего проекта.
Поддержка, доверие и мотивация вовлеченных людей. Мотивированные команды с большей вероятностью выполняют свою лучшую работу, чем сотрудники, недовольные условиями труда.
Взаимодействие лицом к лицу. Коммуникация более успешна, когда команды разработчиков имеют возможность общаться напрямую.
Рабочее программное обеспечение является основной мерой прогресса. Предоставление функционального программного обеспечения клиенту является конечным фактором, который измеряет прогресс.
Поддержка постоянного темпа работы. Команды устанавливают повторяемую и поддерживаемую скорость работы, с которой они могут доставлять функционирующее программное обеспечение.
Внимание к техническим деталям и дизайну. Правильные навыки и хороший дизайн позволяют команде поддерживать темп, постоянно совершенствовать продукт и работать над изменениями.
Простота.
Самоорганизующиеся команды поощряют отличную архитектуру, требования и проекты. Квалифицированные и мотивированные члены команды, которые обладают полномочиями принимать решения, регулярно общаются с другими членами команды и обмениваются идеями, которые обеспечат создание качественного продукта.
Постоянная адаптация к изменяющимся условиям, что поможет сделать продукт более конкурентоспособным на рынке.

Основа метода Agile

Основой метода гибкого управления проектами является ряд ключевых элементов:

Визуальный контроль. Участники проекта в ходе работы над проектом используют карточки различных цветов и видов, которые сигнализируют, какой элемент конечного продукта уже разработан, спланирован, завершен и т.д. Таким образом, команда имеет наглядное представление о существующем положении дел. Визуальный контроль обеспечивает одинаковое видение проекта каждым из участников.
Все участники проекта работаю рядом, включая клиента. Такой подход не только ускоряет многие процессы, связанные с информированием участников рабочей группы, но и создает благоприятную атмосферу для сотрудничества и эффективной работы.
Адаптируемое управление. Руководитель проекта – не человек, который раздает указания, а лидер, определяющий основные правила работы и сотрудничества.
Совместная работа. Команда, руководитель проекта и клиент работают сообща, что исключает возможность потери информации и непонимания целей. Также прозрачность всех процессов позволяет моментально исключать появившиеся проблемы и находить удачные решения и улучшения.
Работа, основанная на разделении общего объема проекта на составные части. Такая система работы значительно снижает сложность проекта и позволяет командам сфокусироваться на каждой части в отдельности.
Работа над ошибками. В ходе работы одного цикла команда осваивает новые навыки и анализирует произошедшие ошибки, что исключает их появление в следующем цикле.
Спринты и ежедневные встречи. Спринты – отрезки времени, за которые команды выполняет ряд задач, — позволяют четко видеть результаты работы. Разделив время работы над проектом на спринты, получаем, например, 10 спринтов, каждый по две недели. А ежедневные встречи не более чем на 15 минут помогут каждому члену команды ответить для себя на три вопроса: что я делал вчера, что я буду делать сегодня, что мне мешает выполнять работу?

Таким образом, внедрение гибкого метода Agile возможно при следующих условиях:

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

На данный момент методология Agile широко распространена в IT-сфере и начинает осваивать деловую сферу, в частности маркетинг, менеджмент, обучение и т.д.. Метод гибкого управления проектами используется многими компаниями и госструктурами, например, правительства Норвегии и Новой Зеландии применяют Agile. В России «Сбербанк» осваивает Agile для коммерческой сферы.

Системы управления проектами, основанные на Agile

Существует множество методов, основанных на идеи Agile, самые популярные из них — Scrum и Kanban.

SCRUM

Scrum — это методология управления проектами, в основе которой делается акцент на качественном контроле процесса работы. Хиротака Такэути и Икудзиро Нонака — первые, кто описал подход Scrum, объяснили его как “подход регби”, в котором scrum — это борьба за мяч. Сам метод представляет собой процесс разработки, разделенный на небольшие итерации — спринты, по завершении которых пользователи получают улучшенный вариант ПО. Спринт жестко фиксирован по времени, а его длительность составляет от 2 до 4 недель. Работа в рамках одного спринта состоит из нескольких этапов:

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

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

Scrum значительно увеличивает производительность и сокращает время до преимуществ по сравнению с классическими процессами «waterfall». Процессы Scrum позволяют организациям плавно адаптироваться к быстро меняющимся требованиям и создавать продукт, отвечающий изменяющимся бизнес-целям. Scrum позволяет:

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

Kanban

Kanban — это процесс, призванный помочь командам работать вместе более эффективно. В переводе с японского kanban обозначает “рекламный щит, вывеска”, а сам метод взят и адаптирован с производственной системы Toyota. Суть Канбан заключается в том, чтобы сделать процесс разработки максимально прозрачным и распределять нагрузку равномерно между членами команды. Канбан способствует непрерывному сотрудничеству и поощряет активное, постоянное обучение и совершенствование.

Kanban основан на трех принципах:

Визуализация задач: видимость всей информации о проекте поможет увидеть недочеты, ошибки и накладки.
Контроль и ограничение WIP (work in progress — работа, выполняемая одновременно): это помогает сбалансировать подход, основанный на потоках, чтобы команды не начинали и не совершали слишком много работы сразу.
Контроль времени на выполнение задачи и оптимизация работы для экономии времени.

Достоинства и недостатки Agile

Любая методология имеет преимущества и недостатки. Рассмотрим плюсы и минусы Agile.

Преимущества

1. Больше гибкости по сравнению с методологией Waterfall.

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

2. Меньше дефектов в конечном продукте.

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

Недостатки

1. Постоянное получение обратной связи приводит к постоянному переносу даты завершения проекта.

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

2. Документация

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

3. Частые встречи

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

Внедрение Agile

Выбор методики. Существуют различные гибкие методологии, которые разработаны под определенные условия. Первым этапом работы с Agile необходимо определить цели задачи работы, сроки, количество сотрудников и многое другое и подобрать такую гибкую методику управления проектом, которая будет отвечать всем требованиям.
Обучение персонала. Обучение необходимо для того, чтобы сотрудники понимали базовые принципы Agile и знали как с ними работать. Именно на этом этапе определяются подводные камни, которые могут снизить эффективность Agile. Готов ли коллектив к изменениям? Подходят ли проекты компании для гибких методик? На эти и многие другие вопросы обычно помогают ответить бизнес-тренеры, специализирующиеся на Agile. Помимо прочего будет также составлен список тренингов и план, по которому будет вестись внедрение Agile в компании.
Демонстрация Agile. Своеобразный тест-драйв Agile, которые проводится под контролем специалиста и показывает все этапы работы, объясняет функции ролей, взаимодействие внутри команды и между командами и т.д.
Создание команды. В создание команды помимо подбора сотрудников также входит определение обязанностей, распределение задач, создание графика встреч и т.д. Каждая из методик рассчитана на определенное количество человек в команде.
Выбор инструментов , необходимых для распределения задач, ведения отчетности, аналитики и прочее.
Первый проект с Agile. В первом проекте будут ошибки, несостыковки, отказ от одних инструментов и выбор других. Любая методика требует своеобразной адаптации под особенности компании, в которую она внедряется.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .

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

Три объёма значения Agile

В первом, более узком значении, этот термин стал с начала 2000-х использоваться в сфере разработки программного обеспечения, когда в американском штате Юта, на горном курорте, собрались отраслевые специалисты, чтобы обсудить методики и практики создания программных продуктов, востребованных конечным потребителем. Результатом той встречи стал Манифест (Agile Manifesto) разработки программных продуктов, с 12-ю принципами, которые, в первую очередь, касались узкой сферы деятельности авторов, но потенциально могли быть распространены и на некоторые другие бизнес-проекты.

Во втором, более широком, значении термина принципы Agile применяются к ведению почти любого бизнеса и в качестве составляющих используются, например, в концепции «бережливого стартапа» (Lean Startup). В этом значении под Agile-моделью (Agile Model) понимают следование гибкой методологии развития проекта, проходящей по характерной схеме в несколько шагов.

Работа над проектом ведётся итерациями – короткими циклами (спринтами). (В случае с разработкой программного обеспечения продолжительность этих циклов составляет от 1 недели до 1 месяца).
По завершении каждого цикла выходит продукт, который уже можно применять в бизнесе. Для программного обеспечения таким продуктом может стать приложение или только его часть, однако даже «сырой» софт уже можно и нужно пробовать в деле.
Продукт проверяется заказчиком или пользователями, которые поддерживают с разработчиками постоянную обратную связь. Клиентоориентированный подход применяется в течение всего проекта (всех итераций).
Любые замечания быстро включаются в доработку, а изменения, позволившие сразу по ходу подправить разработку продукта, – приветствуются, поскольку это позволяет не накапливать глобальные ошибки системы.

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

Быструю обратную связь в настройке конечного формата производства на заводах «Toyota» обеспечивал любой рабочий, который мог стать инициатором остановки конвейера и автором корректировок по донастройке производственного цикла. В масштабах всего производства Agile-трансформация может повлечь за собой переналадку производственной деятельности в целом, если продукт становится результатом живого отклика на текущие потребности клиента. Так, если фабрика выпускала пластиковые тазы, а обратная связь с клиентом демонстрирует потребность в вёдрах, то быстрая адаптация с параллельной корректировкой нюансов (формы ручки, величины, цвета) будет как раз в стиле Agile management (если соблюдены и остальные принципы).

Принципы Agile-управления

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

Решающее значение для настройки продукта имеет потребитель и степень его вовлеченности в создание результата.
Для принятия решения команды должны быть высокоэффективными и сплочёнными.
Поэтапная и цикличная работа становится основой процесса. Проект делится на мелкие части, которые завершаются к определённому сроку до завершения проекта в целом.
Фокус оценки результативности направлен на частые представления промежуточных состояний проекта.
В работе коллектив опирается на закон Парето, по которому 20% усилий дают 80% эффективности, что позволяет не доводить каждый отдельный цикл до совершенства перед представлением результата потребителю. Продукт совершенствуется естественным образом с каждой новой итерацией.
Предполагается обязательное завершение одного этапа перед переходом к следующему.

«Гибкий» подход стал базовым для целого ряда методологических практик, которые отличаются между собой, но включают идеи Agile: Scrum, Kanban, Lean, Crystal и др. Методология Scrum, например, практически всегда рассматриваются в связке с Agile как единая система управления проектами по разработке программного обеспечения.

Метод Scrum демонстрирует, как «гибкий подход» может быть применён на практике в конкретных операциях. Так, например, работа с требованиями по проекту реализуется с помощью четырёх «артефактов»:

Product backlog предполагает формирование списка требований, созданного по единому шаблону (User Story) и отсортированного по приоритетам. Если требований нет, проект завершается.
Sprint backlog – это требования ближайшего спринта (этапа), разделённые на задачи без возможности добавлять новые требования в течение спринта. Обязательство на ближайший этап, взятые командой с типом управления Agile, записываются на доске (т. н. Kanban).
Sprint Goal – общая цель спринта – ориентир при принятии альтернативных решений.
Sprint Burndown Chart – «диаграмма сгорания». Она показывает насколько продвинулась команда в течение этапа.

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

Характерные ошибки внедрения Agile и недостатки подхода

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

К распространённым ошибкам внедрения относятся следующие:

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

Agile («аджайл») - слово, которое последнее время звучит из каждого утюга. Но что такое Agile и, главное, зачем этот Agile нужен?

Если открыть толковый словарь, например, Оксфордский, то можно прочитать там, как минимум, два определения:

Able to move quickly and easily.
Able to think and understand quickly.

То есть, чтобы быть agile, надо уметь быстро и легко двигаться и быстро соображать. Кажется, довольно полезные качества, особенно в бизнесе. Быстро соображать и быстро реагировать - это именно то, что доктор прописал, для нашего времени, иначе просто не выжить: конкуренты сожрут. В мире всё меньше отраслей, где этих конкурентов, нет. Да ещё скорость копирования практически лишает возможности вывести продукт на рынок и почивать на лаврах. Без способности быстро адаптироваться к изменениям, которую даёт так называемая «методология Agile», выживать всё сложнее.

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

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

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

Фокусировка на нуждах и целях клиентов

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

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

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

Примеры подобных инструментов - Lean Canvas, Impact Mapping, User Story Mapping и другие Agile-методы описания гипотез и процессов.

Один из краеугольных камней Agile - это предельная простота. И оргструктура организации, и процессы, по которым работают люди, и правила должны быть настолько простыми, насколько это возможно. Это позволит людям сфокусироваться на своей работе, на ценности, которую они создают, а не на соблюдении регламентов и правил. Прекрасные примеры такого подхода можно найти во множестве команд, работающих по Scrum - самому популярному способу организации рабочего процесса в Agile. Фактически, все договорённости и правила команды в 10-11 человек, текущие задачи на пару недель, цели, а также стратегические планы легко могут поместиться на 2-3 листа бумаги А0. На одном листе может быть так называемый «бэклог спринта», перечень всего, что команда собирается сделать в ближайшую итерацию. Если повесить такой в помещении, где идёт работа, можно избавить себя от необходимости всё это запоминать. То же самое касается и процессов. Скажем, в Скраме место и время проведения всех встреч жестко фиксируются. Любой участник точно знает, что, например, в понедельник в 10-00 планируется ближайшая итерация, а в пятницу в 17-30 - встреча по улучшению процесса работы.

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

Примеры упрощения (и уплощения, но это тема отдельного разговора) в Agile - Scrum, Nexus, LeSS (Large-Scale Scrum, или Скрам на больших масштабах), а также сам Agile-манифест.

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

Чтобы подобного избежать, применяется так называемый итеративно-инкрементальный подход, когда:

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

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

Ещё одно преимущество такого подхода, помимо раннего выхода на рынок и внесения изменений на ранних стадиях работы, - это возможность более точно измерять прогресс. Мы не просто «сделали 15% всей работы», что довольно абстрактно. Мы «сделали 15% функционала», который уже работает.

Все процессные подходы в Agile имеют короткие циклы, будь то упомянутые ранее Scrum, Nexus, LeSS, SAFe или , плюс необходимость работы такими циклами упомянута и в самом манифесте Agile.

Активное, системное использование обратной связи

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

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

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

Примеры, опять-таки, есть везде: ретроспективные встречи в Scrum, Kanban, Nexus и LeSS, циклы I&A в SAFe, подход к созданию продуктов Design Thinking, и т.д.

Зачем давать больше полномочий, когда можно дать бумажку с инструкцией? Есть, как минимум, три причины это делать.

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

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

В-третьих, это всё та же скорость. Если человек может сам, на своём месте, никого не спрашивая, решить какую-то проблему, это сокращает время принятия решений. Не надо больше отправлять вопрос «вверх» и ждать ответа от менеджмента. Это преимущество не так заметно, если у вас работает 3 человека, но если вас 30, или 300, или 3000… В больших организациях, построенных сугубо на иерархическом принятии решений, паралич воли может быть довольно частым явлением.

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

Зачем относиться к людям по-человечески? То есть, моральная сторона дела ясна, а какую пользу это принесёт владельцу предприятия?

Ответ довольно простой. Если создание того, что вы продаёте, не требует умственного труда, а только механический действий - можете не заморачиваться. Просто платите соразмерно сделанной работе, и всё. Но как только в дело вступает мозг работников - придётся считаться с принципами мотивации умственного труда. А они говорят, что для людей важны возможность самореализации, повышения своего мастерства, принесения чего-то ценного в мир, самостоятельности в решениях и ещё ряда факторов. И человек мотивированный (не путать с человеком простимулированным!) будет вкладываться в работу сильнее, и результат будет качественнее и быстрее. Да и в целом, приятная обстановка на работе добавляет желания туда приходить и работать - с этим тоже вряд ли кто поспорит.

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

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

Agile - это не конечное состояние, а образ мышления и жизни

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

И если всё удалось: люди в компании понимают и разделяют ценности и принципы Agile и работают согласно им, - тогда менеджменту не придётся «тащить» на себе любые изменения или «пинать» работников, чтобы они начали что-то делать по-другому. Предприятие станет единым организмом, управление которым будет отнимать меньше сил и приносить больше удовольствия.
А там, где больше удовольствия от работы, и результат выше. Это касается не только специалистов, но и менеджмента, причём в ещё большей степени.