Русский
Русский
English
Статистика
Реклама

Перевод Почему использовать Agile не достаточно

Перевод материала подготовлен в рамках курса "Enterprise Architect".

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


Использовать agile это амбициозно, но быть agile воистину трансформативно. С чего лучше начать? Нет однозначного правильного ответа. Но обо всем по порядку. Какая разница между использовать и быть agile?

Использовать Agile

Agile это не методология; это образ мышления, который вы можете применить в своей жизни и в своем способе ведения бизнеса. Agile широко распространено в индустрии разработки программного обеспечения, но любая отрасль может использовать и извлекать выгоду из образа мышления agile. Для меня использование Agile это реализация определенного поведения или способов ведения бизнеса на основе четырех ценностей и двенадцати принципов (Agile Manifesto). Таким образом, один из способов использовать Agile это реализовать фреймворки или методы, которые очень эффективны для организации, совместной работы и определения приоритетов задач и рабочих процессов в команде, такие как Scrum или Kanban.

Большинство команд выбирают этот подход. Я не думаю, что это неправильно, но я считаю, что этого недостаточно. Когда команды сосредотачиваются только на SCRUM, они забывают, зачем они внедряют Agile. Другими словами, они не видят леса за деревьями. Agile это не скорость. Речь идет о достижении лучших результатов для бизнеса в быстро меняющемся мире. Например, команда в первую очередь оценивает количество новых фич (продукция), а не новых подписчиков (результаты). Производство продукции это нормально, но новые фичи не гарантируют результатов.

Быть Agile

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

Почему быть Agile так сложно

Быть agile это хорошая идея, но не распространенная практика. Причина этого берет корни из каскадной структуре управления проектами. Такой способ управления был создан во время промышленной революции. Целью было найти лучший способ оптимизировать производственную линию. Сейчас все по-другому, потому что скорость изменений настолько высока, что компаниям необходимо адаптироваться каждый день. И что сложнее всего в изменении, так это то, что это не так уж весело. Изменения означают постоянное обучение и преодоление неопределенности. А обучение с неправильным мышлением ведет к неудачам, которые подпитывают нашу неуверенность.

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

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

Это имеет место быть, потому что труднее повлиять на поведение клиента (результат), чем произвести продукт. Это сложно, потому что первое не подконтрольно команде. И это верно, если вы смотрите через линзы перфекциониста, но это не единственно верный способ.

Простое решение

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

Как менеджер, вы должны принять влияние agile на разработку. Вы не можете просить команду использовать Kanban, имея двухлетний план фич, которые команда должна разработать. Вместо этого было бы лучше, если бы вы приняли образ мышления ученика. Как говорит Джефф Готельф, вы создаете бесконечный продукт. Продукт, который постоянно развивается вместе с рынком, и вы не можете знать, что рынок захочет через два года. Образ мышления ученика подразумевает многократные пробы и обучение (на неудачах).

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

Наконец, как лидеру, вам необходимо сформировать общее видение, в котором все понимают, что строка кода влияет на рентабельность инвестиций компании. Вы должны быть последовательны и соответствовать желаемым результатам. Иметь четкие цели и ключевые результаты (OKR - objectives and key results) это нормально, но они должны быть сосредоточены на изменении поведения клиентов.

Заключение

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


Узнать больше о курсе "Enterprise Architect".

Смотреть открытый урок Прошлое, настоящее и будущее роли архитектора предприятия.

Источник: habr.com
К списку статей
Опубликовано: 18.05.2021 18:11:11
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании otus

Управление разработкой

Agile

Enterprise architect

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru