Blog Post

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

Но это не значит, что гибкие подходы есть смысл применять везде без ограничений. Во-первых, помимо ценностей, в Agile-манифесте есть также 12 принципов, которые уточняют и дополняют ценности. Чтобы клиенты были довольны, им нужен именно работающий продукт. Чтобы ускорить процесс разработки, люди также должны взаимодействовать напрямую (без посредников в виде документов или других людей), активно общаться между собой лично, а не письменно. Правда, в современном бизнесе общение часто вынуждено переходить в онлайн.

Нужные для запуска проекта задачи формируются в бэклог – список дел. При этом заказчику отводится главная роль, именно он задает вид и определяет функционал работы. Scrum-мастер ответственен за организацию встреч и обмен посланиями между участниками команды. Легко заметить, что многие принципы Agile непосредственно относятся к разработке ПО. Именно из этого исходили многие участники исходного Agile Alliance, именно на этом делается акцент в манифесте Agile. Однако принципы Agile применимы и к проектам в других областях и отраслях, поэтому давайте рассмотрим это подробнее.

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

Сотрудничество С Заказчиком Важнее Согласований Условий Контракта

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

• Подробнее об этапах управления проектом по этой методологии рассказываем ниже.
• Манифест Agile подписали 17 человек — будущий Agile Alliance.
• Хорошие инструменты и процессы тоже важны, но главное — сплочённость команды и способность эффективно общаться и работать друг с другом.
• Если в начале проекта команда может чётко описать его результат и составить план необходимых работ, гибкие методологии не подойдут.
• При этом команда проекта находится в постоянном контакте с заказчиком.
• Одно из ключевых ограничений Agile кроется в словах «для разработки новых продуктов».

Эту модель лучше всего использовать в регулируемых отраслях, где допустимые отклонения минимальны. «11–13 февраля 2001 года на горнолыжном курорте в штате Юта встретились семнадцать разработчиков — поговорить, покататься на лыжах, расслабиться и обсудить дела. Сейчас трудно было бы найти более крупное собрание организационных анархистов, поэтому то, что вышло из этой встречи, было символичным — манифест гибкой разработки программного обеспечения». Каскадная модель предполагает, что команда проекта составляет детальное техническое задание — какой продукт нужно получить и каким путём — и согласовывает его с заказчиком. Затем занимается разработкой строго по утверждённому плану и сдаёт заказчику готовый продукт. Будет проще понять, в чём суть Agile, если сравнить её с противоположной методологией управления проектами — Waterfall (каскадная модель или «Водопад»).

Что Не Относится К Практикам Agile

Участник команды берёт задачу, перемещает карточку по доске от одной колонки к другой, и вся команда видит актуальный статус этой задачи. Проект разбивают на итерации (спринты) — промежутки времени, в которые команда разрабатывает продукт поэтапно. Agile — прямая противоположность методологии Waterfall («Водопад»).

А чтобы запомнить их лучше, скачайте плакат с наглядным представлением ценностей и принципов Agile. Электронная книга в открытом доступе, при этом она отлично иллюстрирована примерами и содержит подробное сравнение Скрама с Канбаном. https://deveducation.com/ Особенно полезна будет тимлидам, скрам-мастерам и всем, кто управляет кем-либо или чем-либо на уровне отдельной команды, особенно «айтишной». Agile — это уже давно не только про разработку программного обеспечения.

Освоите метод описания функций продукта, которыми пользуются клиенты. Выше мы описали два популярных метода философии Agile — Scrum и Kanban. Однако есть ещё и другие методологии — для начала вам нужно изучить каждый метод и выбрать тот, что ближе вам и требованиям вашей компании. Кажется, что суть гибкого подхода — попробовать всё, что подворачивается или приходит в голову, но это не так.

Преимущества Использования Agile

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

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

Гибкие методологии лучше всего подходят для проектов, в которых требуется быстро реагировать на изменения и дорабатывать продукт в ходе выполнения. В случаях, когда задачи agile-философия проекта важно решать последовательно и строго по первоначальному плану, Agile лучше не использовать. Она возникла в сфере IT и сначала использовалась для разработки ПО.

Сравнение Методики Agile И Каскадной Модели

В погоне за этими идеалами вы рискуете обнаружить, что ваша команда создала нечто совершенно отличное от задуманного. Может даже показаться, что у вас вообще нет определенного направления, потому что вы гоняетесь за новыми возможностями и идете на поводу у отзывов клиентов, уводящих вас в новых направлениях. Из-за таких противоречивых результатов не все команды и компании могут работать по методике Agile. Однако команды, которые решают преодолеть эти препятствия, часто обнаруживают, что в итоге могут предложить своим клиентам более качественный продукт. Таким образом, методология Scrum позволяет команде быстро реагировать на изменения, постоянно взаимодействовать с заказчиком, учитывать новые требования и создавать актуальный продукт. Её придумала группа разработчиков, которые поняли, что старые способы управления проектами не всегда работают хорошо.

Agile-манифест: Главные Ценности И Принципы Agile

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

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

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

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

Таким организациям помогают, в частности, подходы SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum), а также нехитрая практика Scrum of Scrums. Это — тройка наиболее популярных подходов к масштабированию Agile, как показывает то же исследование Agile в России. Как выбрать методологию проекта, которая максимизирует шансы на успешную реализацию продукта?

Чтобы добиться успеха, необходимо добавить новые роли, такие как scrum-мастер, и пересмотреть расписание всех участников в соответствии с заданной периодичностью собраний. У многих команд нет ресурсов для найма новых сотрудников и времени для новых собраний. Если коллективу не удастся полностью перестроиться, то его участники, скорее всего, не смогут реализовать преимущества Scrum. Кроме того, не все команды способны выдавать результат с требуемой частотой. Это приводит к снижению качества, из-за чего многие команды все больше продлевают свои спринты и в конце концов возвращаются к каскадной модели.