Прекрасный пример применения Agile в организации учебного процесса студентов.
https://onagile.ru/trends/business-agility/laboratoria
https://onagile.ru/trends/business-agility/laboratoria
OnAgile Consulting
Спринты вместо семестров и вовлеченные команды вместо скучающих слушателей лекций.
Применение Agile и Scrum в образовании 💎 — OnAgile Consulting
Приятно видеть, как в мире развивается экосистема для предпринимателей.
Пять лет назад, для примера, в России любое действие с регистрацией/бухгалтерией/банковским обслуживанием было квестом. С кучей потерянного времени, заполненных бумажек, походов в банк, комиссий и дополнительных сотрудников на выполнение рутинных, ненужных бизнесу операций.
Помню, одними из первых, кто увидел свободную нишу, были МодульБанк с Точкой, а в итоге стали подтягиваться даже Альфа со Сбербанком, выстраивая свои сервисы вокруг потребностей предпринимателей.
Сейчас это норма, но в 2014 году открыть счет для ИП через приложение без поездки в банк (!) и сразу получить на него деньги от клиента - это было очень круто!
Именно Agile подход помогает крупным компаниям фокусироваться на потребностях клиентов больше, чем на внутренних процедурах.
Пять лет назад, для примера, в России любое действие с регистрацией/бухгалтерией/банковским обслуживанием было квестом. С кучей потерянного времени, заполненных бумажек, походов в банк, комиссий и дополнительных сотрудников на выполнение рутинных, ненужных бизнесу операций.
Помню, одними из первых, кто увидел свободную нишу, были МодульБанк с Точкой, а в итоге стали подтягиваться даже Альфа со Сбербанком, выстраивая свои сервисы вокруг потребностей предпринимателей.
Сейчас это норма, но в 2014 году открыть счет для ИП через приложение без поездки в банк (!) и сразу получить на него деньги от клиента - это было очень круто!
Именно Agile подход помогает крупным компаниям фокусироваться на потребностях клиентов больше, чем на внутренних процедурах.
Перевыполнить план на 45% с помощью применения agile подхода всего за 3 месяца? Почему бы и нет 🙂
Отличный получился кейс с компанией из большой тройки, когда в результате запуска agile команд напрямую улучшились бизнес-показатели.
Прочитайте кейс и спрашивайте подробности, с удовольствием поделимся деталями.
https://onagile.ru/industries/telecommunication/agile-in-telecom
Отличный получился кейс с компанией из большой тройки, когда в результате запуска agile команд напрямую улучшились бизнес-показатели.
Прочитайте кейс и спрашивайте подробности, с удовольствием поделимся деталями.
https://onagile.ru/industries/telecommunication/agile-in-telecom
Принятие решений в Agile-команде — коллективное или экспертное?
Экспедиция в горы как хорошая аналогия к работе Agile-команд, где есть бизнес-цель (вершина) и различные риски, в том числе технологические (необходимость вернуться обратно живыми).
В обоих случаях для этих двух типов задач команда — и ее лидер — должны выбирать разные подходы к решению, и это не всегда про демократию и консенсус.
https://onagile.ru/trends/leadership/teamwork-and-climbing-expeditions-experience
Экспедиция в горы как хорошая аналогия к работе Agile-команд, где есть бизнес-цель (вершина) и различные риски, в том числе технологические (необходимость вернуться обратно живыми).
В обоих случаях для этих двух типов задач команда — и ее лидер — должны выбирать разные подходы к решению, и это не всегда про демократию и консенсус.
https://onagile.ru/trends/leadership/teamwork-and-climbing-expeditions-experience
OnAgile Consulting
Принятие решений: в каких условиях наиболее эффективно коллективное обсуждение, а в каких полезнее иерархическое управление?
Командная работа: чему нас может научить опыт высокогорных экспедиций 💎 — OnAgile Consulting
О приоритизации бэклога.
Один из самых популярных вопросов у менеджеров продукта/Product owner-ов про приоритизацию бэклога. Какой из инструментов самый лучший? Прежде чем ответить на этот вопрос, хочется обратиться к математике.
Есть такой класс математических задач, которые называются NP-полными. Практически это означает, что не существует алгоритма, который может решить эту задачу за полиномиальное, т.е. какое-то реальное и адекватное время.
Одна из таких задач — об укладке ранца. Суть ее такова: есть ранец, и известен некий максимальный вес, который вы можете поднять и унести в нем. И есть набор коробок, отличающихся весом и ценностью. Задача заключается в том, чтобы найти способ наиболее эффективно разместить коробки в рюкзаке так, чтобы можно было унести максимальную ценность.
И кажется, этот пример очень близок задаче приоритизации бэклога 😉
Конечно, можно возразить, что приоритизация более простая вещь, потому что есть такие параметры, как дедлайны или зависимости, существенно упрощающие процесс. Но проблема в том, что если по условиям задачи про ранец вы точно знаете ценность коробки и ее вес, то в случае приоритизации все предположения о «value» или сложности элемента бэклога достаточно приблизительны.
Таким образом, можно сделать околонаучное допущение, что задача о приоритизации также не решается. А значит, все запросы на нахождение инструмента, который единственно правильным и магическим образом упорядочит backlog являются немного наивными.
Остается забыть о поисках серебряной пули и, как обычно в любой непонятной ситуации, просто-напросто думать.
Ну или использовать "жадные" алгоритмы, но про них в следующем посте.
Один из самых популярных вопросов у менеджеров продукта/Product owner-ов про приоритизацию бэклога. Какой из инструментов самый лучший? Прежде чем ответить на этот вопрос, хочется обратиться к математике.
Есть такой класс математических задач, которые называются NP-полными. Практически это означает, что не существует алгоритма, который может решить эту задачу за полиномиальное, т.е. какое-то реальное и адекватное время.
Одна из таких задач — об укладке ранца. Суть ее такова: есть ранец, и известен некий максимальный вес, который вы можете поднять и унести в нем. И есть набор коробок, отличающихся весом и ценностью. Задача заключается в том, чтобы найти способ наиболее эффективно разместить коробки в рюкзаке так, чтобы можно было унести максимальную ценность.
И кажется, этот пример очень близок задаче приоритизации бэклога 😉
Конечно, можно возразить, что приоритизация более простая вещь, потому что есть такие параметры, как дедлайны или зависимости, существенно упрощающие процесс. Но проблема в том, что если по условиям задачи про ранец вы точно знаете ценность коробки и ее вес, то в случае приоритизации все предположения о «value» или сложности элемента бэклога достаточно приблизительны.
Таким образом, можно сделать околонаучное допущение, что задача о приоритизации также не решается. А значит, все запросы на нахождение инструмента, который единственно правильным и магическим образом упорядочит backlog являются немного наивными.
Остается забыть о поисках серебряной пули и, как обычно в любой непонятной ситуации, просто-напросто думать.
Ну или использовать "жадные" алгоритмы, но про них в следующем посте.
В прошлый раз мы остановились на «жадных алгоритмах» ⬆⬆⬆.
https://telegra.ph/Behklog-i-matematika-07-03
https://telegra.ph/Behklog-i-matematika-07-03
Telegraph
Бэклог и математика
Внести в процесс приоритизации конкретику и объяснить иерархию задач в понятных числах может помочь система оценки WSJF — Weighted Shortest Job First. Как видно из названия, чем выше коэффициент WSJF, тем приоритетнее задача. Где: Ценность для клиента/бизнеса…
Небольшой анонс программ обучения на сентябрь, созданных в партнерстве с International Consortium for Agile.
Мы разработали полный курс обучения, состоящий из трех уровней погружения в Agile и Scrum.
От понимания, как работает Agile и что нужно сделать для внедрения Scrum в команде, до детального изучения подходов к созданию востребованных продуктов.
👨🎓 Международный сертификат от консорциума ICAgile каждому участнику.
Посмотреть программу и зарегистрироваться можно здесь ➡️ www.onagile.ru/trainings
Мы разработали полный курс обучения, состоящий из трех уровней погружения в Agile и Scrum.
От понимания, как работает Agile и что нужно сделать для внедрения Scrum в команде, до детального изучения подходов к созданию востребованных продуктов.
👨🎓 Международный сертификат от консорциума ICAgile каждому участнику.
Посмотреть программу и зарегистрироваться можно здесь ➡️ www.onagile.ru/trainings
Несколько советов, как работать с молодыми сотрудниками и помочь раскрыть их потенциал.
Даже мы, в небольшой, казалось бы, компании, уже смогли почувствовать разницу поколений 🙂
https://vc.ru/hr/75600-pokolenie-z-v-agile-komandah-kak-s-nimi-rabotat
Даже мы, в небольшой, казалось бы, компании, уже смогли почувствовать разницу поколений 🙂
https://vc.ru/hr/75600-pokolenie-z-v-agile-komandah-kak-s-nimi-rabotat
vc.ru
Поколение Z в Agile-командах — как с ними работать? — Карьера на vc.ru
Первое полностью цифровое поколение уже заканчивает университеты и становится частью рабочих команд. Как выстраивать с ними эффективное взаимодействие?
В чем отличие Agile от Lean?
Люди, знакомые с Lean или работающие в компаниях, где он применяется, часто спрашивают нас, а в чем отличие Agile от Lean? Вроде бы очень похожие подходы по ценностям и некоторым инструментам.
Тем не менее разница значительная.
1. Lean стремится устранить неэффективные способы работы, а Agile ищет более эффективные пути разработки продуктов с помощью инкрементального подхода.
2. Lean концентрируется на повышении продуктивности процесса и сокращении затрат, Agile нацелен на повышение ценности создаваемого продукта для клиента.
Если вы уже сталкивались с подобным обсуждением, поделитесь с коллегами 👉
Люди, знакомые с Lean или работающие в компаниях, где он применяется, часто спрашивают нас, а в чем отличие Agile от Lean? Вроде бы очень похожие подходы по ценностям и некоторым инструментам.
Тем не менее разница значительная.
1. Lean стремится устранить неэффективные способы работы, а Agile ищет более эффективные пути разработки продуктов с помощью инкрементального подхода.
2. Lean концентрируется на повышении продуктивности процесса и сокращении затрат, Agile нацелен на повышение ценности создаваемого продукта для клиента.
Если вы уже сталкивались с подобным обсуждением, поделитесь с коллегами 👉
Вакансия.
Мы ищем человека, который займется развитием открытых тренингов в OnAgile Academy.
Это и про улучшение клиентского опыта, и про развитие направления в целом.
Хочется проводить больше тренингов, обучать больше участников и все идеально организовывать 🙂
Важное условие - предпринимательский майндсет. Мы бы не хотели вам говорить, что и как нужно делать, но, конечно же, поможем видением, опытом и советом.
Понимание организации процесса обучения и наличие соответствующего опыта - обязательно.
Москва, м. Автозаводская, наш светлый и уютный офис с прекрасной кофемашиной.
Присылайте резюме и пару строк, почему вам эта вакансия интересна, будем рады познакомиться!
info@onagile.ru
Мы ищем человека, который займется развитием открытых тренингов в OnAgile Academy.
Это и про улучшение клиентского опыта, и про развитие направления в целом.
Хочется проводить больше тренингов, обучать больше участников и все идеально организовывать 🙂
Важное условие - предпринимательский майндсет. Мы бы не хотели вам говорить, что и как нужно делать, но, конечно же, поможем видением, опытом и советом.
Понимание организации процесса обучения и наличие соответствующего опыта - обязательно.
Москва, м. Автозаводская, наш светлый и уютный офис с прекрасной кофемашиной.
Присылайте резюме и пару строк, почему вам эта вакансия интересна, будем рады познакомиться!
info@onagile.ru
#разборкейса
Срочные задачи — бросать все и делать?
Ситуация, с которой сталкиваются почти все команды, особенно на этапе становления процесса по Канбан-методу: завели доску и все визуализировали, определили условия передвижения задач из столбца в столбец, определили WIP-лимиты. Согласовали с заказчиком приоритеты, чтобы понимать, в какой последовательности брать задачи. Все отлично, работаем.
И тут, уже после сессии расстановки приоритетов (replenishment meeting), от заказчика приходит новая срочная задача. А потом еще одна. Что обычно делает команда? Откладывает все и берется за новые задачи. И скорее всего, совершает ошибку.
Уже скоро выяснится, что запланированные задачи повисли незавершенными, и если новые команда тоже не успела доделать — сложится впечатление, что не сделано вообще ничего, хотя усилия затрачены. Команда расстроена, заказчик недоволен, и аргумент «Мы же переключились на новые срочные задачи», скорее всего, не сработает. Более того, все начинание по внедрению Agile может показаться неэффективным, хотя Канбан-метод просто сделал существующие проблемы видимыми.
Что делать? Вспомнить про принцип эволюционного развития и «вытягивания» новых задач по мере мере продвижения текущих. Прежде чем браться за любое внеплановое задание, стоит обсудить с заказчиком текущую ситуацию: что уже находится в работе, на какой стадии, действительно ли новая задача требует отставить все остальное в сторону или она сможет подождать до завтра/ послезавтра, когда будет завершена текущая?
В этот момент полезно еще раз проговорить правила взаимодействия заказчика с командой и порядок вытягивания задач из очереди — чтобы все понимали, почему делается так или иначе.
Срочные задачи — бросать все и делать?
Ситуация, с которой сталкиваются почти все команды, особенно на этапе становления процесса по Канбан-методу: завели доску и все визуализировали, определили условия передвижения задач из столбца в столбец, определили WIP-лимиты. Согласовали с заказчиком приоритеты, чтобы понимать, в какой последовательности брать задачи. Все отлично, работаем.
И тут, уже после сессии расстановки приоритетов (replenishment meeting), от заказчика приходит новая срочная задача. А потом еще одна. Что обычно делает команда? Откладывает все и берется за новые задачи. И скорее всего, совершает ошибку.
Уже скоро выяснится, что запланированные задачи повисли незавершенными, и если новые команда тоже не успела доделать — сложится впечатление, что не сделано вообще ничего, хотя усилия затрачены. Команда расстроена, заказчик недоволен, и аргумент «Мы же переключились на новые срочные задачи», скорее всего, не сработает. Более того, все начинание по внедрению Agile может показаться неэффективным, хотя Канбан-метод просто сделал существующие проблемы видимыми.
Что делать? Вспомнить про принцип эволюционного развития и «вытягивания» новых задач по мере мере продвижения текущих. Прежде чем браться за любое внеплановое задание, стоит обсудить с заказчиком текущую ситуацию: что уже находится в работе, на какой стадии, действительно ли новая задача требует отставить все остальное в сторону или она сможет подождать до завтра/ послезавтра, когда будет завершена текущая?
В этот момент полезно еще раз проговорить правила взаимодействия заказчика с командой и порядок вытягивания задач из очереди — чтобы все понимали, почему делается так или иначе.
В крупных компаниях нередки встречи и совещания, на которых одновременно присутствуют 20 человек, при этом в течение часа или двух обсуждаются вопросы, для принятия решений в которых достаточно всего четырех человек.
Ну, вы знаете, наверняка в таких участвовали 🙂
Подслушали недавно у клиента забавный термин, описывающий такие мероприятия, — togethering (тугезэринг, буквально: делание чего-то вместе)
А как у вас называются встречи, на которых переговорка битком, но при этом половина людей сидит в ноутбуках и телефонах?
Ну, вы знаете, наверняка в таких участвовали 🙂
Подслушали недавно у клиента забавный термин, описывающий такие мероприятия, — togethering (тугезэринг, буквально: делание чего-то вместе)
А как у вас называются встречи, на которых переговорка битком, но при этом половина людей сидит в ноутбуках и телефонах?
Возможно ли организовать эффективную работу распределенной команды, и на что при этом обратить внимание? Несколько полезных практик из нашего опыта➡
https://vc.ru/hr/77384-ofis-vs-udalennaya-rabota-v-agile-komande
https://vc.ru/hr/77384-ofis-vs-udalennaya-rabota-v-agile-komande
vc.ru
Офис vs удаленная работа в Agile-команде — Карьера на vc.ru
Плюсы и минусы удаленной работы. И 5 практик, которые помогут запустить распределенные Agile-команды, от консультантов OnAgile Consulting.
Обратная связь внутри команды
Для всесторонней оценки работы команды мнения только руководителя или Scrum-мастера может быть недостаточно. Много ценной информации также способна дать обратная связь от коллег по команде — они, в отличие от руководителя, наблюдают за работой друг друга каждый день. К тому же такие комментарии сопровождаются меньшим стрессом, чем когда работу оценивает человек, принимающий решение о размере премии.
Регулярная практика обратной связи с коллегами (peer feedback) помогает процессу постоянного улучшения. Вот несколько простых правил, которые помогут наладить фидбэк без лишнего стресса:
🔹 Базовые принципы обратной связи — обсуждение один на один, и только когда коллега готов ее услышать.
🔹Анонимная обратная связь — «часть нашей команды считает, что...» — работает хуже. Гораздо полезнее для всего рабочего процесса создать среду, в которой возможны открытые и честные отзывы.
🔹Контекст: обратная связь всегда относится к ситуации, а не к человеку. Описывая ситуацию со своей точки зрения, мы улучшаем взаимопонимание.
🔹Наблюдения вместо простого перечисления фактов. «Я заметил, что...»
🔹Чувства важны: описывая, как ситуация влияет на нас, мы даем понять, чем мотивирован фидбэк, и фокусируем разговор на важности изменений.
🔹Предложения: как можно улучшить ситуацию? как избежать повторения подобных сценариев? Даже если коллега не воспользуется ими буквально, это хорошая возможность еще раз сверить ориентиры.
🔹Диалог: обратная связь не должна превращаться в монолог, который неизбежно поставит одного члена команды выше другого. Важно узнать, как сам коллега видит ситуацию, с чем согласен, а с чем — нет.
🔹Для формулирования обратной связи можно воспользоваться акронимом OSCAR (observed, situation, consequence, alternative, resulting): «Я наблюдал.., особенно в этой ситуации…, возможные последствия… Я предлагаю следующую альтернативу… В результате...»
А в вашей команде принято делиться мнениями о работе друг друга? С какими сложностями при этом сталкивались?
Для всесторонней оценки работы команды мнения только руководителя или Scrum-мастера может быть недостаточно. Много ценной информации также способна дать обратная связь от коллег по команде — они, в отличие от руководителя, наблюдают за работой друг друга каждый день. К тому же такие комментарии сопровождаются меньшим стрессом, чем когда работу оценивает человек, принимающий решение о размере премии.
Регулярная практика обратной связи с коллегами (peer feedback) помогает процессу постоянного улучшения. Вот несколько простых правил, которые помогут наладить фидбэк без лишнего стресса:
🔹 Базовые принципы обратной связи — обсуждение один на один, и только когда коллега готов ее услышать.
🔹Анонимная обратная связь — «часть нашей команды считает, что...» — работает хуже. Гораздо полезнее для всего рабочего процесса создать среду, в которой возможны открытые и честные отзывы.
🔹Контекст: обратная связь всегда относится к ситуации, а не к человеку. Описывая ситуацию со своей точки зрения, мы улучшаем взаимопонимание.
🔹Наблюдения вместо простого перечисления фактов. «Я заметил, что...»
🔹Чувства важны: описывая, как ситуация влияет на нас, мы даем понять, чем мотивирован фидбэк, и фокусируем разговор на важности изменений.
🔹Предложения: как можно улучшить ситуацию? как избежать повторения подобных сценариев? Даже если коллега не воспользуется ими буквально, это хорошая возможность еще раз сверить ориентиры.
🔹Диалог: обратная связь не должна превращаться в монолог, который неизбежно поставит одного члена команды выше другого. Важно узнать, как сам коллега видит ситуацию, с чем согласен, а с чем — нет.
🔹Для формулирования обратной связи можно воспользоваться акронимом OSCAR (observed, situation, consequence, alternative, resulting): «Я наблюдал.., особенно в этой ситуации…, возможные последствия… Я предлагаю следующую альтернативу… В результате...»
А в вашей команде принято делиться мнениями о работе друг друга? С какими сложностями при этом сталкивались?
Product owner и скрам-мастер: почему важно разделять эти роли
Когда компания начинает внедрять Scrum, две новые роли — владелец продукта и скрам-мастер — часто решают назначить одному человеку. Обычно это менеджер проекта или тимлид. Но это так не работает.
Скрам-мастер — это не только тот, благодаря кому встречи команды наконец-то начинают укладываться в отведенное для них время. Его задача — помогать команде придерживаться правил фреймворка и, главное, самоорганизовываться: понимать, как прийти к заданной цели, вовремя обнаруживать проблемы и находить их решения.
Product owner в это время должен развивать продукт, чтобы тот удовлетворял потребности потребителей и приносил прибыль компании. Он отвечает за видение продукта, за понимание потребностей клиентов, обеспечивает коммуникации между стейкхолдерами и командой и формирует бэклог, над которым будет работать команда.
По сути, product owner говорит команде, что нужно делать, но не навязывает свое видение, как этого добиться. А скрам-мастер помогает команде научиться работать максимально эффективно, постоянно улучшая процесс своей работы. И если обе этих роли соединить в одном человеке, мы вернемся к модели работы классического менеджера, и наши Agile и Scrum превратятся в просто наклеивание стикеров и постоянные встречи.
Когда компания начинает внедрять Scrum, две новые роли — владелец продукта и скрам-мастер — часто решают назначить одному человеку. Обычно это менеджер проекта или тимлид. Но это так не работает.
Скрам-мастер — это не только тот, благодаря кому встречи команды наконец-то начинают укладываться в отведенное для них время. Его задача — помогать команде придерживаться правил фреймворка и, главное, самоорганизовываться: понимать, как прийти к заданной цели, вовремя обнаруживать проблемы и находить их решения.
Product owner в это время должен развивать продукт, чтобы тот удовлетворял потребности потребителей и приносил прибыль компании. Он отвечает за видение продукта, за понимание потребностей клиентов, обеспечивает коммуникации между стейкхолдерами и командой и формирует бэклог, над которым будет работать команда.
По сути, product owner говорит команде, что нужно делать, но не навязывает свое видение, как этого добиться. А скрам-мастер помогает команде научиться работать максимально эффективно, постоянно улучшая процесс своей работы. И если обе этих роли соединить в одном человеке, мы вернемся к модели работы классического менеджера, и наши Agile и Scrum превратятся в просто наклеивание стикеров и постоянные встречи.
Анализ продуктов конкурентов
Когда product owner задумывается о развитии продукта и повышении его ценности для клиентов, сравнение обычно идет с тем, что предлагают конкуренты. И вот почему этого недостаточно:
Клиент не делает буквальный выбор между продуктами А и Б — он хочет решить свою задачу. И для этого у него может оказаться гораздо больше возможностей, чем кажется при анализе текущей ситуации на рынке.
Простой пример. Допустим, наша компания производит сушилки для обуви: мы много работаем над дизайном, бьемся за снижение энергопотребления и делаем провод, который не перегрызет собака. Мы смотрим на сушилки конкурентов и стараемся сделать лучше.
А теперь представьте, что вы попали под дождь. Не впервые за это лето, и в этот раз пообещали себе точно не забыть купить сушилку. Но тут вам на глаза попадается газета, из тех что вечно оказываются в почтовом ящике, — и это тоже способ решить вашу проблему. И вот уже бесплатная газета становится конкурентом сушилок производителя А, и Б, и С. А еще можно поставить обувь к батарее — не самый бережный метод, но и это тоже конкурентный способ решить проблему клиента.
Поэтому мы рекомендуем при разработке стратегии развития продукта, помимо анализа текущего поведения пользователей и сравнения с предложениями конкурентов, учитывать любые альтернативы, которые позволят клиенту решить свои задачи.
❓ А какие неочевидные альтернативы есть у вашего продукта?
Когда product owner задумывается о развитии продукта и повышении его ценности для клиентов, сравнение обычно идет с тем, что предлагают конкуренты. И вот почему этого недостаточно:
Клиент не делает буквальный выбор между продуктами А и Б — он хочет решить свою задачу. И для этого у него может оказаться гораздо больше возможностей, чем кажется при анализе текущей ситуации на рынке.
Простой пример. Допустим, наша компания производит сушилки для обуви: мы много работаем над дизайном, бьемся за снижение энергопотребления и делаем провод, который не перегрызет собака. Мы смотрим на сушилки конкурентов и стараемся сделать лучше.
А теперь представьте, что вы попали под дождь. Не впервые за это лето, и в этот раз пообещали себе точно не забыть купить сушилку. Но тут вам на глаза попадается газета, из тех что вечно оказываются в почтовом ящике, — и это тоже способ решить вашу проблему. И вот уже бесплатная газета становится конкурентом сушилок производителя А, и Б, и С. А еще можно поставить обувь к батарее — не самый бережный метод, но и это тоже конкурентный способ решить проблему клиента.
Поэтому мы рекомендуем при разработке стратегии развития продукта, помимо анализа текущего поведения пользователей и сравнения с предложениями конкурентов, учитывать любые альтернативы, которые позволят клиенту решить свои задачи.
❓ А какие неочевидные альтернативы есть у вашего продукта?
Управление проектами в Agile - наш новый сертификационный курс для руководителей проектных офисов и менеджеров проектов.
🔹Как совместить Agile с классическим управлением проектами?
🔹Как развивать продукт и планировать проект в гибридной среде
🔹Как взаимодействовать с Agile-командами в классическом проекте и как работать с подрядчиками в Agile-среде
🔹Как управлять стоимостью проектов и выстраивать проектную отчетность в Agile.
Тренинг подготовлен на базе Delivery Management Track и PMI Agile Practice guide и дает знания, необходимые для сдачи экзамена PMI Agile Certified Practitioner (PMI-ACP).
Приходите к нам за новыми знаниями и сертификатом от ICAgile (ICP-APM).
Москва, 24-25 сентября 2019.
Забронировать участие ➡️ https://onagile.ru/trainings/agile-project-management
🔹Как совместить Agile с классическим управлением проектами?
🔹Как развивать продукт и планировать проект в гибридной среде
🔹Как взаимодействовать с Agile-командами в классическом проекте и как работать с подрядчиками в Agile-среде
🔹Как управлять стоимостью проектов и выстраивать проектную отчетность в Agile.
Тренинг подготовлен на базе Delivery Management Track и PMI Agile Practice guide и дает знания, необходимые для сдачи экзамена PMI Agile Certified Practitioner (PMI-ACP).
Приходите к нам за новыми знаниями и сертификатом от ICAgile (ICP-APM).
Москва, 24-25 сентября 2019.
Забронировать участие ➡️ https://onagile.ru/trainings/agile-project-management
Сколько новых идей для своего продукта вы получаете каждую неделю? Уверены, что немало.
Запросы бизнеса всегда превышают возможности команд по их реализации. Как следствие — бэклог постоянно растет, а команда не знает, за что хвататься.
Практика, которая помогает контролировать ситуацию, называется backlog refinement. Что это такое и как ей пользоваться ➡️ https://onagile.ru/trends/lean-startup/backlog-refinement
Запросы бизнеса всегда превышают возможности команд по их реализации. Как следствие — бэклог постоянно растет, а команда не знает, за что хвататься.
Практика, которая помогает контролировать ситуацию, называется backlog refinement. Что это такое и как ей пользоваться ➡️ https://onagile.ru/trends/lean-startup/backlog-refinement
О роли менеджера в Agile
С приходом Agile в компанию менеджеры задаются вопросом, как изменится их роль в новых условиях. В самом Agile роль менеджера детально не рассматривается, поэтому стоит обратиться к более широкому понятию Business Agility, или Гибкость бизнеса. Оно охватывает все сферы управления организацией, в том числе дает понимание процесса эволюции менеджера в лидера.
В новой реальности менеджеру предстоит перейти от директивного управления к созданию среды для эффективной работы сотрудников. В которой они могут сами принимать решения, берут на себя ответственность и ставят цели. Хотим поделиться с вами переводом постера «Обеспечение гибкости бизнеса», который содержит соответствующие принципы лидерства.
Как создать такую среду — тема для отдельного большого разговора, и мы к нему непременно вернемся. А пока: Don’t manage people, manage system.
Скачать постер➡️ onagile.ru/tools
С приходом Agile в компанию менеджеры задаются вопросом, как изменится их роль в новых условиях. В самом Agile роль менеджера детально не рассматривается, поэтому стоит обратиться к более широкому понятию Business Agility, или Гибкость бизнеса. Оно охватывает все сферы управления организацией, в том числе дает понимание процесса эволюции менеджера в лидера.
В новой реальности менеджеру предстоит перейти от директивного управления к созданию среды для эффективной работы сотрудников. В которой они могут сами принимать решения, берут на себя ответственность и ставят цели. Хотим поделиться с вами переводом постера «Обеспечение гибкости бизнеса», который содержит соответствующие принципы лидерства.
Как создать такую среду — тема для отдельного большого разговора, и мы к нему непременно вернемся. А пока: Don’t manage people, manage system.
Скачать постер➡️ onagile.ru/tools
Практика Scrum: как создать бэклог продукта
Итак, у нас есть классная идея для нового продукта, мы знаем наших будущих пользователей и их потребности, которые закроет наш продукт. Можно приступать к работе😉
Но прежде чем Scrum-команда начнет работу в первом спринте, предстоит создать бэклог продукта. Записали для вас пошаговый алгоритм:
https://onagile.ru/trends/lean-startup/how-to-create-product-backlog
А с какими сложностями вы сталкивались при создании бэклога?
Итак, у нас есть классная идея для нового продукта, мы знаем наших будущих пользователей и их потребности, которые закроет наш продукт. Можно приступать к работе😉
Но прежде чем Scrum-команда начнет работу в первом спринте, предстоит создать бэклог продукта. Записали для вас пошаговый алгоритм:
https://onagile.ru/trends/lean-startup/how-to-create-product-backlog
А с какими сложностями вы сталкивались при создании бэклога?