Принятие культуры Agile

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

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

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

Расписание и ритм

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

Выберите длину спринта, которая подходит для культуры вашей организации, продуктов и желания предоставлять обновления. Например, отдел средств разработчиков в Корпорации Майкрософт (примерно 6000 человек) работает в трехнедельных спринтах. Команда руководства не выбрала эту длину спринта; это решение было получено на основе прямой обратной связи от инженерных команд. Весь отдел работает по трехнедельному графику спринтов. Спринты с тех пор стали пульсом организации. Теперь каждая команда марширует под один ритм.

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

Культура доставки

Питер Provost, главный руководитель групповой программы в Корпорации Майкрософт, сказал: "Вы не можете обмануть доставку". Простота и правда этого заявления является краеугольным камнем гибкой культуры. Питер имеет в виду, что выпуск вашего программного обеспечения научит вас тому, что вы не сможете понять, если действительно не выпускаете свое программное обеспечение.

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

Работоспособные команды

Нет рецепта для идеальной команды Agile. Однако некоторые ключевые характеристики значительно упрощают достижение успеха.

Распределяйте команды совместно, если возможно

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

Сохранение групп без изменений в течение разумного периода времени

Разрешите командам мастерить искусство создания программного обеспечения вместе. Когда команды борются, любая химия, которую они разработали, нарушается. Иногда это подходит для реорганизации, но команды обычно более продуктивны, когда они получают время, чтобы узнать, как работать вместе. В качестве руководства старайтесь сохранить команды нетронутыми по крайней мере на 12 месяцев.

Балансируйте объём работы, а не людей

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

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

Пусть команды имеют собственные области функций, а не слои архитектуры

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

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

У команд функций нет этих проблем. Четко определены владение и подотчетность. Может найтись место для некоторых команд, основанных на архитектуре. Тем не менее, вертикально ориентированные команды более эффективны.

Дальнейшие шаги

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

Корпорация Майкрософт является одной из крупнейших в мире компаний Agile. Узнайте больше о том, как Майкрософт приняла культуру Agile для планирования DevOps.

Узнайте, как Azure DevOps позволяет командам внедрять и масштабировать культуру Agile.