Философия agile что это такое
Принципы Agile
Базовые ценности и 12 заповедей
Agile – это философия, которая включает в себя четыре ценности и двенадцать принципов. Преимущества этого подхода можно увидеть, только если команда готова работать по agile и если проект подходит под эту гибкую систему. В этом случае уже спустя короткий срок можно отследить следующие изменения: увеличится скорость создания продукта, появится возможность легко вносить изменения в требования к проекту, повысятся эффективность работы и качество продукта.
Содержание
История появления гибкого метода управления
Agile зародился в IT-индустрии на фоне проблем в разработке продуктов.
До 1990-х процессы по разработке программного обеспечения трудно было назвать успешными. Разработка двигалась согласно этапам, которые были описаны многочисленными документами на старте проекта. Вести документацию было необходимо в процессе разработки, что негативно сказывалось на сроках выполнения работы. Разработчики регулярно нарушали дедлайны, а из-за невозможности менять требования к продукту в процессе разработки зачастую заказчик получал продукт, не отвечающий его потребностям.
Активные попытки создать новые методы и подходы к проектам по программированию начались в 90-х годах. В это время появились такие методы, как RAD, XP, Scrum и т.д.
В 2001 году в США группа независимых практиков сформулировала новый подход, включающий в себя самые успешные принципы разработки продуктов. Этот метод был альтернативой сложным и тяжеловесным моделям управления проектами, например, водопадной. Новый подход заключался в гибкой системе управления и был назван словом «Agile».
Что такое Agile
По аналогии с другими подходами к управлению проектами Agile также называют методологией. Однако этот подход разительно отличается от всех других методологий, которые описывают процесс реализации проектов.
Agile – это философия, у которой есть манифест, описывающий четыре основополагающие ценности. К нему прилагается документ, в котором говорится о 12 принципах работы. Аджайл – это не методология или стандарт по управлению проектами, он не включает в себя терминологию, понятия, правила или инструкции. Концепция заключается в четырех ценностях и 12 принципах. А для внедрения и использования в работе этих принципов используют методологии и инструменты, или фреймворки, которые соответствуют основным принципам аджайл.
В классической системе менеджмента ход работы строго регламентирован предварительно установленными требованиями. Agile же предлагает гибкую и быструю работу, включающую адаптацию к внешним и внутренним изменениям в ходе проекта. Для достижения этого применяется итеративная разработка продукта и высокий уровень коммуникации между участниками Agile-проекта.
Основные отличия Agile от других методик заключаются в высоком уровне гибкости, а также скорости работы.
В чем секрет популярности аджайла, узнаете в статье «Agile – новый Lean?» на нашем портале.
Манифест
Agile-манифест включает в себя четыре базовые ценности. Основатели аджайл-философии создали этот документ в 2001 году, его перевели на все языки мира.
Манифест не дает четких инструкций, определений или требований к процессу управления проектами, не сообщает, что правильно или неправильно.
Люди и их взаимодействие важнее, чем процессы и инструменты.
Работу Agile-команды не должны ограничивать инструменты и процессы. Реализация проекта заключается в эффективном взаимодействии людей, которые сами принимают решения об изменениях процессов или инструментов своей работы.
Участники процесса должны общаться напрямую, исключая передачу через других людей или документацию. Обсуждения должны проходить лично или онлайн через видеосвязь, помимо чатов и писем.
Работающие продукты важнее, чем подробная документация.
Участники сосредотачиваются на том, чтобы как можно быстрее подготовить продукт к использованию. Отчеты, документы, графики второстепенны. Если составление документации замедляет создание продукта, от нее можно вовсе отказаться.
Сотрудничество с заказчиком важнее, чем согласование условий контракта.
Чтобы продукт получился именно таким, какой нужен заказчику, разработчики отказываются от лишних требований и деталей в контракте. Жесткие требования, заданные перед стартом работы, будут ограничивать команду и не позволят быстро и гибко реагировать на изменения в процессе разработки. Чтобы достичь такого уровня взаимодействия с заказчиком, важно выстроить с ним доверительные отношения, а все изменения обсуждать лично.
Готовность к изменениям важнее, чем движение по первоначальному плану.
В Agile важна готовность к изменениям и быстрая реакция на появление новых данных. Именно поэтому работа по аджайл строится в формате коротких итераций, в которые закладывают определенный пул задач. Итерация – короткий срок, от одной до четырех недель.
Если в процессе работы стало понятно, что в разработку нужно включить новый этап или изменить один из них, команда займется этим в следующей итерации.
Со стороны заказчика для внесения требуемых изменений нужно будет пожертвовать какими-то из запланированных ранее работ или отложить их. Приоритеты и сроки нужно обсуждать на встрече.
Например, в процессе работы заказчик понял, что дополнительная функция в его будущем продукте может увеличить продажи. Если команда работает по водопадной модели, то нужно будет пересмотреть контракт. На это уйдет много времени, а разработчики продолжат действовать по старому плану, общий дедлайн сдвинется, стоимость проекта увеличится, результат заказчика не устроит.
Agile-команда, наоборот, в такой ситуации берет новую задачу в работу и встраивает ее в продукт уже в следующей итерации, не тратя время на документацию. Заказчик получает результат в ближайшее время, продукт работает.
12 принципов Agile
Кроме четырех ценностей, Agile также описывает 12 принципов. Чтобы внедрить аджайл-культуру в работу компании или отдельных проектов, нужно встроить эти принципы в работу проектной команды.
Наивысший приоритет – непрерывный прогресс. Для этого команда должна регулярно поставлять работающий продукт заказчику.
Принятие изменений в требованиях даже на поздних этапах разработки продукта. Аджайл позволяет внедрять изменения для улучшения продукта и его конкурентоспособности.
Стремление поставлять работающий продукт каждые несколько недель, в крайнем случае – раз в несколько месяцев. Чем выше частота поставок, тем лучше.
Самый результативный способ передачи информации – встретиться лично.
Представители бизнеса и разработчики продукта должны работать совместно.
В процессе должны участвовать только мотивированные люди. Нужно создать для них комфортную рабочую среду, дать необходимые инструменты и доверить им делать свою работу.
Главный показатель успешности проекта – работающий продукт.
Гибкие процессы помогают постоянному развитию. Заказчик, разработчики и пользователи должны поддерживать постоянный темп работы в течение всего рабочего процесса.
Внимание к техническому совершенству и качественному построению работы делает процесс разработки более гибким.
Простота помогает избежать лишней работы.
Лучшая архитектура, требования и дизайн создаются в самоорганизующихся командах.
Команда должна непрерывно искать пути для повышения эффективности с помощью настройки и изменения своих действий.
Главные отличия от Scrum и Kanban
Главное отличие Agile от Scrum и Kanban в том, что Agile – это философия, а Scrum и Kanban – фреймворк и метод работы, которые соответствуют ценностям аджайл.
Scrum – это самый популярный фреймворк. В Scrum работа измеряется короткими по продолжительности отрезками времени – спринтами. Работа выполняется небольшой командой, до 10 человек. Обычно в команду входят: заказчик продукта, разработчики, если это ИТ-проект, и скрам-мастер.
Kanban для отслеживания задач тоже использует визуальную доску. Чем дальше вправо идет задача, тем она ценнее, тем больше на нее потратили времени и денег. Поэтому такую задачу лучше быстрее закрыть, она приоритетнее, так как быстрее принесет пользу. Чем быстрее задачи проходят до конца доски, тем эффективнее работа команды. Процессы канбана строятся не по спринтам, а по этапам выполнения задач: «сделать», «в процессе», «тестирование», «согласование» и так далее в зависимости от того, какие статусы решит ввести сама команда.
Главное различие Scrum и Kanban – длина итераций. В Scrum итерации могут длиться две или четыре недели. Встречается вариант с недельным спринтом. Спринт более четырех недель неэффективен. Итерации фиксированны, результат обсуждается по итогу итерации. В kanban можно передавать результат в любое время, даже через день. Это дает больше гибкости и позволяет чаще отдавать продукт заказчику. Также, как правило, задачи в Scrum распределяются по следующим статусам: «бэклог», «в работе», «выполнено». В Kanban можно устанавливать любые статусы задач, которые отвечают вашим потребностям.
Плюсы и минусы
Если аджайл подходит для вашего конкретного проекта, тогда проявляются плюсы:
Скорость. Обычно при использовании фреймворков срок разработки продукта гораздо короче, чем при использовании водопадной модели, например.
Гибкость. Заказчик может легко вносить изменения в требования к продукту по ходу его реализации.
Качество продукта. Быстрое реагирование на новые данные помогает сделать продукт более качественным, а его характеристики более совершенными.
Agile очень требователен к профессионализму команды. Если в команде есть люди, которые не соответствуют профессиональным требованиям или отстают от остальных членов команды, работать по модели Agile будет сложно. Лучше подбирать членов команды с одинаковым уровнем профессионализма.
Работать по гибкой системе с немотивированными людьми очень тяжело. Так как самая важная составляющая аджайл – самостоятельная команда, немотивированный сотрудник не сможет вовлечься в процесс в полной мере. Для эффективной работы нужна профессиональная и достаточно мотивированная команда.
Как внедрить Agile в работу компании
По аджайлу сегодня работают уже организации из разных сфер, а не только ИТ-компании. Решение о внедрении Agile-методологии управления проектами должно приниматься на основе следующих шагов:
Сначала надо определиться с целями. Их нужно ставить по Smart-методу постановки целей, основанному на пяти принципах: конкретности, измеримости, достижимости, важности и определенности. Важно понять, зачем вы хотите внедрить Agile, на какие метрики в работе компании желаете повлиять.
Проанализировать все проекты и понять, какие из них могут быть модернизированы с помощью гибкого подхода и сколько их. Если таких проектов нет, то вопрос о внедрении можно снять.
Понять, сможете ли вы реализовать эти цели. В этом поможет тестовый запуск аджайл-модели для одного из проектов. Для этого надо выбрать один из фреймворков, например, Scrum – он сейчас наиболее популярен. Выберите пилотный проект, на нем проведите обучение сотрудников и протестируйте работу. Желательно для этого пригласить профессионального Scrum-мастера или аджайл-коуча, чтобы он помог первой команде сделать внедрение.
Затем нужно расселять тех людей, которые научились работать по этому фреймворку, по нескольким командам и постепенно культивировать новую модель взаимодействия. Люди должны научиться работать в новых ролях, по-новому подходить к требованиям к продукту, проводить довольно много совещаний и т.д.
Книги про Agile
Чтобы разобраться с принципами Agile и понять, как внедрить эту модель в работу компании, стоит изучать литературу не об аджайл в целом, а о конкретных инструментах и методологиях. Вот пара книг об инструментах внедрения гибкого подхода:
Книга основателя методологии scrum Джеффа Сазерленда «Scrum. Революционный метод управления проектами» поможет понять, как она работает, какие плюсы и минусы у нее есть, а также даст описание конкретных шагов для внедрения Scrum в работу. Эта книга подойдет для менеджеров, руководителей, разработчиков, а также всех, кто изучает теорию эффективного управления проектами.
Книга «Канбан. Альтернативный путь к Agile», которую написал основатель подхода, научит распознавать возможные пути улучшения работы компании или отдельного проекта. В книге автор делится знаниями об управлении процессами создания продукта, помогает понять, стоит ли встраивать методологию в работу, и описывает способы внедрения Kanban в работу компании. Книга полезна для менеджеров и руководителей проектов.
Как объяснить бабушке, что такое Agile за 15 минут с картинками
«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера
Самый просматриваемый ролик на 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 — это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.
График уничтожения историй
Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.
Два тренда — оптимистичный и пессимистичный (можно на глаз). Расстояние между трендами показывает насколько нестабильна скорость работы команды. Со временем эти тренды стабилизируются и конус неопределенности будет уменьшаться.
Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?
Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.
Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.
Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»
Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное — позже.
Владелец продукта делает расчеты еженедельно и использует исключительно эмпирические данные, а не выдает желаемое за действительное. Он честно говорит о неопределенности. Команда поддерживает темп работы, а Пэт не давит на них, заставляя ускориться.
Несколько команд
Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.