Заявка на услуги DST
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Agile (эджайл) — методология управления проектами. Она возникла в сфере IT и сначала использовалась для разработки ПО. Сейчас Agile используют и в других отраслях — поэтому, кроме проджектов, в методологии должны разбираться и другие менеджеры, а также руководители компаний.
Что такое Agile
Термин Agile используют в двух значениях:
- Это философия, система ценностей и принципов, по которым работает команда проекта.
- Это семейство методологий управления проектами, которые созданы на базе философии Agile.
С английского agile переводится как «гибкий». Гибкость лежит в основе и философии, и методологий. Это означает, что команда, которая работает по Agile, быстро адаптируется к изменениям в работе и новым вводным. Например, к новым требованиям заказчика, новым потребностям целевой аудитории, изменениям в рыночных условиях или другим неожиданным обстоятельствам.
Agile — прямая противоположность методологии Waterfall («Водопад»). Waterfall была доминирующей методологией управления проектами во второй половине XX века.
Суть Waterfall заключается в следующем. Команда проекта составляет детальное техническое задание и согласовывает его с заказчиком. Затем занимается разработкой строго по утверждённому плану и сдаёт заказчику готовый продукт.
В системе Agile всё устроено по-другому. Продукт стараются разработать как можно быстрее — так, чтобы начать им пользоваться почти сразу. Функции продукта меняют в ходе разработки. При этом команда проекта находится в постоянном контакте с заказчиком.
Как система ценностей Agile сформировалась в 2001 году. Её придумала группа разработчиков, которые поняли, что старые способы управления проектами не всегда работают хорошо. Так появился Agile-манифест — подробнее о нём говорим в следующем разделе.
Для управления проектами используют методологии. Так называют специальные стандарты, согласно которым применяют инструменты, ставят задачи и распределяют время команды. Одна из самых востребованных методологии в IT — Agile.
Что это такое расскажут разработчики DST Global
Само слово обозначает не только методологию, но и философию, которая лежит в ее основе. Говоря про Agile, зачастую имеют в виду набор ценностей, по которым должна работать команда.
Основной из этих ценностей, как и следует из названия, считается гибкость. Смысл Agile в том, чтобы с легкостью адаптироваться к быстро меняющимся задачам и новым условиям.
Этим Agile отличается от своего главного конкурента — классической методологии Waterfall. Последняя завоевала популярность в середине прошлого века и до сих пор применяется в менее динамичных сферах.
Waterfall предполагает четкое следование установленному плану. Сначала команда составляет задание, потом согласовывает его, а затем идет по плану разработки и предоставляет готовый продукт.
А в 2001 году группа разработчиков сформулировала Agile-манифест, который стал новым стандартом для управления проектами в IT. Его суть сводилась к тому, чтобы создать первую версию продукта как можно быстрее, а дорабатывать ее уже потом. В том числе, и внедряя новые функции, которые изначально не были запланировали.
Для этого команда по Agile работает в режиме небольших итераций. В каждой из них они выполняют установленные задачи, а затем проводят анализ результатов. По их итогам цели могут изменяться в следующей итерации.
Принципы Agile
Их всего четыре:
- Люди и взаимодействия важнее процессов и инструментов. Здесь речь идет о том, что старые подходы к разработке с жесткими рамками не подходят для создания инновационных IT-продуктов. Необходима большая гибкость и на первый план выходит не следование инструкциям, а более свободные отношения.
- Работающий продукт важнее документации. Это во многом связано с современной культурой стартапов. Чем раньше MVP-версия выйдет на рынок, тем лучше. Тратить время на создание идеально работающего приложения нет смысла, если непонятно, как на него отреагирует пользователь.
- Сотрудничество с заказчиком важнее условий договора. В IT не всегда можно заранее определить, каким будет продукт и предусмотреть все условия. Необходимо постоянно быть в диалоге заказчиком, чтобы совместно работать над изменениями в проекте.
- Готовность к изменениям важнее следования изначальному плану. Хороший продукт тот, который отвечает потребностям пользователя, а предсказать их заранее зачастую невозможно.
Сейчас эти принципы во многом кажутся банальностью, но в тот момент, когда их сформулировали, они были инновационными и во многом определили лицо современной разработки.
Манифест Agile
В 2001 году команда разработчиков из 17 человек подписала своего рода меморандум, в который вошло 12 главных принципов. Их до сих пор используют как базис Agile.
- Главная цель команды — удовлетворить истинные нужды заказчика, создавая продукт качественно и своевременно.
- Изменения требований к ПО в процессе работы — это нормально. Такая гибкость предоставляет конкурентные преимущества.
- Заказчик должен получать промежуточные версии продукта каждые несколько недель или месяцев.
- Разработчики и руководители команды должны работать рука об руку все время.
- Основа проекта — сотрудники с высоким уровнем мотивации. Им нужно предоставить все условия для выполнения работы.
- Передавать информацию в команде лучше всего путем личной беседы.
- Главный показатель качества работы — продукт, а не потраченное время.
- Гибкие процессы — основа непрерывного развития. Они помогают как на коротких, так и на длинных дистанциях.
- Для развития проекта важно работать как над технической стороной, так и над дизайном.
- Процессы должны быть максимально простыми, сотрудников нужно освободить от бесполезной работы.
- Микроменеджмент — зло. Над созданием качественных продуктов работают команды, которые умеют самоорганизовываться.
- Нужно постоянно оценивать эффективность и менять стратегию.
В чем уникальность Agile
Agile — целое семейство методологий. Но в основе всех них лежат общие принципы, которые выгодно отличаются от устаревших моделей, прежде всего, Waterfall.
В чем уникальность Agile:
- Предусматривается, что основная цель может измениться в течение работы над проектом. Такие изменения даже приветствуются, так как только с ними можно адаптироваться к смене условий в окружающем мире.
- Исходя из этого не стоит доводить планирование до совершенства, лучше потратить время команды на сам продукт.
- В разработке по Agile обязательно должны быть промежуточные этапы. По итогу каждого — появляется новая работоспособная версия продукта, пусть и без всех функций.
- Когда появляются новые требования, их нужно учитывать в следующей итерации.
- Руководитель должен непосредственно вникать в работу команды на всех этапах.
Основные методологии в Agile
Их еще называют фреймворками. Есть две самых популярных методологии на основе Agile, с которым сталкивается большинство команд в сфере IT.
Scrum
Это доминирующая методология в разработке программного обеспечения. В ее основе лежат итерации или спринты — небольшие отрезки времени, в течение которых команда должна предоставить результат.
Обычно спринт проходит за 2-4 недели. В конце происходит демо — демонстрация продукта или какой-то его функции.
В классическом виде эта методология предусматривает отсутствие руководителя. Есть только Scrum-мастер, который помогает команде в работе.
Основные инструменты:
- Планирование. По итогам прошедшего спринта Scrum-мастер с владельцем продукта или клиентом планируют следующую итерацию. Цель плана — получить следующую жизнеспособную версию продукта. Например, если в первом спринте создали главную страницу сайта, во втором целью будет форма для регистрации.
- Дейли-митинги. Это ежедневные встречи. Команды, работающие по Scrum, каждый день собираются на несколько минут, чтобы поделиться информацией. Обычно на дейли говорят, что сделали за прошлый день и что планируют сделать за этот, какие есть риски и ограничения у команды.
- Обзор спринта (демо). На нем команда презентует продукт, над которым работали весь спринт. А заказчик проверяет, совпадает ли это с критериями приемки, которые обозначили во время планирования.
- Ретро. Это анализ работы команды, которым занимаются ее члены. Сотрудники сами обозначают свои успехи и неудачи и намечают по итогам точки роста, чтобы в будущем работать эффективнее.
- Бэклог. Так называют список задач, которые нужно сделать. В процессе их можно добавлять или удалять. Есть бэклог для задач по спринту и отдельно по всему продукту.
- Ревью бэклога. Это проверка задач на актуальность и уточнение деталей их постановки по ходу работы.
Команда в этой методологии состоит из developers (инженеров) — сотрудников, которые непосредственно работают над задачей. Обычно их меняют только по окончанию проекта.
Scrum-мастер — менеджер и учитель методологии, который помогает команде решать проблемы и задает вектор развития. К его обязанностям относятся организационные функции. Он доносит точку зрения клиента до сотрудников.
Рroduct owner — это владелец продукта. Его роль выполняет представитель заказчика или непосредственно сам клиент.
Kanban
В основу этой методологии положили японскую систему с карточками, которую использовали на автомобильных производствах. Еще в 50-е годы там применяли систему досок, на которые вешали карточки со списком работ.
Сейчас Kanban знаком многим по программам — таск-трекерам, которые используются не только в IT. Это Trello или Jira, разработчики DST Global используют собственную разработку - DST CRM, CRM систему в которой уже встроен таск-трекер что позволяет еще более эффективней работать.
Основа методики в том, чтобы эффективно декомпозировать большую работу на несколько маленьких задач. Таким способом происходит управление проектами.
Все задачи, которые надо решить, появляются на доске и отправляются в одну из нескольких колонок. Член команды берет задачу в виде карточки в работу, а затем двигает ее по горизонтали из одной колонки в другую в зависимости от прогресса.
Это позволяет сразу всей команде видеть, как идет работа и на каком этапе находится задача.
Главная цель такого подхода — построить своеобразный конвейер. Работникам не нужно планировать задачи и выставлять приоритеты. У них есть список задач, которые они просто выполняют.
Число колонок на доске в Kanban может быть разным. Обычно они имеют статусы: «Создано», «В работе», «На согласовании», «Выполнено» и т.д.
На карточках всегда задают сроки. Предполагается, что член команды закрывает одну задачу и сразу берет другую.
В Kanban также есть регулярные встречи, которые называют каденциями: ежедневные, ежемесячные с обзором риском, квартальные с разработкой стратегии и несколько других.
Этапы управления проектами
В Agile работа над проектом происходит на основе спринтов. Это небольшие отрезки времени, в течение которых команда работает над продуктом. Есть несколько стандартных этапов:
- Планирование. Команда разрабатывает основную идею, обсуждают требования и составляют список задач. Ими наполняют бэклог. Затем задачи в бэклоге сортируют по приоритетам, самые актуальные и срочные идут на верх.
- Анализ. Команда рассматривает задачи, создает список ресурсов, которые потребуются, и каждый из сотрудников берет на себя их часть. Также во время анализа ставятся критерии оценки, которые нужно использовать, чтобы понять, что задача выполнена.
- Исполнение. Разработчики занимаются задачами, ежедневно обсуждают, что уже выполнено и чем они займутся сегодня. Регулярные совещания необходимы, чтобы все члены команды были в курсе происходящего на проекте.
- Тестирование. Когда работа выполнена, нужно проверить ее качество. Например, новая функция приложения должна работать в полной мере и не мешать работоспособности уже реализованных частей.
- Демо. Это демонстрация получившегося продукта заказчику. Ему, в свою очередь, необходимо оценить продукт. А команде — провести работу над ошибками, исходя из полученных замечаний.
Спринты повторяются до конца процесса разработки, когда финальную версию приложения отдают заказчику.
Плюсы Agile
Эта методология не зря стала одной из самых популярных на рынке. Вот список ее преимуществ.
- Гибкость
Основное качество Agile обеспечивает львиную долю преимуществ. В отличие от устаревших методик, этот подход дает возможность отвечать на вызовы рынка. За счет гибкости, он позволяет быстро менять продукт под новые требования и перестраиваться в процессе разработки.
- Больше шансов на успех
В классической методологии цели и задачи проекта принимают раз и навсегда. Это удобнее с точки зрения планирования, но повышает вероятность провала. С таким подходом полностью готовый продукт может оказаться невостребованным, если в его основе лежала изначально ложная гипотеза. Agile позволяет уйти от этого риска, так же как от вероятности создания приложения, которое не будет отвечать требованиям заказчика. За счет регулярных встреч и ежемесячного планирования проект проще «развернуть» на полпути и направить в нужное русло.
- Соблюдение сроков
Гибкий подход к разработке позволяет создать готовый продукт несмотря не на что. Это делается за счет адаптации, даже если одна задача заняла слишком много времени, разработчики могут убрать другой функционал и все равно выпустить готовый продукт вовремя.
- Эффективная работа в команде
Agile дает возможность максимально использовать потенциал сотрудников. Благодаря большей автономности они несут больше личной ответственности за проект и активнее в него вовлекаются.
- Реакция на перемены
Планирование небольшими спринтами позволяет не только вовремя изменять продукт, но и лучше работать с ошибками. В Agile баг, появившийся в одном цикле, обычно можно починить уже в следующем, не дожидаясь сдачи всего проекта.
- Минимизация бюрократии
Эта методология позволяет уменьшить количество отчетов, которые заставляют членов команды терять время и выгорать.
Минусы Agile
У этой методологии есть и свои недостатки.
- Отсутствие четкой структуры
С этим бывает тяжело работать заказчикам, которым важна определенность. В некоторых сферах, где применяют строгую регуляцию, внедрение Agile может быть затруднено.
- Обилие коммуникации
Методология предполагает, что представители заказчика тесно взаимодействуют с командой и активно погружаются в задачи. Это само по себе требует не только времени, но и квалификации. Хотя и положительно влияет на качество продукта.
- Критическая важность сотрудников
В команде, работающей по Agile, сравнительно сложно поменять сотрудника. Ему нужно будет долго входить в курс дела, изучая произошедшее во всех предыдущих спринтах.
- Проблемы внедрения
Если команда раньше не работала по Agile, то сходу внедрить методологию может быть проблематично. Зачастую для этого требуется привлекать сторонних консультантов. Без них многие команды вводят отдельные части методологии, которые не работают по отдельности.
Где используют Agile
Эта методология по мнению специалистов DST Global больше всего подходит для стартапов, небольших проектов и IT-компаний. Главноологию целиком.
Кроме IT, Agile используют в маркетинге и различных творческих сферах. Эта методология не работает в предсказуемых и типовых проектах, в которых и цель, и пути ее достижения точно определены и существуют в строгих рамках.
Если на этапе планирования можно четко описать результат и определить список работ, то использовать Agile обычно не стоит в них — высокий уровень неопределенности в требованиях к продукту.
В таких проектах методология позволяет использовать все плюсы и нивелировать минусы. В других компаниях Agile применяют с оговорками, так как его недостатки выходят на первый план.
В целом этот подход изначально применялся не ко всем проектам, а только к сфере IT. В настоящее время по Agile работают большинство лидеров рынка, включая Google, Adobe и Microsoft.
Но его отдельные элементы используют практически все команды разработчиков, а многие внедряют метод
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Ижевск, ул. Воткинское шоссе, д. 170 Е, Технопарк Нобель, офис 1117
Задать вопрос по почте
Те кто называют agile методологией чаще всего либо не понимают что это, либо пытаются навязать свои услуги.
Например ваша фраза что на всех проектах. Нет не на всех. Многие компании которые ведут проекты по разработке могут жить с agile но при проектах связанных с масштабированием проваливаются с такой логикой.
Agile как набор правил очень крутой для разработчиков чего угодно. Но это не решение всех бед. Иначе бы Siemens и многие крупные немецкие разработчики тоже бы хотели в гибкость, но нет.
Scrum уже методология. Но не особо эффективная для больших команд. Придумана менеджерами, ее основной идеей является переложить работу менеджера проекта по общению с менеджером продукта/клиентом на команду разработчиков. Ведет к убыткам компании не оправданным расходам и увеличению срока разработки. Чем больше команда тем больше потерь для компании.
Канбан это тоже не методология, это тупо доска.
Waterfall еще одна методология, эффективная по использованию времени разработчиков. Но слишком жесткая, делает развитие продуктов не удобным для менеджеров.
Успешные и эффективные команды используют комбинации подходов. Мы например используем. scrum + kanban на этапе общения между продактом и проджектом. Когда они согласовывают какую то часть, это фиксируется и проджект передает ее тимлиду, а отдел разработки уже работает по небольшим проектам в формате waterfall, несколько waterfall проектов в рамках одного продукта могут идти паралельно. Как итог, разработчики вообще не ходят на совещания, привлекать их к ним запрещено, они посвящают 100% времени написанию кода. А менеджеры получают необходимую им гибкость для развития продукта. Не уверен как это называется но это близко к Scrum-sashimi.
Последний вариант очень эффективен, но требует больших затрат, для разработки системы которая сможет обеспечить этот процесс. Нам пришлось написать свою систему с нуля. Думаю можно, законфигурировать для этих целей какой то конструктор. Но ограничения все равно останутся.