[Управление разработкой, Agile] Почему использовать Agile не достаточно (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Перевод материала подготовлен в рамках курса "Enterprise Architect".Всех желающих приглашаем на открытый урок «Прошлое, настоящее и будущее роли архитектора предприятия». На открытом уроке у нас будет возможность обсудить роль архитектора предприятия: кем были, кем стали и кем должны быть в обозримом будущем, и почему. Поговорим о необходимых компетенциях агента изменений и базовых знаниях для позитивного влияния в организации. Увидим, где начинается архитектурный подход и куда нужно стремиться в профессиональном развитии.
Использовать agile — это амбициозно, но быть agile — воистину трансформативно. С чего лучше начать? Нет однозначного правильного ответа. Но обо всем по порядку. Какая разница между использовать и быть agile?Использовать AgileAgile — это не методология; это образ мышления, который вы можете применить в своей жизни и в своем способе ведения бизнеса. 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
===========
===========
Автор оригинала: FRAN CHERNY
===========Похожие новости:
- [NoSQL, MongoDB] Иерархия потребностей по Маслоу при разработке документации (перевод)
- [Open source, Программирование, Управление разработкой, Управление проектами] Открываем доступ к Platform V — опенсорсному суперфреймворку Сбера
- [Python, Программирование] Функция property() в Python (перевод)
- [Программирование, Java] Отправка электронных писем с помощью Spring (перевод)
- [Тестирование игр] 7 методов тестирования игр (перевод)
- [Программирование, Совершенный код, Управление разработкой] Почему в мире так много отстойного ПО (перевод)
- [Программирование, Анализ и проектирование систем, Проектирование и рефакторинг, Управление разработкой, TypeScript] Чем меня не устраивает гексагональная архитектура. Моя имплементация DDD – многоуровневая блочная архитектура
- [Тестирование IT-систем, Администрирование баз данных] Типы угроз для базы данных (перевод)
- [CSS, HTML] Доступный toggle (перевод)
- [Разработка под iOS, Swift] Построение графиков в SwiftUI (перевод)
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_agile, #_agile, #_enterprise_architect, #_upravlenie_razrabotkoj (управление разработкой), #_blog_kompanii_otus (
Блог компании OTUS
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_agile
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 13:07
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Перевод материала подготовлен в рамках курса "Enterprise Architect".Всех желающих приглашаем на открытый урок «Прошлое, настоящее и будущее роли архитектора предприятия». На открытом уроке у нас будет возможность обсудить роль архитектора предприятия: кем были, кем стали и кем должны быть в обозримом будущем, и почему. Поговорим о необходимых компетенциях агента изменений и базовых знаниях для позитивного влияния в организации. Увидим, где начинается архитектурный подход и куда нужно стремиться в профессиональном развитии.
 Использовать agile — это амбициозно, но быть agile — воистину трансформативно. С чего лучше начать? Нет однозначного правильного ответа. Но обо всем по порядку. Какая разница между использовать и быть agile?Использовать AgileAgile — это не методология; это образ мышления, который вы можете применить в своей жизни и в своем способе ведения бизнеса. 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 =========== =========== Автор оригинала: FRAN CHERNY ===========Похожие новости:
Блог компании OTUS ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_agile |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 13:07
Часовой пояс: UTC + 5