Agile основные принципы: 1.1 Что такое Agile?

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 принципов. Чтобы внедрить аджайл-культуру в работу компании или отдельных проектов, нужно встроить эти принципы в работу проектной команды. 

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

2. Принятие изменений в требованиях даже на поздних этапах разработки продукта. Аджайл позволяет внедрять изменения для улучшения продукта и его конкурентоспособности.

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

4. Самый результативный способ передачи информации – встретиться лично.

5. Представители бизнеса и разработчики продукта должны работать совместно.

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

7. Главный показатель успешности проекта – работающий продукт.

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

9. Внимание к техническому совершенству и качественному построению работы делает процесс разработки более гибким.

10. Простота помогает избежать лишней работы.

11. Лучшая архитектура, требования и дизайн создаются в самоорганизующихся командах.

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

Главные отличия от Scrum и Kanban

Главное отличие Agile от Scrum и  Kanban  в том, что Agile – это философия, а Scrum и Kanban – фреймворк и метод работы, которые соответствуют ценностям аджайл.

Scrum – это самый популярный фреймворк. В Scrum работа измеряется короткими по продолжительности отрезками времени – спринтами. Работа выполняется небольшой командой, до 10 человек. Обычно в команду входят: заказчик продукта, разработчики, если это ИТ-проект, и скрам-мастер.

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

Главное различие Scrum и Kanban – длина итераций. В Scrum итерации могут длиться две или четыре недели. Встречается вариант с недельным спринтом. Спринт более четырех недель неэффективен. Итерации фиксированны, результат обсуждается по итогу итерации. В kanban можно передавать результат в любое время, даже через день. Это дает больше гибкости и позволяет чаще отдавать продукт заказчику. Также, как правило, задачи в Scrum распределяются по следующим статусам: «бэклог», «в работе», «выполнено». В Kanban можно устанавливать любые статусы задач, которые отвечают вашим потребностям.

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

Если аджайл подходит для вашего конкретного проекта, тогда проявляются плюсы:

• Скорость. Обычно при использовании фреймворков срок разработки продукта гораздо короче, чем при использовании водопадной модели, например.

• Гибкость. Заказчик может легко вносить изменения в требования к продукту по ходу его реализации.

• Качество продукта. Быстрое реагирование на новые данные помогает сделать продукт более качественным, а его характеристики более совершенными.

Минусы Agile-подхода:

• Agile очень требователен к профессионализму команды. Если в команде есть люди, которые не соответствуют профессиональным требованиям или отстают от остальных членов команды, работать по модели Agile будет сложно. Лучше подбирать членов команды с одинаковым уровнем профессионализма.

• Работать по гибкой системе с немотивированными людьми очень тяжело. Так как самая важная составляющая аджайл – самостоятельная команда, немотивированный сотрудник не сможет вовлечься в процесс в полной мере. Для эффективной работы нужна профессиональная и достаточно мотивированная команда.

Как внедрить Agile в работу компании

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

• Сначала надо определиться с целями. Их нужно ставить по Smart-методу постановки целей, основанному на пяти принципах: конкретности, измеримости, достижимости, важности и определенности. Важно понять, зачем вы хотите внедрить Agile, на какие метрики в работе компании желаете повлиять.

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

• Понять, сможете ли вы реализовать эти цели. В этом поможет тестовый запуск аджайл-модели для одного из проектов. Для этого надо выбрать один из фреймворков, например, Scrum – он сейчас наиболее популярен. Выберите пилотный проект, на нем проведите обучение сотрудников и протестируйте работу. Желательно для этого пригласить профессионального Scrum-мастера или аджайл-коуча, чтобы он помог первой команде сделать внедрение.

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

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

Книги про Agile

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

Книга основателя методологии scrum Джеффа Сазерленда «Scrum. Революционный метод управления проектами» поможет понять, как она работает, какие плюсы и минусы у нее есть, а также даст описание конкретных шагов для внедрения Scrum в работу. Эта книга подойдет для менеджеров, руководителей, разработчиков, а также всех, кто изучает теорию эффективного управления проектами.

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

Принципы гибкой методологии управления проектами Agile: почему люди важнее бюрократии

Наталья Баранова

Контент-директорка «Теплицы социальных технологий».

Аджайл (Agile) – философия, определенный образ мышления с системой ценностей. Сторонники аджайла верят, что создать идеальный продукт или запустить проект могут самостоятельные команды из профессионалов. Замредактора Теплицы Наталья Баранова попросила менеджера «Альфа-банка» Артема Молчанова прокомментировать основные принципы, написанные в манифесте гибкой разработки Agile.

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

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

Принцип 1: «Люди и взаимодействие важнее процессов и инструментов»

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

Еще по теме: Как управлять проектом с помощью методов Agile, Scrum и Kanban

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

90% людей до сих пор приходят ко мне и говорят: «Мы же работаем по аджайл, у нас нет документации, как понять этот принцип?». Дело в том, что в аджайл тоже есть документация и договоры, просто эти компоненты на втором плане. Важнее конечный продукт, которым клиент будет пользоваться.

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

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

Принцип 3: «Сотрудничество с заказчиком важнее согласования условий контракта»

Об этом принципе многие забывают, но он дополняет самый первый – про важность взаимодействия людей. В классическом подходе работа над проектом выглядит так: it-подразделение и бизнес-подразделение работают отдельно. Бизнес в роли заказчика придумывает, закидывает тему разработчикам, через полгода приходит и спрашивает результат. Но за этот срок ничего не сделано.

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

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

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

Еще по теме: Scrum в деталях

Принцип 4: «Готовность к изменениям важнее следования первоначальному плану»

Этот принцип зачастую интерпретируют неверно: «Что бы ни произошло – это изменения». Этим тезисом очень легко манипулировать. Допустим, владелец продукта понял, что не учел что-то важное и все пропало. Он экстренно обращается к команде и говорит: «Мы все переиграли, будем делать вот так». Команда в недоумении: «Мы же так не договаривались», а владелец пожимает плечами и аргументирует: «Ну, извините, у нас аджайл». Но этот принцип вовсе не о подобном хаосе в работе.

Раз в неделю команда собирает обратную связь от клиента и понимает, что нужно изменить, чтобы улучшить продукт. С этими пожеланиями она приходит к владельцу продукта. Начинается работа по совершенствованию. Готовность к изменениям – это когда команда понимает: «Да мы сделали не то, но мы же здравые люди, давайте поменяем нашу модель поведения и все исправим».

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

404: Страница не найдена

ИТ-директор

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

Что я могу сделать сейчас?

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

Поиск

• Узнайте последние новости.
• Наша домашняя страница содержит самую свежую информацию о CIO.
• Наша страница о нас содержит дополнительную информацию о сайте, на котором вы находитесь, ИТ-директор.
• Если вам нужно, свяжитесь с нами, мы будем рады услышать от вас.

Просмотр по категории

Облачные вычисления

• Знакомство с иерархией ресурсов Azure

  Группы управления Azure, подписки, группы ресурсов и ресурсы не являются взаимоисключающими. Предприятия могут – и часто делают…

• Начните работу с Amazon CodeGuru с помощью этого руководства

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

• Упростите управление несколькими облаками с помощью 5 лучших практик

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

Мобильные вычисления

• Каковы лучшие файловые менеджеры для устройств Mac?

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

• Как обеспечить безопасность профилей конфигурации iPhone 9Профили конфигурации 0002 упрощают управление BYOD iPhone, но они также связаны с вредоносными программами. Политики безопасности мобильных устройств…

• Как удалить профиль управления с iPhone

  User Enrollment создает профиль управления для BYOD iPhone, но ИТ-отдел должен удалить эти данные в таких случаях, как потеря или кража устройства…

Дата-центр

• Используйте Cockpit для удаленного администрирования сервера Linux

  Администраторы Linux могут использовать Cockpit для просмотра журналов Linux, мониторинга производительности сервера и управления пользователями. Используйте инструмент, чтобы помочь администраторам управлять …

• Учебник по гипермасштабируемым центрам обработки данных

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

• Узнайте, кто строит инфраструктуру 5G

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

Каковы 4 основных принципа гибкой методологии?

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

Краткий обзор Agile Manifesto

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

Целью его авторов не является пропаганда антиметодологии. Вместо этого они хотели «восстановить доверие к слову «методология». Таким образом, они стремились сбалансировать существующие способы разработки программного обеспечения с некоторыми новыми альтернативами. Например, они принимают моделирование и документацию только тогда, когда это полезно для проекта.

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

Четыре ценности Agile

1. Вот четыре основные ценности, изложенные в Манифесте Agile:
2. Индивиды и взаимодействие в процессах и инструментах
3. Рабочее программное обеспечение поверх исчерпывающей документации
4. Сотрудничество с клиентами по поводу переговоров по контракту
5. Реагирование на переход по плану

Ценность № 1: Индивидуумы и взаимодействия

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

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

Значение № 2: Работающее программное обеспечение

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

Связанное содержимое:

Практические причины для работы с командой, использующей Agile-методологию

Ценность № 3: сотрудничество с клиентами

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

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

Значение № 4: Реагирование на изменения

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

12 принципов Agile-манифеста

Помимо основных принципов Agile Manifesto также включает в себя следующие 12 принципов:

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

Связанное содержание:

Подробный обзор 12 принципов Agile-управления проектами

Выводы

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

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

No related posts.