Ближайшие тренинги

Друзья, мы продолжаем делиться проверенными на практике инструментами управления проектами, продуктами и командой.

Каждая программа — это три дня глубокого погружения в Agile под руководством экспертов-практиков. С получением международной сертификации.

1. Фундаментальный курс по Agile и Scrum

Самый широкий по охвату тем тренинг, основной курс по гибким подходам, включающий Scrum и Kanban. Идеальная программа для тех, кто присоединился к scrum-команде или планирует перестроить работу своей команды.

Забронировать участие

Ближайшие группы
21 – 23 сентября
16 – 18 ноября

2. Курс по управлению проектами в Agile

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

Ближайшие группы
19 – 21 октября
14 – 16 декабря
Забронировать участие

3. Продвинутый курс для Скрам-мастеров и руководителей

Более чем на 60% состоящий из практики продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, эффективное проведение командных встреч, командный коучинг и фасилитация.

Ближайшие группы
28 – 30 сентября
23 – 25 ноября
Забронировать участие

4. Продвинутый курс для Владельцев Продуктов

Углубленный курс по созданию, выводу на рынок и развитию продуктов в быстроменяющейся среде. Включая управление ожиданиями заказчиков, работу в agile-команде, проектирование и развитие продукта на основе глубокого понимания потребностей клиентов.

Ближайшая группа
05 – 07 октября
07 – 09 декабря
Забронировать участие

5. Нужен тренинг для группы коллег?

Адаптируем программу специально для вашей команды и проведем онлайн или очно в Мск/Спб.

Для консультации свяжитесь с нами по тел. +7 495 221 87 39 или на info@onagile.ru

Бывают отзывы, которыми просто невозможно не поделиться:)
Спасибо, Елена, у вас отличная команда, с которой очень приятно работать!

«Мы занимаемся научным консалтингом и недавно решили разрабатывать ПО, что подтолкнуло нас организовать тренинг по управлению проектами с использованием Agile-подходов. 

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

Дмитрий отличный тренер, и практик метода, а учиться у практика - особая привилегия. 

Главный результат тренинга - что уже на следующей неделе после тренинга мы создали рабочую группу и работа по новым правилам началась!»

На выходных ребята опубликовали русский перевод эпичного кейса из заказной разработки ПО, когда Hertz заказал у Accenture новый сайт-приложение и в итоге обе большие и известные компании этот проект не осилили, дело закончилось судом.

Рекомендую почитать как тем, кто разрабатывает софт, так и тем, кто его заказывает - я думаю каждый сможет провести много параллелей со своим опытом. Дело было в 2017-19 годах, но сути это не меняет 🙂

https://vc.ru/dev/468325-keys-kak-kompaniya-hertz-zaplatila-agentstvu-accenture-32-milliona-dollarov-za-veb-sayt-kotoryy-tak-i-ne-zapustilsya

Оригинал на английском здесь: https://www.henricodolfing.com/2019/10/case-study-hertz-accenture-website.html

Что интересно, такой сценарий просто невозможен в agile подходе, потому что:

• Весь большой продукт обязательно делится на небольшие, логически разделенные части. Поэтому не нужно ждать конца проекта, чтобы выпустить продукт на первых клиентов, это можно было сделать в случае с hertz уже через месяц-два.
• Вся разработка делится на недельные итерации. Поэтому в конце каждой недели можно увидеть небольшой, но реальный прогресс. Например, на тестовом стенде. Таким образом, мгновенно не заметить отсутствие той же адаптивной верстки, как в кейсе Accenture- Hertz, просто невозможно.
• Задачи ставятся и тз пишется не все и сразу, а «в моменте», непосредственно перед началом разработки. Поэтому любые важные изменения требований от заказчика всегда будут учтены.
• И последнее. Никогда, никогда и ещё раз никогда нельзя использовать fixed price модель разработки.

Приведу пример из собственного опыта - меня пригласили в крупный и известный банк, который на тот момент уже 2.5 года, в сотрудничестве с не менее крупной и известной компанией-аутсорсером, разрабатывал новый продукт для юрлиц. И за 2.5 года не было не только работающей версии у клиентов, но и тестовых версий с хотя бы одним работающим сквозным сценарием. Напоминает кейс Accenture-Hertz, верно?

Только в данном случае вовремя осознали, что нужно срочно менять подход к ведению проекта, перешли на Agile и все стало хорошо (но, конечно, не сразу).

А первое, что я сделал в этом проекте в качестве консультанта - перевёл взаимодействие банка, который уже был готов подавать судебный иск, и подрядчика на T&M контракт.

Конечно, чтобы выпустить успешный продукт мы потратили ещё несколько месяцев. Но уход от Fixed price модели принципиально сделал успех этого проекта возможным. Жаль, что в Hertz не догадались до этого. Ну или не хватило политической воли, чтобы реализовать такой переход.

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

В этом году на тренингах снова часто спрашивают, в чем основное отличие Agile от Lean.

Я обычно объясняю это так.

Другими словами, задача Lean - оптимизировать операционные процессы, задача Agile - оптимизировать разработку новых нетиповых решений за счет коротких циклов проверки гипотез.

Добавите что-нибудь?

Сила продуктовых команд

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

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

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

Сила продуктовой команды в крутости обсуждаемых гипотез и скорости их проверки.

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

Приведу пример вопросов из реальной команды недавно запущенного продукта, которые мы обсуждаем все вместе:

1. Почему у нас только X% клиентов начинают регистрацию?
2. Почему у нас только X1% завершают регистрацию?
3. Почему только Y% зарегистрированных людей делает целевое действие, а Y1% уходит и не возвращается?
4. Почему так мало (до K%) клиентов возвращаются и повторно делают целевое действие?
5. Что не так с СегментомХ клиентов, живущих в СтранеY?

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

Самое частое возражение - «у нас ведь есть продакт и аналитик, это же их работа».

Тем не менее, через несколько недель команду уже, как правило, не узнать.

А у вас был опыт переключения коллег в продуктовое мышление? Как работали с возражениями?

Друзья, привет, обычно мы так не делаем, но 🙂

У вас есть уникальная возможность посетить последний в этом году тренинг "Управление проектами в Agile" с огромной 25% скидкой!

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

13-15 декабря 2022, онлайн

Всего 5 мест с такой скидкой, запишитесь прямо сейчас: https://icagile.ru/agile-project-management.

P.S. Места со скидкой закончились :)

#agile #управлениепроектами #скидка #профессиональноеразвитие

Друзья, привет! Мы решили немного обновить название и концепцию канала в новом году.

Будем по-прежнему публиковать полезные на наш взгляд материалы, но с утроенной энергией и частотой 🙂 А еще добавим бесплатные онлайн встречи по самым интересным темам.

Итак, встречайте - OnAgile Learning Hub.

Кстати, первый пост у нас вышел почти 5 лет назад, 10 мая 2018 года. Если кто-то из наших дорогих подписчиков помнит то время, напишите в комментариях или поставьте сердечко 🙂

Хочу поделиться очень понятной вводной статьей про работу с графиком распределения Leadtime, надеюсь, вам будет интересно прочитать: https://mauvisoft.com/2020/10/08/how-to-read-lead-time-distribution/

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

Самое удобно в этой диаграмме то, что она может работать с любым процессом, будь то Scrum, Kanban-метод или любой другой существующий в компании процесс разработки и поставки.

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

Ну а самое приятное - это через несколько месяцев увидеть, как распределение начинает смещаться влево, в сторону более быстрой поставки результатов.

В дополнение к предыдущему посту про LeadTime, небольшая иллюстрация как именно он считается.

Есть два ключевых понятия.

1. Commitment point (точка Взятия обязательств) - когда мы пообещали, что начали работу над конкретной задачей и соответственно время ожидания в глазах наших заказчиков или клиентов начало идти.

2. Delivery point (Точка Поставки) - когда мы отдаем обещаный результат и заказчик/клиент может его принимать.

По каждой сделанной задаче (прошедшей Delivery Point) мы отмечаем дату, когда задача была сделана, вычитаем из нее дату, когда задача была взята в работу (прошла Commitment Point) и получаем время работы над задачей (LeadTime).

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

Источник иллюстрации: https://www.projectwizards.net/en/blog/2019/01/kanban-corepractices

Друзья, приглашаем вас принять участие в первом вебинаре нашей новой серии, в понедельник 6 марта 18.00.

Рассмотрим на примерах самые актуальные вопросы, связанные с оценкой и планированием задач.

Какие инструменты применить и что сделать, чтобы повысить точность оценки и перестать переживать за озвученные сроки.

Ссылку на подключение опубликуем в этом сообщении за час до вебинара.

До встречи! 6 марта 18.00 мск

(🗓 не забудьте добавить себе в календарь)

Ссылка на запись вебинара: https://www.youtube.com/watch?v=ja_5i0rn1xQ

Новая версия SAFe 6.0 уже успела обрасти правдивыми шутками 🙂

Вообще этот момент очень показательный.

Когда организация задумывается о применении agile / scrum в масштабе и выбирает фреймворк, можно такой вопрос руководителям и задавать.

Вы ОК продолжать жить с теми зависимостями (и следовательно, проблемами), что есть сейчас?
Тогда SAFe подойдет, чтобы улучшить процессы в компании.

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

🚀 Друзья, у нас отличные новости! Мы обновили тренинг для Владельцев продуктов в соответствии с последними трендами рынка, касательно роли РО.

Вгляд бизнеса на роль Владельца продукта меняется: новшества пришли из интерпрайза и SAFe, но уже закрепились в крупном и среднем бизнесе вне зависимости от используемого фреймворка.

ICAgile теперь предлагает разделять обучение для менеждера продукта и для владельца продукта.

Для Product Owner'а ключевые измения состоят в том, что:
✅ теперь он больше фокусируется на выстраивании взаимодействия со стейкхолдерами: как вести диалог, как их изучать, как вовлекать стейкхолдеров
✅ обеспечивает поставку и всё, что с ней связано, за счет смещения фокуса от исследований к технологиям управления и поставки продукта.

Подробнее о новых инструментах, необходимых каждому Владельцу продукта.

Обновленный тренинг для Владельцев продуктов в Agile стартует после майских, 17-19 мая.

👉 Мы добавили еще больше практических упражений: одни из примеров — коммуникационный план работы со стейхолдерами и разработка стратегии для достижения целевых бизнес-показателей
👉 После тренинга вас ждет международный сертификат Agile Product Ownership (ICP-APO)

Не упустите возможность актуализировать ваши знания в соответствии с последними тенденциями рынка 🌟

А для тех, кто не уехал в отпуск и готов принимать решения на праздниках, до 10 мая специальная цена - всего 43 400 руб.

🥇 Забронировать участие

Друзья, хотим поделиться с вами статьей, которая поможет повысить эффективность работы в agile-команде. В ней рассмотрены основные факторы формирования самоорганизованной команды и какие действия помогут ей стать более продуктивной.

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

Чтобы узнать больше, переходите по ссылке и читайте статью. Желаем успешной работы в команде!

Друзья, прямо сейчас мы проводим для одной из школ вебинар по роли QA специалиста в Agile.

Уровень начальный, но подача материала очень интересная!

Update: трансляция закончилась, спасибо тем кто слушал :)

Друзья, привет! Мы сейчас делаем с клиентом проект по внедрению LeSS (скрам в масштабе), хочется поделиться информацией на тему Актуализации бэклога (Product Backlog Refinement, или сокращенно PBR).

Несмотря на то, что многое в LeSS повторяет Скрам, такая вещь как Актуализация бэклога очень сильно отличается, в первую очередь из-за количества участников процесса и необходимого уровня обмена информацией.

Описали три вида PBR и их основные отличия, посмотрите кому интересно. В нашем текущем кейсе мы на первых спринтах начали с Общего PBR, но сейчас уже начали обсуждать многокомандный, как целевой формат проведения.

https://onagile.ru/trends/business-agility/less-product-backlog-refinement