Внедрение культуры Agile

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

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

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

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

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

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

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

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

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

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

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

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

Совместное поиск команд по возможности

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

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

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

Работа с балансировкой нагрузки, а не люди

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

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

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

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

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

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

Следующие шаги

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

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

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