Всем доброе утро!
Предлагаем пятничную разминку:
Перед вами Velocity chart некой команды за 6 месяцев. Вам предстоит работать с этой командой. Что бы вы смогли сказать о команде по этому графику. Какие были бы ваши первые действия, чтобы изменить ситуацию, если её, конечно, нужно менять?
Пишите в комменты свои мнения и замечания...
Предлагаем пятничную разминку:
Перед вами Velocity chart некой команды за 6 месяцев. Вам предстоит работать с этой командой. Что бы вы смогли сказать о команде по этому графику. Какие были бы ваши первые действия, чтобы изменить ситуацию, если её, конечно, нужно менять?
Пишите в комменты свои мнения и замечания...
🔥6❤1👍1
💦Статья Сергея Рогачева Featureban — симуляция Kanban про простую игру-симуляцию Kanban, которая позволяет понять, как Kanban-практики: визуализация, формальные политики, выстраивание обратной связи — обеспечивают прозрачность, а ограничение на одновременно выполняемую работу (Work In Process, WIP) обеспечивает балансировку загрузки и емкости системы.
Описание включает все необходимые материалы для самостоятельного проведения игры.
@agileincubator
#agile #kanban #games #игры #articles #статьи
Описание включает все необходимые материалы для самостоятельного проведения игры.
@agileincubator
#agile #kanban #games #игры #articles #статьи
👍4🔥4⚡1
В бизнесе и продукте, как и в любом другом сложном домене нашей жизни, могут быть различные ограничения, правила и особенности. Как раз об этом варианте декомпозиции пользовательской истории мы и поговорим сегодня.
Вспомните, когда последний раз вы где-то регистрировались. Вспоминаете те ограничения, которым должен был соответствовать ваш пароль? Длина не менее 8 символов, строчные и прописные буквы, спецсимволы. Вот это как раз и есть один из примеров использования бизнес правил.
Рассмотрим процесс регистрации в нашем продукте. «Я, как пользователь, хочу зарегистрироваться в системе, чтобы не потерять историю своих заказов». Первый этап это регистрация. В зависимости от вашего продукта варианты могут быть следующие: регистрация с использованием электронной почты, номера телефона, использование логина. Так же наверняка у вас есть требования к паролю.
Вводя правила в процесс регистрации, вы накладываете ограничения: проверка пароля на соответствие условиям, номер телефона должен соответствовать формату номера, почта должна содержать символ @ и принадлежность к домену (.com, .ru, .uk и т.д.).
Такие ограничения и проверку сделать необходимо, даже не обсуждается. Но появляется другой вопрос — а так ли нам необходимо сделать их для запуска продукта, можем ли пока не проводить проверку, а вынести её в отдельную задачу по пользовательской истории и тем самым ускорить процесс выпуска пользовательской истории, либо зафиксировать общий объём работ.
Давайте поразмышляем. Пользовательская история: «Как пользователь, я хочу иметь возможность оставлять отзывы о товарах на сайте». Чтобы было проще начать, приведу пример первого возможного правила: Пользователь должен авторизоваться на сайте, чтобы оставить комментарий. Напишите в комментариях, какие ещё бизнес условия и правила вы можете предложить для данной истории?
@agileincubator
Вспомните, когда последний раз вы где-то регистрировались. Вспоминаете те ограничения, которым должен был соответствовать ваш пароль? Длина не менее 8 символов, строчные и прописные буквы, спецсимволы. Вот это как раз и есть один из примеров использования бизнес правил.
Рассмотрим процесс регистрации в нашем продукте. «Я, как пользователь, хочу зарегистрироваться в системе, чтобы не потерять историю своих заказов». Первый этап это регистрация. В зависимости от вашего продукта варианты могут быть следующие: регистрация с использованием электронной почты, номера телефона, использование логина. Так же наверняка у вас есть требования к паролю.
Вводя правила в процесс регистрации, вы накладываете ограничения: проверка пароля на соответствие условиям, номер телефона должен соответствовать формату номера, почта должна содержать символ @ и принадлежность к домену (.com, .ru, .uk и т.д.).
Такие ограничения и проверку сделать необходимо, даже не обсуждается. Но появляется другой вопрос — а так ли нам необходимо сделать их для запуска продукта, можем ли пока не проводить проверку, а вынести её в отдельную задачу по пользовательской истории и тем самым ускорить процесс выпуска пользовательской истории, либо зафиксировать общий объём работ.
Давайте поразмышляем. Пользовательская история: «Как пользователь, я хочу иметь возможность оставлять отзывы о товарах на сайте». Чтобы было проще начать, приведу пример первого возможного правила: Пользователь должен авторизоваться на сайте, чтобы оставить комментарий. Напишите в комментариях, какие ещё бизнес условия и правила вы можете предложить для данной истории?
@agileincubator
👍3❤2🔥2👏1
⚡3😁2❤1🔥1🤔1🤣1👻1
🦥В сегодняшних условиях быстро развивающейся цифровой трансформации растет потребность в принятии качественных, быстрых решений в условиях неопределенности. Цифровая трансформация несет с собой огромный потенциал для развития всех участников: каждого из нас, общества, бизнеса, государства. Она меняет нашу жизнь, образование, здравоохранение, бизнес-процессы, способ взаимодействия.
Подробнее в статье Андрея Гирина и Римы Кочарян Lean в информационных технологиях.
@agileincubator
#lean #articles #статьи
Подробнее в статье Андрея Гирина и Римы Кочарян Lean в информационных технологиях.
@agileincubator
#lean #articles #статьи
👍4⚡3🔥2❤1
Декомпозиция. S.P.I.D.R. — Спайки.
Данный подход является «последней капелей» в методе S.P.I.D.R. К нему обычно прибегают в последнюю очередь, когда все предыдущие шаги не помогли.
❤️ Не всегда к нам приходит задача со стороны бизнеса с достаточным описанием, раз.
❤️ Не всегда то, что нужно бизнесу понятно как делать с технической стороны, два.
❤️ В комплексном и сложном продукте не всегда сразу видны и понятны зависимости между частями большой системы, три.
И так можно продолжать. А значит нам не обойтись без предварительного исследования. Как правило, такое предложение исходит от участников команды, в случае возникновения вопросов, ответить на которые команда не может.
В такстрекере (Jira, Kaiten, ClickUp и прочие) такие задачи лучше обозначать отдельным типом. Для этих задач рекомендуется явно ограничить время на исполнение, в идеале 1-2 дня. В них четко описывается та часть функциональности, которая подлежит детальному изучению. А так же как будет выглядеть результат исследования: концептуальная схема, proof-of-concept, отчёт о производительности и т.д. Идеальным вариантом будет считаться описание по пунктам, что следует изучить и для чего.
На следующем PBR (Product Backlog Refinement, встрече по уточнению бэклога) команда возвращается к обсуждению пользовательской истории, но теперь уже с более глубоким пониманием предметной области или технической составляющей, а возможно и четкими задачами в рамках истории.
Это последний этап в методе S.P.I.D.R. А часто ли ваши команды прибегают к пункту Spikes? А можем вы их как-то по другому называете у себя? Или вообще работа с историей у вас начинается с исследования? Поделитесь в комментариях.
Данный подход является «последней капелей» в методе S.P.I.D.R. К нему обычно прибегают в последнюю очередь, когда все предыдущие шаги не помогли.
И так можно продолжать. А значит нам не обойтись без предварительного исследования. Как правило, такое предложение исходит от участников команды, в случае возникновения вопросов, ответить на которые команда не может.
В такстрекере (Jira, Kaiten, ClickUp и прочие) такие задачи лучше обозначать отдельным типом. Для этих задач рекомендуется явно ограничить время на исполнение, в идеале 1-2 дня. В них четко описывается та часть функциональности, которая подлежит детальному изучению. А так же как будет выглядеть результат исследования: концептуальная схема, proof-of-concept, отчёт о производительности и т.д. Идеальным вариантом будет считаться описание по пунктам, что следует изучить и для чего.
На следующем PBR (Product Backlog Refinement, встрече по уточнению бэклога) команда возвращается к обсуждению пользовательской истории, но теперь уже с более глубоким пониманием предметной области или технической составляющей, а возможно и четкими задачами в рамках истории.
Это последний этап в методе S.P.I.D.R. А часто ли ваши команды прибегают к пункту Spikes? А можем вы их как-то по другому называете у себя? Или вообще работа с историей у вас начинается с исследования? Поделитесь в комментариях.
Please open Telegram to view this post
VIEW IN TELEGRAM
👏4👍1🔥1
Доброе утро! Предлагаю пятницу начать с обсуждения очередного кейса.
Вводная: Вы — Скрам-мастер, подключились к команде. Прошла только одна неделя. Вы начинаете немного погружаться в контекст и правила поведения команды. И на одном из дейликов у Вас происходит диалог.
Что Вы, как Скрам-мастер, будете делать дальше?
Вводная: Вы — Скрам-мастер, подключились к команде. Прошла только одна неделя. Вы начинаете немного погружаться в контекст и правила поведения команды. И на одном из дейликов у Вас происходит диалог.
СМ: Как дела по задаче Х?
Dev: В работе.
СМ: А какие достижения за вчера? И как сегодня планируешь подвинуться к окончанию задачи?
Dev: Вчера код писал, сегодня тоже код буду писать.
Что Вы, как Скрам-мастер, будете делать дальше?
⚡4🔥2👏2👍1
🥷Как войти в новую команду и сразу начать двигать изменения? В первые 90 дней роль Agile-коуча или Delivery-менеджера — это не просто адаптация, а шанс изменить процессы и построить доверие. Узнайте, какие шаги помогут вам превратить сопротивление в сотрудничество, а хаос — в продуктивность.
Подробнее в статье Дениса Опалинского Первые 90 дней — инструкция агенту изменений.
@agileincubator
#agile #articles #статьи
Подробнее в статье Дениса Опалинского Первые 90 дней — инструкция агенту изменений.
@agileincubator
#agile #articles #статьи
🔥7👍3⚡3❤1
Очередной инструмент декомпозиции — несколько потребностей.
В процессе разработки продукта, исследования гипотез может случиться так, что мы получаем составную пользовательскую историю. Это легко определить, когда в тексте истории находятся союзы и/или. Как только увидели такое, сразу вспоминайте этот метод.
Как вы уже догадались из названия, мы просто выделяем из пользовательской истории части, которые закрывают определённые потребности. Давайте рассмотрим на примере.
Пример: как покупатель, я хочу, чтобы процесс оформления заказа был интуитивно понятным и быстрым, чтобы я мог без лишних усилий совершить покупку.
Нашли союз «и»? Я думаю особых сложностей не вызвало. Давайте проведём декомпозицию.
Первая история, которую можем выделить: оформление заказа должно быть интуитивно понятным.
Вторая история: оформление заказа должно быть быстрым.
Выглядит просто? Ну да, так оно и есть) И в данном конкретном случае, я думаю, у вас возник вопрос: а что такое интуитивно и быстро? Если это так — то поздравляю, вы на правильном пути размышления. Чтобы ответить на этот вопрос, нам понадобиться понятие «Критерии приёмки». А об этом в следующих постах.
И как обычно, небольшое практическое задание: как пользователь, я хочу иметь возможность сохранять музыкальные плейлисты, чтобы легко добраться до любимой музыки, и просматривать плейлисты друзей, чтобы открывать для себя новые музыкальные хиты.
@agileincubator
В процессе разработки продукта, исследования гипотез может случиться так, что мы получаем составную пользовательскую историю. Это легко определить, когда в тексте истории находятся союзы и/или. Как только увидели такое, сразу вспоминайте этот метод.
Как вы уже догадались из названия, мы просто выделяем из пользовательской истории части, которые закрывают определённые потребности. Давайте рассмотрим на примере.
Пример: как покупатель, я хочу, чтобы процесс оформления заказа был интуитивно понятным и быстрым, чтобы я мог без лишних усилий совершить покупку.
Нашли союз «и»? Я думаю особых сложностей не вызвало. Давайте проведём декомпозицию.
Первая история, которую можем выделить: оформление заказа должно быть интуитивно понятным.
Вторая история: оформление заказа должно быть быстрым.
Выглядит просто? Ну да, так оно и есть) И в данном конкретном случае, я думаю, у вас возник вопрос: а что такое интуитивно и быстро? Если это так — то поздравляю, вы на правильном пути размышления. Чтобы ответить на этот вопрос, нам понадобиться понятие «Критерии приёмки». А об этом в следующих постах.
И как обычно, небольшое практическое задание: как пользователь, я хочу иметь возможность сохранять музыкальные плейлисты, чтобы легко добраться до любимой музыки, и просматривать плейлисты друзей, чтобы открывать для себя новые музыкальные хиты.
@agileincubator
🔥4👏4👍2⚡1
Когда речь заходит о внедрении Agile в компании, многие представляют себе что-то абстрактное, вроде автоматической магической трансформации процессов. На самом деле, внедрение Agile — это методичный, стратегический процесс, требующий не только изменений на уровне инструментов и процессов, но и значительной адаптации культуры внутри компании. Agile — это не про технологии, это про людей. О том, как эта трансформация происходит на практике, мы и поговорим, основываясь на моем опыте трансформаций.
Подробнее в статье Андрея Гирина Agile: особенности внедрения.
@agileincubator
#agile #articles #статьи
Подробнее в статье Андрея Гирина Agile: особенности внедрения.
@agileincubator
#agile #articles #статьи
🔥5❤4⚡2👏1
Декомпозиция. Разные платформы.
Самый распространённый вариант декомпозиции пользовательской истории.
Как правило, в современном мире любой цифровой продукт доступен на нескольких платформах, к примеру Android, IOS, Windows, MacOS, Linux и прочие в зависимости от продукта.
Самым очевидным решением является разделение одного большого запроса клиента на платформы, где он может решить свои проблемы и получить ценность.
Понимая целевую аудиторию (ЦА) и зная свой продукт, вы можете определить, на какой платформе у вас больше всего активных или платящих клиентов. И, в качестве приоритетной задачи, определить реализацию пользовательской истории именно для этой платформы.
Это не обязательно должна быть разработка приложения. Если рассматривать вопрос в контексте веб-разработки, то в первую очередь верстку сайта можно реализовывать под мобильные платформы. И только потом сделать из сайта, адаптированного под навигацию на телефонах, сайт с навигацией под десктопные устройства (mobile first).
Все зависит от вашего продукта и вашей ЦА.
А вы разбиваете продукт и команды на работу с различными платформами? Или ваш продукт выходит разом на множестве платформ?
@agileincubator
Самый распространённый вариант декомпозиции пользовательской истории.
Как правило, в современном мире любой цифровой продукт доступен на нескольких платформах, к примеру Android, IOS, Windows, MacOS, Linux и прочие в зависимости от продукта.
Самым очевидным решением является разделение одного большого запроса клиента на платформы, где он может решить свои проблемы и получить ценность.
Понимая целевую аудиторию (ЦА) и зная свой продукт, вы можете определить, на какой платформе у вас больше всего активных или платящих клиентов. И, в качестве приоритетной задачи, определить реализацию пользовательской истории именно для этой платформы.
Это не обязательно должна быть разработка приложения. Если рассматривать вопрос в контексте веб-разработки, то в первую очередь верстку сайта можно реализовывать под мобильные платформы. И только потом сделать из сайта, адаптированного под навигацию на телефонах, сайт с навигацией под десктопные устройства (mobile first).
Все зависит от вашего продукта и вашей ЦА.
А вы разбиваете продукт и команды на работу с различными платформами? Или ваш продукт выходит разом на множестве платформ?
@agileincubator
🔥6❤4👏3
🎁Разыгрываем билет на онлайн-трансляцию конференции Enterprise Agile Russia 18 ноября 2024.
Конкурс на самый креативный ответ!
❓ «Чем заканчивается трансформация?»
Условия:
✔️ Быть подписанным на этот Telegram-канал @agileincubator.
✔️ Оставить один комментарий с ответом на вопрос под этим постом.
✔️ Победитель — комментатор, набравший больше всего реакций (лайки самого себя не учитываются).
🏆 Итоги конкурса подведем ровно через неделю, 8 ноября.
#enterpriseagilerussia24
Конкурс на самый креативный ответ!
❓ «Чем заканчивается трансформация?»
Условия:
✔️ Быть подписанным на этот Telegram-канал @agileincubator.
✔️ Оставить один комментарий с ответом на вопрос под этим постом.
✔️ Победитель — комментатор, набравший больше всего реакций (лайки самого себя не учитываются).
🏆 Итоги конкурса подведем ровно через неделю, 8 ноября.
#enterpriseagilerussia24
🔥3❤2⚡2👍1👏1
Статья Юлии Герасимовой Penny Game: делайте больше, уменьшая нагрузку — простая игра про поток и вытягивание, в ходе которой вы можете научиться бережливому производству, Lean в применении к интеллектуальному труду.
@agileincubator
#agile #scrum #games #игры #devops #articles #статьи
@agileincubator
#agile #scrum #games #игры #devops #articles #статьи
👍8❤1👏1⚡1
Декомпозиция. Критерии приёмки.
Скажите честно, часто ли к вам «прилетают» задачи со словами: «Сделать продукт самым крутым», или «Интерфейс должен быть понятным», или «Всё должно работать быстро»?
Вы делаете интерфейс и работу с ним быстрой и понятной, а по результату все равно «медленно», «наш продукт не самый крутой, и вообще, я ничего тут не понимаю».
Знакомо, не правда ли!
Из названия вы догадались, о чем пойдёт речь. Да-да, как раз о тех самых вопросах: «Что значит крутой?», «Понятный — это какой?», «Быстро — это быстрее 5 секунд?». Отвечая на данные вопросы, вы проясняете мысли заказчика, с одной стороны, а с другой облегчаете себе работу над задачей.
Как только вы вместе поймёте, что для заказчика:
🟢 «Крутой продукт» — место в ТОП-5 конкретного отраслевого рейтинга.
🟢 Понятный интерфейс — когда 99,9% пользователей проходят по клиентскому пути без обращения к справке.
🟢 Быстро — пользователь не ждёт загрузки интерфейса больше 1 секунды.
Вы сразу же получаете те критерии приёмки задачи, которые ожидает заказчик. При достижении которых он не сможет сказать, что ему что-то не нравится. Помимо ясности в формате конечного варианта, вы сразу же получаете примерную разбивку на более мелкие задачи.
Рассмотрим на примере. Как покупатель, я хочу иметь возможность добавлять товары в корзину, чтобы удобно совершать покупки.
После беседы вы получили следующие критерии приёмки, по которым заказчик согласится принять задачу:
🔴 после добавления товара в корзину обновляется иконка корзины на сайте с увеличением числа товаров в ней;
🔴 товар в корзине можно удалить из карточки товара;
🔴 в корзине отображается количество товара на складе.
Вы уже получили несколько готовых для реализации задач:
🟠 функция обновления иконки и подсчёт товара в корзине;
🟠 смена кнопки «Добавить в корзину» на «Удалить из корзины»;
🟠 интеграция с базой склада для получения актуального количества товара.
Надеюсь, вы уловили суть. Довольно просто, когда у всех участников процесса есть единое понимание конечного результата и необходимой работы.
А теперь пример на самостоятельную декомпозицию. Как потребитель я хочу быстро сделать заказ, чтобы что-нибудь поесть. Ваши уточняющие вопросы можете задавать в комментариях к посту. Я буду отвечать из роли заказчика, и вместе мы получим критерии приёмки и предварительную декомпозицию.
@agileincubator
Скажите честно, часто ли к вам «прилетают» задачи со словами: «Сделать продукт самым крутым», или «Интерфейс должен быть понятным», или «Всё должно работать быстро»?
Вы делаете интерфейс и работу с ним быстрой и понятной, а по результату все равно «медленно», «наш продукт не самый крутой, и вообще, я ничего тут не понимаю».
Знакомо, не правда ли!
Из названия вы догадались, о чем пойдёт речь. Да-да, как раз о тех самых вопросах: «Что значит крутой?», «Понятный — это какой?», «Быстро — это быстрее 5 секунд?». Отвечая на данные вопросы, вы проясняете мысли заказчика, с одной стороны, а с другой облегчаете себе работу над задачей.
Как только вы вместе поймёте, что для заказчика:
Вы сразу же получаете те критерии приёмки задачи, которые ожидает заказчик. При достижении которых он не сможет сказать, что ему что-то не нравится. Помимо ясности в формате конечного варианта, вы сразу же получаете примерную разбивку на более мелкие задачи.
Рассмотрим на примере. Как покупатель, я хочу иметь возможность добавлять товары в корзину, чтобы удобно совершать покупки.
После беседы вы получили следующие критерии приёмки, по которым заказчик согласится принять задачу:
Вы уже получили несколько готовых для реализации задач:
Надеюсь, вы уловили суть. Довольно просто, когда у всех участников процесса есть единое понимание конечного результата и необходимой работы.
А теперь пример на самостоятельную декомпозицию. Как потребитель я хочу быстро сделать заказ, чтобы что-нибудь поесть. Ваши уточняющие вопросы можете задавать в комментариях к посту. Я буду отвечать из роли заказчика, и вместе мы получим критерии приёмки и предварительную декомпозицию.
@agileincubator
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥3⚡2👏1
✨Итоги розыгрыша билета на онлайн-трансляцию конференции Enterprise Agile Russia 18 ноября 2024.
👏Победителем становится: Екатерина Никонова. Ответ Екатерины набрал наибольшее количество лайков. 👍
🎁Свяжемся с победителем в ближайшее время.
Спасибо всем за участие!
@agileincubator
👏Победителем становится: Екатерина Никонова. Ответ Екатерины набрал наибольшее количество лайков. 👍
🎁Свяжемся с победителем в ближайшее время.
Спасибо всем за участие!
@agileincubator
⚡4❤3🔥2👍1
В статье Lean Canvas Workshop — как собрать концепцию и определить минимально-жизнеспособный продукт Сергей Рогачев описывает воркшоп, на котором участники определяют MVP (Minimum Viable Product) с помощью инструмента Lean Canvas.
@agileincubator
#agile #scrum #articles #статьи
@agileincubator
#agile #scrum #articles #статьи
🔥4⚡3
Декомпозиция. Временные, затем сохраняемые данные.
Нет ничего более постоянного, чем временное! Наверняка вы слышали такую фразу в обыденной жизни. Но мы не будем углубляться в философские рассуждения, а пойдём техническим путём.
В работе могут встречаться пользовательские истории, например: как пользователь, я хочу оплатить заказ кредитной картой на сайте, чтобы не посещать магазин.
Кажется, нет ничего сложного — прикрути оплату картой, и пользователь будет счастлив. Но и здесь можно пойти несколькими путями.
Рассмотрим путь временных данных.
🟠 Первым делом подключаем модуль оплаты на нашем сайте, и просим вводить данные карты при оплате, но не сохраняем их в профиль пользователя. И при каждой следующей оплате мы вновь будем просить пользователя ввести данные. Скорее всего, не так удобно как хотелось, но потребность пользователя уже закрывается. Он оплачивает картой.
🟠 А следующим шагом, мы можем разработать функциональность сохранения данных о карте в профиль пользователя. Это уже постоянные данные, доступные в любой момент времени.
Выглядит достаточно просто, но, как правило, о временных мерах часто забывают в угоду удобству пользователя. В некоторых контекстах это оправдано. Но и случаи, когда нужно быстро выдать результат с временными данными, часто встречаются в продуктовой разработке.
В этот раз попробуем что-нибудь новенькое: накидайте в комментарии случаи из своей практики, когда данный подход подошёл бы вам.
Нет ничего более постоянного, чем временное! Наверняка вы слышали такую фразу в обыденной жизни. Но мы не будем углубляться в философские рассуждения, а пойдём техническим путём.
В работе могут встречаться пользовательские истории, например: как пользователь, я хочу оплатить заказ кредитной картой на сайте, чтобы не посещать магазин.
Кажется, нет ничего сложного — прикрути оплату картой, и пользователь будет счастлив. Но и здесь можно пойти несколькими путями.
Рассмотрим путь временных данных.
Выглядит достаточно просто, но, как правило, о временных мерах часто забывают в угоду удобству пользователя. В некоторых контекстах это оправдано. Но и случаи, когда нужно быстро выдать результат с временными данными, часто встречаются в продуктовой разработке.
В этот раз попробуем что-нибудь новенькое: накидайте в комментарии случаи из своей практики, когда данный подход подошёл бы вам.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤2🔥1⚡1
🥷Каждый агент изменений уникален, но как выявить свои сильные стороны и развить их для максимальной эффективности?
В статье Дениса Опалинского Архетипы агента изменений: как эффективно использовать свои сильные стороны вы погрузитесь в шесть ключевых архетипов Agile-коучей — от аналитиков до эмпатов — и посмотрите, как их можно использовать для трансформации бизнеса и команд. Узнаете, какой архетип ближе вам и вашей компании, и как именно эти знания помогут вам ускорить развитие, повысить эффективность и достичь новых высот в профессии.
@agileincubator
#agile #articles #статьи
В статье Дениса Опалинского Архетипы агента изменений: как эффективно использовать свои сильные стороны вы погрузитесь в шесть ключевых архетипов Agile-коучей — от аналитиков до эмпатов — и посмотрите, как их можно использовать для трансформации бизнеса и команд. Узнаете, какой архетип ближе вам и вашей компании, и как именно эти знания помогут вам ускорить развитие, повысить эффективность и достичь новых высот в профессии.
@agileincubator
#agile #articles #статьи
⚡5❤3👍1