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

Тем не менее, Agile (в частности, Scrum) вполне подходит и для крупных компаний, однако при его внедрении имеет смысл учитывать ряд нюансов, о которых я хотел бы рассказать в этой статье.

1. Мифы и реальность

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

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

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

Другим примером является сборка потенциально продаваемого инкремента продукта в результате работы всех команд в рамках одной итерации. Залогом успешной кросс-командной сборки являются:

· единое понимание критериев готовности продукта во всей организации для всех пользовательских историй, элементов функциональности и дефектов;

· проведение регулярных Scrum-of-Scrums встреч для обзора спринтов (спринт — итерация, в ходе которой создаётся функциональный рост программного обеспечения. — Прим. ред.), синхронизации действий команд, выявления и устранения межкомандных зависимостей и т. п. На такого плана встречи делегируется представитель каждой Scrum-команды.

2. Привычный водопад

Даже четкое понимание основ Agile не всегда спасает от попыток модифицировать стандартные правила Scrum, совместив их с каскадной моделью разработки ПО.

Такой подход опасен вдвойне, так как в итоге плюсы обеих методологий взаимоуничтожаются, оставляя открытое пространство для «буйства» негативных эффектов.

При использовании Agile гибкость достигается путем непрерывного анализа требований, проектирования, разработки/интеграции и тестирования. Границы между этими активностями размыты, поэтому любая попытка разбить проект на «водопадные» фазы приведет к беде.

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

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

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

3. Ни грамма магии

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

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

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

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

4. Люди превыше всего

Scrum — это не инструкция по разработке ПО, а скорее набор рекомендаций для организации рабочего процесса и повышения эффективности команды. Scrum-команды организованы так, чтобы каждый их участник смог достичь наибольшей продуктивности. Этому способствует ряд факторов:

  • организация работы: работа в одной команде и только в ней, бесперебойная работа во время спринта в спокойном ритме без сверхурочных;
  • взаимодействие: поддержка прозрачности совместной работы всех членов команды в рамках взаимных обязательств может осуществляться разными средствами — от решений для мгновенного обмена сообщений, серверов Wiki и хранилищ документов для обмена информацией до веб-камер и общих десктопов для демонстрации работы по продукту, не говоря уже об общем репозитории кода и т. п.;
  • корпоративное обучение: одного энтузиазма недостаточно, чтобы начать эффективно работать в Agile-среде, необходимо постоянное и последовательное корпоративное обучение на начальном и последующем уровнях внедрения Agile;
  • техническое совершенство: фокус на скорости доставки функциональности не должен идти в ущерб качеству написанного кода. Важно убедиться, что все члены Scrum-команд владеют такими техническими практиками и инструментами (или, по крайней мере, ознакомились с ними), как разработка через тестирование (Test Driven Development), взаимные проверки кода (Peer Review), непрерывная интеграция и автоматизация тестирования.

Манифест гибкой разработки программного обеспечения (The Manifesto for Agile Software Development) начинается с того, что люди и их взаимодействие важнее процессов и инструментов. То есть люди и коммуникации в команде крайне важны. Но заказчики — тоже люди, и забывать о них не следует. Интенсивное участие заказчика в разработке продукта влечет необходимость подстраиваться под его текущее настроение, желания и потребности. При первых признаках фрустрации клиента (да, такое тоже бывает) команда может смягчить ситуацию, например, перейдя от довольно формальной и детализированной переписки к формату «вопрос-ответ». Это позволит сохранить и темп разработки, и вовлеченность заказчика, снизив «градус эмоций». В общем, никогда не забывайте о людях. В конце концов, производительность труда и удовлетворенность клиентов являются залогом успеха Agile.

Автор статьи — сертифицированный Scrum Master, отвечает за развитие отношений с ключевыми клиентами в компании Itransition.

Версия для печати