Управление проектами довольно сложный процесс. Чтобы не выстраивать его каждый раз с нуля, были разработаны специальные методологии. Они представляют собой набор стандартов, регламентирующих применение инструментов, распределение рабочего времени, определение задач и т.д. Среди разработчиков популярностью пользуется сразу несколько методологий, объединенных в одно семейство и получившее название Agile.
Что такое Agile
Agile – это один из подходов к управлению проектами, ориентированными на создание программного обеспечения. Чаще всего он используется в командах с ограниченным числом разработчиков.
Под термином «Agile» понимается не только совокупность гибких методологий, но и философия, которой следует команда. По сути, это набор ценностей и принципов, на которых строится вся работа. Гибкость подхода объясняется характером рабочего процесса. Он разбивается на несколько итераций, длительностью не больше 2-3 недель. Каждая из них содержит пул задач, куда входит изучение аналитики, проектирование, разработка и тестирование. По завершении итерации специалисты анализируют полученные результаты и выбирают новые приоритеты.
Все началось в 2001 году, когда в США группой разработчиков был составлен и подписан манифест об использовании современных подходов к разработке. В то время IT-сфера переживала кризис, поскольку создавать передовые информационные продукты по устаревшим методологиям было просто невозможно. В итоге, новые принципы, о которых говорилось в манифесте, стали основой для Agile.
Принципы Agile
Содержание манифеста Agile находится в открытом доступе. В нем не описываются конкретные подходы к разработке или рекомендуемые инструменты. Документ содержит общие принципы, которые применяются не только при создании ПО, но и в других бизнес-сферах. Звучат они следующим образом:
- создаваемый продукт направлен на закрытие потребностей клиента. Заказчик должен получать качественное ПО и своевременные обновления;
- процесс разработки должен быть гибким, что позволит сделать продукт более конкурентоспособным на рынке;
- доставка программного обеспечения клиенту не должна превышать 16 недель;
- основу проекта составляют заинтересованные и мотивированные специалисты. Для них должны быть созданы все необходимые условия;
- главный показатель прогресса – качественное ПО. Все остальные критерии – второстепенны;
- залог успеха – слаженная работа разработчиков и руководителей;
- хороший продукт выделяет качественный дизайн и корректно работающий функционал;
- лучший способ коммуникации – личная беседа;
- сложную работу стоит оптимизировать, а все лишнее по возможности исключать;
- гибкость – ключ к устойчивому развитию. Это позволяет эффективно работать как в краткосрочной, так и долгосрочной перспективе;
- анализ результатов и работа над ошибками – обязательная часть рабочего процесса;
- микроменеджмент вредит команде, предпочтение стоит отдавать свободному управлению.
На основе перечисленных выше принципов сформировались ключевые ценности Agile:
- сотрудничество с клиентом превалирует над контрактом и его условиями;
- взаимодействие в команде важнее используемых инструментов и выстроенных процессов;
- документация второстепенна, главное – создать работающий продукт;
- если необходимы изменения, изначальный план может корректироваться.
Сегодня эти принципы не вызывают никакого удивления и кажутся логичными. Однако еще 20 лет назад они буквально перевернули представление о разработке. Тогда следили за выполнением каждого пункта в договоре, планировали свою работу на несколько лет вперед и много времени уделяли ведению подробной документации.
Отличия от других методологий
Говоря о различиях, нужно помнить тот факт, что Agile является семейством методологий, для которого характерны лишь общие принципы. В отдельности каждая методология этого семейства имеет свои подходы к организации рабочего процесса и пользуется разными инструментами. Поэтому прямое сравнение не совсем уместно.
Впрочем, если говорить об основополагающих принципах, то Agile имеет целый ряд отличий от классических методологий с более строгим подходом:
- сбор и изучение аналитики должны занимать меньше времени, чем разработка. Главная задача – сделать максимально качественный продукт;
- в изменениях нет ничего плохого, более того они способствуют созданию актуального ПО. Если процесс разработки длится несколько месяцев, требования заказчика могут измениться и к этому нужно быть готовым;
- сроки сдачи проекта должны быть гибкие и учитывают возможные задержки, связанные с внесением изменений;
- результатом каждой итерации, на которые разбивается рабочий процесс, должен быть продукт, пусть и недоработанный;
- если возникают новые требования, их нужно учитывать и выполнять в следующих итерациях;
- процесс создания продукта подразумевает тесное сотрудничество команды и руководителя.
На этом отличия не заканчиваются, но они уже относятся к инструментам и практикам, применимым на проектах.
Преимущества и недостатки
Главное достоинство заключается в гибкости и возможности быстро вносить изменения. Это позволяет учитывать требования клиента, которые могут появиться после заключения договора. Более того, следуя принципам Agile, команда может комфортно себя чувствовать в конкурентной среде и не бояться неопределенности.
К другим плюсам относят:
- минимизация рисков – регулярное тестирование, общение с клиентом и аналитика помогают свести к минимуму возможность провала. Если что-то идет не по плану, разработчики быстро вносят изменения и тестируют исправленный вариант;
- вовлеченность разработчиков – поскольку команда постоянно взаимодействует с руководством и ее работа во многом строится на принципе самоуправления, сотрудники работают эффективнее и понимают какое влияние оказывают на проект;
- адаптация сроков – если разработка какой-то функции занимает много времени, дату сдачи проекта можно перенести. В случаях, когда это невозможно, от реализации фичи можно отказаться;
- оперативное устранение проблем – в случае появления ошибок и багов их можно быстро исправить. Для этого не нужно вносить глобальные изменения в проект или надолго сдвигать сроки его сдачи;
- минимизация рутинных процессов – составление отчетов и написание документации не занимает у разработчиков много времени.
У Agile есть и слабые стороны:
- проект не имеет четкой структуры – созданный по итогу продукт может значительно отличаться от того, что предполагалось сделать в начале. Для некоторых заказчиков это может стать серьёзным недостатком, поскольку для них важно следование заранее согласованному плану;
- работа с мелочами – желание усовершенствовать и доработать продукт может привести к смещению фокуса с главной цели проекта;
- постоянное общение с командой – клиент регулярно взаимодействует с разработчиками, обновляя перечень требований и оценивая промежуточные результаты;
- командно-ориентированный процесс – во время работы над проектом довольно сложно заменить руководителя или разработчика, поскольку ему придется вникнуть и разобраться во всех предыдущих итерациях рабочего процесса;
- проблемы с внедрением – перейти со строгой методологии на Agile бывает проблематично. Обычно в таких ситуациях приходится нанимать отдельного специалиста, у которого есть богатый опыт работы с гибкими методологиями. При этом переход может затянуться.
Где применяются гибкие методологии
Agile идеально подходит для реализации небольших проектов и стартапов, поскольку большинство минусов нивелируются. Клиент сам заинтересован во взаимодействии с командой, структура имеет второстепенное значение, а процесс внедрения проходит быстрее. Если же проект крупный и разработка занимает несколько месяцев, то недостатки становятся более заметными. Они мешают созданию продукта, полностью соответствующего требованиям заказчика.
Изначально Agile предполагалось использовать в командах разработки программного обеспечения, однако со временем он распространился и на другие сферы бизнеса. Сегодня им пользуются такие компании как: Microsoft, Adobe, Google, Spotify и другие IT-гиганты. При этом он все также популярен в среде стартапов.
Agile используют не только IT-компании. Некоторые принципы применяются в самых разных областях. Иногда работа полностью выстраивается в соответствии с гибкой методологией или ее вариациями, которые стали признанными стандартами во многих современных проектах.
Методы и технологии управления проектами по Agile
Agile содержит несколько гибких проектных методологий. Довольно часто их называют методами управления. Среди них наиболее популярны Kanban и Scrum. В том числе, их используют многие российские компании и стартапы.
Scrum
Работа над проектом начинается с формирования списка требований к будущему продукту. Обычно за это отвечает заказчик, который передает его команде разработчиков. Они анализируют предстоящую работу и делят ее на этапы, которые еще называют спринтами. Их длина не должна превышать 3-4 недель.
У каждого спринта есть свои цели и задачи. Для их достижения необходимо выполнить определенный перечень работ, которые прописываются в бэклоге проекта. Это своего рода список этапов, обязательных к выполнению. На его основе формируются бэклоги для отдельных спринтов.
По завершении спринта команда должна представить рабочий продукт. Он может содержать не все функции, иметь незаконченный интерфейс, но уже быть готовым к использованию. Перед началом нового спринта для него создается бэклог, куда входят обновленные цели и задачи.
Чтобы в процессе выполнения задач команда не отклонялась от главной цели, используются специальные события. Это может быть приоритизация, планирование или взаимодействие с бэклогом. Отвечает за это отдельный специалист – scrum-мастер. Его задача – помочь разработчикам спланировать работу. Более подробно об этом написано в Scrum-гайде, который является основным документом методологии.
Scrum показывает хорошие результаты в условиях неопределенности, однако плохо переносит внешнее давление. Команда должна самостоятельно управлять всем, что происходит на каждом из этапов. Если появляется тот, кто также может влиять на конечный результат, метод перестает работать.
Отличительной особенностью от других подобных методологий является возможность работы с отчетами и квартальным планированием. Scrum позволяет устанавливать четкие сроки выполнения задач. Несмотря на это, целиком его используют редко, предпочитая брать отдельные принципы. Все потому, что методология требовательна к инструментам и принципам. Если чего-то не хватит, Scrum не даст нужного результата.
Kanban
Данная методология имеет один инструмент, который пользуется широкой популярностью у многих компаний – Kanban-доска. Она позволяет в наглядной форме представить задачи команды. Однако сама методология намного объемнее и шире. В ее основу легли следующие принципы:
- правила достижения целей должны быть максимально простыми и понятными для всех участников;
- чтобы лучше понимать рабочий процесс, нужно использовать петли обратной связи;
- для визуализации задач нужно использовать Kanban-доску;
- процессы не должны быть перегружены, поскольку большое количество задач ведет к снижению эффективности;
- потоком работы нужно управлять, для этого необходимо отслеживать задачи, появляющиеся на доске;
- по возможности рабочие процессы должны быть максимально оптимизированы.
Kanban отличается от Scrum более гибким подходом. Он дает возможность постепенно переделывать и улучшать процессы, которые были сформированы в компании. Иногда его получается совмещать с другими методологиями. Однако нужно понимать, что доска и расписанные на ней задачи – это не Kanban. Чтобы метод начал работать важно соблюдать и другие принципы.