Гибкая методология — что это?
С начала 2000-х годов гибкая методология превратилась в один из основных подходов к управлению проектами во многих технологических организациях. Большинство команд разработчиков программного обеспечения применяют сегодня гибкую методологию в той или иной форме, а ее элементы используются в различных условиях работы. Популярность слова «гибкий» возрастает, поскольку сегодня авторитетные лидеры начинают говорить о необходимости быть более гибкими в мире бизнеса. Но что на самом деле означает использование методологии гибкого управления проектами в вашей компании?
Гибкая методология — это процесс управления проектами, который основан на разделении проектов на более мелкие задачи и этапы. Такое дробление позволяет командам, применяющим гибкую методологию, учитывать отзывы участников проекта, переоценивать результаты работы и применять итеративный подход на каждом этапе процесса. Один из наиболее популярных подходов к применению гибкой методологии заключается в разделении проекта на короткие этапы разработки, которые называются спринтами. Это обеспечивает команде возможность быстро выполнять работу и регулярно анализировать результаты с руководством и участниками проекта при планировании спринтов и проведении ежедневных скрамов. По результатам анализа команда и участники проекта могут либо продолжить двигаться в существующем направлении, либо пересмотреть планы очередных спринтов. По сравнению с традиционными подходами к управлению проектами, в гибкой методологии основными приоритетами являются оперативность, гибкость, командная работа и потребности участников проекта.
Как возникла гибкая методология?
Идея гибкой методологии была предложена в начале 2000-х годов группой разработчиков программного обеспечения, которые сформулировали четыре основных принципа этой методики:
Люди и взаимодействие важнее процессов и инструментов.
Работающее программное обеспечение важнее полной документации.
Сотрудничество с клиентом важнее обсуждения условий контракта.
Реагирование на изменения важнее следования первоначальному плану.
Эти принципы, закрепленные в Манифесте гибкой разработки программного обеспечения (Agile Manifesto), выпущенном в 2001 году, определили методологию гибкого управления проектами и трансформировали индустрию разработки программного обеспечения.
До этого момента наиболее целесообразным подходом к управлению проектами по разработке программного обеспечения считалась каскадная модель. Эта модель, которая появилась в 1970-х годах, в начале считалась новаторской идеей, но к 2000-м годам она стала тяжеловесной. Принципиальным является то, что данная модель требовала огромных объемов документации и существенного планирования до начала проектных работ. После фактического начала работы выполнялись в строгом соответствии с планом отдельными и зачастую разрозненными командами, что затрудняло адаптацию проекта в случае возникновения проблем или необходимости изменений. По сравнению с этой моделью команды, применяющие гибкую методологию в разработке, могли приступать к реализации проекта быстрее, адаптироваться к возникающим проблемам и напрямую взаимодействовать с заказчиками и участниками проектов при планировании.
Почему гибкое управление проектами настолько популярно?
По сравнению с каскадной моделью преимущества гибкой методологии были очевидны для технологических компаний в 2000-х годах. Преимущества гибкой методологии не ограничены только миром программирования, поскольку этот подход используется в рабочих процессах целого ряда других отраслей. Итак, что делает гибкую методологию столь привлекательной для многочисленных руководителей проектов и руководителей компаний?
Адаптируемость
По сути, гибкая методология заключается в возможности реагировать на изменение целей, условий или технологических моментов. Принципы гибкой методологии требуют интеграции возможности анализа текущих результатов работы, сроков и проектных требований. Если один из участников проекта захочет изменить объем или направление проекта, благодаря использованию скрам-методов и планированию спринтов команда сможет изменить курс. Если кто-то из участников команды столкнется с проблемой в текущей задаче или части проекта, график работ можно скорректировать для оперативного устранения проблемы. Вместо разработки того, что больше не соответствует потребностям клиента, гибкая методология позволяет оперативно менять курс.
Согласование позиций участников проекта
Благодаря такому уровню манёвренности, гибкая методология обеспечивает возможность быть в курсе постоянно меняющихся требований и потребностей клиентов и заказчиков. В любом проекте цели и объем работ, изначально согласованные между командой и участниками проекта, редко остаются неизменными. У вашего клиента могут возникнуть дополнительные объемы работ и потребности, которые он не мог предвидеть, либо со временем могут измениться требования конечного потребителя. Независимо от причины изменения планов участниками проекта, гибкая методология позволяет более оперативно реагировать на такие изменения, что, в свою очередь, обеспечивает возможность быстро выполнять работу и не допускать отставания. Это гарантирует соответствие результатов постоянно растущим требованиям клиентов, независимо от их расхождения с тем, что было в начале проекта.
Скорость
Разумеется, гибкая методология называлась бы иначе, если бы она не была гибкой по своей сути. Дробление задач команды и определение более коротких и определенных сроков исполнения в гибкой методологии позволяет команде сосредоточиться и выполнять работу быстрее. Иными словами, это означает возможность ускорения вывода продукции на рынок или ее сдачи клиентам. Именно такое сочетание скорости и адаптируемости делает гибкую методологию столь привлекательной для компаний всех видов. При возникновении проблем команда имеет возможность быстро изменить курс для их устранения. Не нужно тратить время на возврат к исходным планам или документам: проблема поднимается в скраме, планируются мероприятия и проблема решается. Таким образом, гибкая методология помогает командам сосредоточиться на конкретных задачах и выполнять их вовремя.
Какие трудности связаны с гибким подходом?
Гибкая методология не идеальна. Как и любая модель управления проектами, она имеет свои преимущества и ограничения. Как и в случае каскадной модели, использование гибкой методологии связано с рядом недостатков и проблем, которые, если их не решить, будут мешать в работе.
Управление объемом работ
При возможности оперативно реагировать на проблемы и изменения в процессе очень важно контролировать общее состояние проекта и объем работ. Гибкая методология позволяет менять планы и работать оперативно, но быстрое переключение между задачами может помешать вам следить за ходом выполнения работ в целом. Даже если команда работает эффективно, вы можете выйти за рамки бюджета или времени, если не будете контролировать выполнение перечней задач, которые формулируются при планировании спринтов. Команды и руководители проектов, которые работают по гибкой методологии, должны следить за исполнением проектных объемов и плана-графика, чтобы объем работ не вышел из под контроля.
Календарное планирование
При использовании Agile-процесса от команды может ускользнуть не только объем работ. Когда команды используют планирование спринта, они могут гибко планировать свои графики и приоритеты в зависимости от текущих потребностей. Однако как только члены команды начинают перемещаться и решать новые задачи или оказывать поддержку в решении проблем, график должен гибко адаптироваться, чтобы учитывать это. Если вы придерживаетесь строгого графика, вам необходимо убедиться, что планирование спринта по-прежнему укладывается в эти временные рамки.
Помимо этого, участники самоорганизующихся рабочих групп могут переключаться между задачами по мере необходимости, но в конечном итоге они должны возвращаться к тем задачам, за которые они отвечают. В этом случае руководители проектов, реализуемых с помощью гибкого подхода, должны проконтролировать состояние всех выполняемых командой задач и убедиться, что ничего не упущено из виду. Иными словами, то, что считалось выполненным, может оказаться забытым в ходе многочисленных интенсивных спринтов.
Общение
При гибком подходе уделение приоритетного внимания командной работе и быстрому реагированию фактически означает, что обмен информацией имеет первостепенное значение. Участники рабочей группы должны иметь возможность оперативно сообщать о ходе работ, выявлении проблем и необходимости получения помощи. Такое взаимодействие должно быть организовано на регулярной основе между всеми участниками команды, а полученная в результате информация — использоваться непосредственно в планировании. Очень важно регулярно получать данные от других участников проекта, поскольку без информации о том, что нужно другим участникам, невозможно внести изменения в план.
Как реализуется гибкий процесс
Если вы хотите использовать методологию гибкого управления проектами в своей рабочей группе, существует много испытанных и проверенных стратегий и практических решений, среди которых наиболее распространены спринты и скрамы. Разумеется, использование соответствующих программ и инструментов для управления проектами также может решить судьбу методологии гибкого планирования. Ниже приведены некоторые из самых важных технологий и методов внедрения и применения гибкой методологии.
Контролируйте ход выполнения задач
Чтобы понять, какую работу необходимо выполнить на следующем коротком участке, вам нужно знать, что уже выполнено. Таким образом, ваша команда должна уметь отслеживать ход своей работы. Уточнение незавершенных заданий или оптимизация работы с ними — это метод, который обычно используется Agile-командами. Он направлен на обеспечение прозрачности для команд, расстановку приоритетов в невыполненных задачах и обеспечение готовности задач, стоящих первыми в списке, к выполнению. Скрам-команды часто используют доски планирования или Канбан-доски для отслеживания задач, но многие выбирают программное обеспечение для управления задачами.
Организуйте регулярную и эффективную коммуникацию
Правильная коммуникация является краеугольным камнем любой гибкой методологии управления проектами. Поэтому предоставление вашей команде средств и возможностей для регулярного общения имеет первостепенное значение. Хотя спринты обычно проводятся рывками по 2–3 недели, многие скрам-мастера ежедневно проводят «стендапы» со своими командами, чтобы быть в курсе прогресса изо дня в день. Хотя конкретный темп общения зависит от вас и вашей команды, использование инструментов может помочь вам облегчить эти обсуждения.
Интеграция с приложениями для чата и видеоконференций в режиме реального времени также поможет вам проводить командные совещания и сессии планирования. Вы можете делиться файлами и начинать обсуждения прямо в Dropbox, сокращая время, затрачиваемое на переключение между вкладками и контекстом.
Сделайте паузу для анализа
При гибкой методологии возникает искушение перескакивать от одной задачи к другой, отмечая их в списке по мере перехода. Но в гибких процессах очень важно выделять время для анализа и разбора спринтов, чтобы не допустить зашоренности команды. Выделение времени для анализа по завершении каждого спринта дает участникам команды возможность проанализировать проделанную работу и расставить приоритеты.
Быстрый критический анализ также следует использовать для изучения того, как ваше планирование повлияло на проект на протяжении его жизненного цикла. В этом случае отслеживание и ведение надлежащих записей вашей работы имеет решающее значение. В Dropbox есть встроенные функции контроля версий, которые помогают вам проверять файлы вашей команды на каждом этапе разработки. Функцию также можно использовать во время коротких совещаний, чтобы отслеживать ход работы каждого участника команды или откатывать изменения, которые могли не быть одобрены.
Работа по гибкой методологии
Методология Agile оказала трансформационное воздействие на многие предприятия и руководителей с точки зрения их работы и достигнутого ими успеха. С 2000-х годов он стал движущей силой процессов разработки программного обеспечения, и его элементы проникли повсеместно на рынок труда. Независимо от того, планируете ли вы завтра утром собраться на командное совещание или просто продолжить переписку по электронной почте, похоже,методология Agile никуда не денется.
