Онлайн-обучение Agile и Scrum — ближайшие курсы на апрель.
Новый для большинства людей формат работы из дома — отличная возможность пересмотреть устоявшиеся паттерны взаимодействия и перестроить процесс работы команды.
Здесь пригодятся практики Agile: работа с мотивацией команды, налаживание прозрачного процесса на основе Scrum и Kanban, техники проведения эффективных и коротких встреч онлайн — все, что работает на скорость получения результата.
Чтобы не терять время в ожидании окончания «нерабочих дней», мы запустили онлайн-обучение.
22-24 апреля - основной курс по гибким подходам — фундаментальный Certified Agile Professional — теперь доступен онлайн.
Программа адаптирована на 3 учебных дня по 4 часа. После обучения вы получаете сертификат от консорциума ICAgile.
https://onagile.ru/trainings/certified-agile-professional
20-21 апреля - наш новый курс Scrum Professional — практическое руководство по переходу к Scrum-процессу.
Если вы решили оптимизировать свои процессы с помощью фреймворка Скрам, эти 2 дня по 4 часа помогут детально разобраться с практиками и инструментами подхода.
https://onagile.ru/trainings/scrum-professional
Приходите сами и приглашайте коллег. При регистрации троих человек из одной компании, третий участник — бесплатно!
Новый для большинства людей формат работы из дома — отличная возможность пересмотреть устоявшиеся паттерны взаимодействия и перестроить процесс работы команды.
Здесь пригодятся практики Agile: работа с мотивацией команды, налаживание прозрачного процесса на основе Scrum и Kanban, техники проведения эффективных и коротких встреч онлайн — все, что работает на скорость получения результата.
Чтобы не терять время в ожидании окончания «нерабочих дней», мы запустили онлайн-обучение.
22-24 апреля - основной курс по гибким подходам — фундаментальный Certified Agile Professional — теперь доступен онлайн.
Программа адаптирована на 3 учебных дня по 4 часа. После обучения вы получаете сертификат от консорциума ICAgile.
https://onagile.ru/trainings/certified-agile-professional
20-21 апреля - наш новый курс Scrum Professional — практическое руководство по переходу к Scrum-процессу.
Если вы решили оптимизировать свои процессы с помощью фреймворка Скрам, эти 2 дня по 4 часа помогут детально разобраться с практиками и инструментами подхода.
https://onagile.ru/trainings/scrum-professional
Приходите сами и приглашайте коллег. При регистрации троих человек из одной компании, третий участник — бесплатно!
Частый вопрос при внедрении Scrum - в конце спринта обязательно должен быть инкремент продукта, а у нас еще ничего ценного для клиентов или внутренних заказчиков не готово, как быть?
Например, это первые несколько спринтов команды или работа над ценной для клиентов фичей занимает несколько недель.
Мне очень нравится определение Potentially Shippable Product (PSP) - Продукт, который может быть поставлен. Первый раз я услышал о нем в 2013 году от Алистера Коберна, одного из "отцов" Agile.
Очень хорошо этот термин раскрыт в описании LeSS, рекомендую: https://less.works/less/framework/potentially-shippable-product-increment.html
Potentially shippable is a statement about the quality of the software and not about the value or the marketability of the software.
Например, это первые несколько спринтов команды или работа над ценной для клиентов фичей занимает несколько недель.
Мне очень нравится определение Potentially Shippable Product (PSP) - Продукт, который может быть поставлен. Первый раз я услышал о нем в 2013 году от Алистера Коберна, одного из "отцов" Agile.
Очень хорошо этот термин раскрыт в описании LeSS, рекомендую: https://less.works/less/framework/potentially-shippable-product-increment.html
Potentially shippable is a statement about the quality of the software and not about the value or the marketability of the software.
Друзья, есть 1 бесплатное место для представителя НКО на онлайн-тренинг Scrum Professional 20-21 апреля 🚀
Подробно разберемся, как применять фреймворк, запустить скрам-команду и получить впечатляющие результаты;)
Что еще вас ждет интересного: https://onagile.ru/trainings/scrum-professional
Обучение с 14 до 18 на платформе zoom.us
UPD Место забронировано🙂
Подробно разберемся, как применять фреймворк, запустить скрам-команду и получить впечатляющие результаты;)
Что еще вас ждет интересного: https://onagile.ru/trainings/scrum-professional
Обучение с 14 до 18 на платформе zoom.us
UPD Место забронировано🙂
Привет! Мы возвращаемся с новой порцией историй о нашем опыте применения Agile в российских компаниях и реалиях.
Все это время мы продолжали лидировать Agile-преобразования у наших клиентов — это 6 компаний в четырех разных отраслях, помогли им запустить 23 новых команды и провели обучение 18 групп по темам, связанным с Agile как культурой работы, особенностям Scrum-подхода, Kanban-методу и разработке продуктов в условиях быстро меняющейся среды.
Все это время мы продолжали лидировать Agile-преобразования у наших клиентов — это 6 компаний в четырех разных отраслях, помогли им запустить 23 новых команды и провели обучение 18 групп по темам, связанным с Agile как культурой работы, особенностям Scrum-подхода, Kanban-методу и разработке продуктов в условиях быстро меняющейся среды.
Историй накопилось много, поэтому вопрос — какие материалы вам было бы интереснее всего здесь читать?
Anonymous Poll
41%
Кейсы применения Agile
22%
Разбор частых ошибок
12%
Теория Scrum и Канбан-метода
23%
Agile на уровне организации
1%
Ответы на вопросы из комментариев
1%
Другое (напишу в комментариях)
Спасибо вам за ответы, будем стараться писать полезный материал. А вы нам помогайте 🙂
Сегодня - разбор одной из частых ошибок - оценки задач в человекочасах.
Удивительно, что многие команды в разработке ПО продолжают использовать оценку задач на основе человеко-часов и даже человеко-дней.
Например, работы по отдельной задаче команда оценивает так: аналитику нужно 2 дня, разработчику 6 дней, тестировщику 3 дня. Получаем общую сумму в 11 дней, кладем на календарь, получаем дату окончания работ = день начала + 11 дней.
И примерно в 100% случаев результат по задаче выдается позже озвученной даты и наши заказчики начинают становиться недовольными.
В чем причина? Как минимум, при такой оценке не учитываются временные затраты на встречи, ожидание, помощь коллегам и даже фикс ошибок, найденных тестировщиком. Все эти активности занимают достаточно большое количество времени и общий срок по задаче улетает за 11 дней.
Есть два способа улучшить точность оценки, не сделав ее процесс сложнее.
1. Использовать понятие "идеальный час" - это час рабочего времени, когда мы в субботу сидим одни в комнате, все прочие дела сделаны, в наушниках играет любимая музыка и мы максимально погружены в решение задачи без единого отвлекающего фактора.
То есть процесс оценки в часах обычно выглядит так - "если тебя никто не будет отвлекать, ты сядешь и целиком погрузишься в задачу - сколько часов тебе потребуется, чтобы ее сделать?"
Теперь остается умножить полученную оценку на некий коэффициент, отражающий соотношение идеального времени к реальному в вашей команде, например, на 1.4.
Раньше такой коэффициент называли фокус-фактор, но поскольку в целом оценка в часах признана мировым сообществом слишком неточной, с нее так или иначе уходят на следующий способ.
2. Самая точная и при этом быстрая оценка задач (вернее сказать, пользовательских историй) - в сторипоинтах.
Это относительные размеры историй друг к другу, без привязки к часам, работам определенной роли (анализ, разработка, тестирование) и вообще календарю.
Например, задача по выпуску виртуальной карты может иметь оценку в 13 поинтов, а задача по отображению ее реквизитов - оценку в 3 поинта.
Что это для нас значит?
Что реквизиты примерно в 4 раза проще выпуска карты и очевидно более определенные с точки зрения требований, зависимостей и возможных рисков.
Предположим команда в двухнедельный спринт делает историй в среднем на 20 поинтов. Исходя из этого можно научиться достаточно точно планировать как объем спринта, так и сроки по набору историй из бэклога, и, конечно, выполнять обязательства.
Сегодня - разбор одной из частых ошибок - оценки задач в человекочасах.
Удивительно, что многие команды в разработке ПО продолжают использовать оценку задач на основе человеко-часов и даже человеко-дней.
Например, работы по отдельной задаче команда оценивает так: аналитику нужно 2 дня, разработчику 6 дней, тестировщику 3 дня. Получаем общую сумму в 11 дней, кладем на календарь, получаем дату окончания работ = день начала + 11 дней.
И примерно в 100% случаев результат по задаче выдается позже озвученной даты и наши заказчики начинают становиться недовольными.
В чем причина? Как минимум, при такой оценке не учитываются временные затраты на встречи, ожидание, помощь коллегам и даже фикс ошибок, найденных тестировщиком. Все эти активности занимают достаточно большое количество времени и общий срок по задаче улетает за 11 дней.
Есть два способа улучшить точность оценки, не сделав ее процесс сложнее.
1. Использовать понятие "идеальный час" - это час рабочего времени, когда мы в субботу сидим одни в комнате, все прочие дела сделаны, в наушниках играет любимая музыка и мы максимально погружены в решение задачи без единого отвлекающего фактора.
То есть процесс оценки в часах обычно выглядит так - "если тебя никто не будет отвлекать, ты сядешь и целиком погрузишься в задачу - сколько часов тебе потребуется, чтобы ее сделать?"
Теперь остается умножить полученную оценку на некий коэффициент, отражающий соотношение идеального времени к реальному в вашей команде, например, на 1.4.
Раньше такой коэффициент называли фокус-фактор, но поскольку в целом оценка в часах признана мировым сообществом слишком неточной, с нее так или иначе уходят на следующий способ.
2. Самая точная и при этом быстрая оценка задач (вернее сказать, пользовательских историй) - в сторипоинтах.
Это относительные размеры историй друг к другу, без привязки к часам, работам определенной роли (анализ, разработка, тестирование) и вообще календарю.
Например, задача по выпуску виртуальной карты может иметь оценку в 13 поинтов, а задача по отображению ее реквизитов - оценку в 3 поинта.
Что это для нас значит?
Что реквизиты примерно в 4 раза проще выпуска карты и очевидно более определенные с точки зрения требований, зависимостей и возможных рисков.
Предположим команда в двухнедельный спринт делает историй в среднем на 20 поинтов. Исходя из этого можно научиться достаточно точно планировать как объем спринта, так и сроки по набору историй из бэклога, и, конечно, выполнять обязательства.
Продолжая тему с оценками, давайте посмотрим, в чем вообще проблема с ними. Почему в общем случае крайне сложно дать точную оценку?
(Применимо к оценке работ так называемого умственного труда, knowledge work).
1. В вариативной среде, которой свойственная большая неопределенность (например, создание нового продукта), при этом работая командой в несколько человек, физически невозможно заранее предугадать все факторы, которые возникнут в процессе работы и повлияют на ее длительность.
2. Требования, которые у нас есть на старте - не описывают будущий продукт на 100%, какими бы объемными и детальными они ни были. В отличие от, например, изготовления детали по чертежу или строительство дома по готовой проектной документации.
3. И самое главное - проблема в ДНК процесса оценки.
Когда нас просят что-то оценить, нам говорят буквально следующее «На основе информации, которая есть у вас сейчас и вашего опыта, когда, как вам кажется, вы могли бы это сделать?».
Мы говорим (применяя любую методику оценки), например, через 20 дней, или к 17 ноября. И это тот оценочный срок, который нас попросили назвать.
Но в ту же секунду, те кто нас спрашивает о сроках (заказчики), воспринимают его как дедлайн, под который мы только что сами подписались. Отсюда и возникают недоверие и напряженность в отношениях между заказчиками и командой. И, конечно, сорванные сроки.
Поэтому нужно искать кардинально иные способы прогнозирования сроков поставки результата.
Дальше будут еще два способа, как можно договариваться с заказчиками, не прибегая к привычной экспертной оценке.
И у меня вопрос - а как вы решаете проблему со сроками в своих командах? Напишите, пожалуйста, в комментариях.
(Применимо к оценке работ так называемого умственного труда, knowledge work).
1. В вариативной среде, которой свойственная большая неопределенность (например, создание нового продукта), при этом работая командой в несколько человек, физически невозможно заранее предугадать все факторы, которые возникнут в процессе работы и повлияют на ее длительность.
2. Требования, которые у нас есть на старте - не описывают будущий продукт на 100%, какими бы объемными и детальными они ни были. В отличие от, например, изготовления детали по чертежу или строительство дома по готовой проектной документации.
3. И самое главное - проблема в ДНК процесса оценки.
Когда нас просят что-то оценить, нам говорят буквально следующее «На основе информации, которая есть у вас сейчас и вашего опыта, когда, как вам кажется, вы могли бы это сделать?».
Мы говорим (применяя любую методику оценки), например, через 20 дней, или к 17 ноября. И это тот оценочный срок, который нас попросили назвать.
Но в ту же секунду, те кто нас спрашивает о сроках (заказчики), воспринимают его как дедлайн, под который мы только что сами подписались. Отсюда и возникают недоверие и напряженность в отношениях между заказчиками и командой. И, конечно, сорванные сроки.
Поэтому нужно искать кардинально иные способы прогнозирования сроков поставки результата.
Дальше будут еще два способа, как можно договариваться с заказчиками, не прибегая к привычной экспертной оценке.
И у меня вопрос - а как вы решаете проблему со сроками в своих командах? Напишите, пожалуйста, в комментариях.
Третий подход к оценке задач, NoEstimates — один из самых интересных.
Что если перестать оценивать задачи вообще?
Здесь нужно оговориться, что если ваш процесс оценки работает хорошо, то данный метод, наверное, будет неактуален.
А вот для новых команд или там, где сроки часто срываются, он работает отлично.
Лично я его применяю абсолютно каждый раз, когда начинаю работать с новой командой.
«Но как тогда отвечать заказчикам по срокам?» — спросите вы.
Несмотря на то, что с первого раза глубина этой идеи воспринимается непросто, давайте посмотрим, как и почему этот подход может работать лучше, чем два предыдущих.
Зачем вообще заказчики интересуются сроками?
Основных причин две:
1. Нужен ориентир по дате, когда будет результат, чтобы планировать другие активности с этим результатом связанные (использование продукта, продажи, маркетинг и тп).
2. Нужен инструмент контроля/мотивации исполнителей, чтобы их работа не тянулась слишком долго.
Но если те даты, которые называются, регулярно сдвигаются, то мы все равно не получим ничего, кроме негатива со стороны заказчиков. Который, безусловно, перерастет в усложнение отношений между заказчиком и исполнителем (бизнесом и разработкой).
Знакомая ситуация?
В этом случае лучшее, что можно придумать, — это отказаться от процесса оценки (в человеко-часах, днях, месяцах) и сфокусировать общие усилия на двух вещах:
1. Наладить конструктивное взаимодействие между собой, поставив целью разработку продукта на первое место.
2. Упорядочить задачи/элементы бэклога в единую очередь (1, 2, 3, 4..) и фокусировать усилия команды на максимально быструю поставку результата по каждому из них последовательно.
Как только результат на выходе станет появляться чаще и быстрее (а обычно это случается в течение 2-4 недель), отношения с заказчиком автоматически перейдут в новое русло конструктивных партнерских отношений. И потребность в оценке в часах пропадет полностью.
The basic idea, as I understand it, is that it is possible to do small chunks of work incrementally, leading as rapidly as possible to a desired shippable product, and that when you do that there is no need to do much of anything in the way of estimating stories or the project.
Ron Jeffries, 2013, https://ronjeffries.com/xprog/articles/the-noestimates-movement/
Конечно, через какое-то время снова захочется прогнозировать даты, например, дату релиза — но здесь уже поможет следующий вариант оценки, о котором я расскажу дальше. И это даже близко не человеко-часы и даже не сторипоинты.
На личном опыте могу сказать, что такой подход работает даже в аутсорсинговых проектах. Но с одним ограничением — контракт с заказчиком должен быть T&M (или его нужно перевести в такой, даже если сейчас середина проекта).
Если тема интересная, задавайте вопросы комментариях.
Что если перестать оценивать задачи вообще?
Здесь нужно оговориться, что если ваш процесс оценки работает хорошо, то данный метод, наверное, будет неактуален.
А вот для новых команд или там, где сроки часто срываются, он работает отлично.
Лично я его применяю абсолютно каждый раз, когда начинаю работать с новой командой.
«Но как тогда отвечать заказчикам по срокам?» — спросите вы.
Несмотря на то, что с первого раза глубина этой идеи воспринимается непросто, давайте посмотрим, как и почему этот подход может работать лучше, чем два предыдущих.
Зачем вообще заказчики интересуются сроками?
Основных причин две:
1. Нужен ориентир по дате, когда будет результат, чтобы планировать другие активности с этим результатом связанные (использование продукта, продажи, маркетинг и тп).
2. Нужен инструмент контроля/мотивации исполнителей, чтобы их работа не тянулась слишком долго.
Но если те даты, которые называются, регулярно сдвигаются, то мы все равно не получим ничего, кроме негатива со стороны заказчиков. Который, безусловно, перерастет в усложнение отношений между заказчиком и исполнителем (бизнесом и разработкой).
Знакомая ситуация?
В этом случае лучшее, что можно придумать, — это отказаться от процесса оценки (в человеко-часах, днях, месяцах) и сфокусировать общие усилия на двух вещах:
1. Наладить конструктивное взаимодействие между собой, поставив целью разработку продукта на первое место.
2. Упорядочить задачи/элементы бэклога в единую очередь (1, 2, 3, 4..) и фокусировать усилия команды на максимально быструю поставку результата по каждому из них последовательно.
Как только результат на выходе станет появляться чаще и быстрее (а обычно это случается в течение 2-4 недель), отношения с заказчиком автоматически перейдут в новое русло конструктивных партнерских отношений. И потребность в оценке в часах пропадет полностью.
The basic idea, as I understand it, is that it is possible to do small chunks of work incrementally, leading as rapidly as possible to a desired shippable product, and that when you do that there is no need to do much of anything in the way of estimating stories or the project.
Ron Jeffries, 2013, https://ronjeffries.com/xprog/articles/the-noestimates-movement/
Конечно, через какое-то время снова захочется прогнозировать даты, например, дату релиза — но здесь уже поможет следующий вариант оценки, о котором я расскажу дальше. И это даже близко не человеко-часы и даже не сторипоинты.
На личном опыте могу сказать, что такой подход работает даже в аутсорсинговых проектах. Но с одним ограничением — контракт с заказчиком должен быть T&M (или его нужно перевести в такой, даже если сейчас середина проекта).
Если тема интересная, задавайте вопросы комментариях.
Расписание тренингов до конца года:
Пока пора онлайна и можно подключиться из дома, в каком бы городе вы ни находились, — отличная возможность усилить компетенции перед выходом в офис и ответить на накопившиеся вопросы.
* Онлайн, 14 часов интенсивных занятий за 3 дня, группа до 12 человек.
* Практические упражнения в miro, тренинг проходит в zoom.
* Международный сертификат от консорциума ICAgile по окончании тренинга.
* Делимся практическим опытом применения Agile.
Фундаментальный Certified Agile Professional — основной курс по гибким подходам, включающий Scrum и Kanban.
23-25 ноября, 16-18 декабря
https://onagile.ru/trainings/certified-agile-professional
Продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, командный коучинг и фасилитация, — Advanced Scrum Master & Agile Coach.
18-20 ноября
https://onagile.ru/trainings/advanced-scrum-master-and-agile-coach
Управление проектами и их эволюционирование в гибкой среде — Agile Project Management.
2-4 декабря https://onagile.ru/trainings/agile-project-management
Присоединяйтесь, будет интересно!
Пока пора онлайна и можно подключиться из дома, в каком бы городе вы ни находились, — отличная возможность усилить компетенции перед выходом в офис и ответить на накопившиеся вопросы.
* Онлайн, 14 часов интенсивных занятий за 3 дня, группа до 12 человек.
* Практические упражнения в miro, тренинг проходит в zoom.
* Международный сертификат от консорциума ICAgile по окончании тренинга.
* Делимся практическим опытом применения Agile.
Фундаментальный Certified Agile Professional — основной курс по гибким подходам, включающий Scrum и Kanban.
23-25 ноября, 16-18 декабря
https://onagile.ru/trainings/certified-agile-professional
Продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, командный коучинг и фасилитация, — Advanced Scrum Master & Agile Coach.
18-20 ноября
https://onagile.ru/trainings/advanced-scrum-master-and-agile-coach
Управление проектами и их эволюционирование в гибкой среде — Agile Project Management.
2-4 декабря https://onagile.ru/trainings/agile-project-management
Присоединяйтесь, будет интересно!
OnAgile Consulting
Вы освоите современные подходы к управлению Agile, Scrum, Kanban, с получением сертификата международного консорциума ICAgile,…
🚀 Тренинг по Agile, обучение Scrum и методу Kanban
Частый вопрос: как оценить работу Скрам-мастера? Для быстрой оценки, будь то полугодовой ассесмент, итоги испытательного срока или просто желание менеджера держать руку на пульсе внедрения процессных изменений в компании, хорошо зарекомендовали себя 3 критерия : https://onagile.ru/trends/agile/scrum-master-assessment
А как вы определеяете, насколько хорошо ваш SM делает свою работу? Расскажите в комментариях.
А как вы определеяете, насколько хорошо ваш SM делает свою работу? Расскажите в комментариях.
Вам было бы интересно узнать, на что обратить внимание при собеседовании Скрам-мастера?
Anonymous Poll
69%
Да
7%
Нет
32%
Я Скрам-мастер, и мне тоже интересно
Анализ стейкхолдеров проекта
Несмотря на то, что в базовом варианте работа agile-команды не предполагает такую процедуру как Управление проектом (как и саму роль менеджера проекта), часто бывает полезно применять хорошие практики, наработанные в рамках стандартных процедур управления проектами.
Одна из них — анализ стейкхолдеров проекта.
https://telegra.ph/Analiz-stejkholderov-proekta-10-02
Несмотря на то, что в базовом варианте работа agile-команды не предполагает такую процедуру как Управление проектом (как и саму роль менеджера проекта), часто бывает полезно применять хорошие практики, наработанные в рамках стандартных процедур управления проектами.
Одна из них — анализ стейкхолдеров проекта.
https://telegra.ph/Analiz-stejkholderov-proekta-10-02
Telegraph
Анализ стейкхолдеров проекта
Когда применять: при старте нового проекта / новой команды, когда есть много заинтересованных в процессе и конечном результате лиц, причем разного уровня корпоративной иерархии и часто из различных компаний. Что сделать: собраться командой вместе с владельцем…
Как проводить встречи, если вы менеджер и все ждут вашего решения?
Интересный вопрос, который нам задали на тренинге.
Здесь мы сталкиваемся с одной из организационных дисфункций, которая особенно ярко проявляется в консервативной корпоративной среде, где принято не перечить начальникам.
Что делать?
1. Как руководителю, нужно менять культуру: максимально вовлекаться в процесс работы команды и лично ходить на встречи. Чтобы команда начала воспринимать вас не как начальника, а как человека, который участвует в процессе работы и готов способствовать ему.
Пока к вам относятся исключительно как к начальнику — без акцента на сотрудничество — невозможно эффективно проводить командные встречи.
Это одна из тех проблем, с которой борется Agile. Часто сотрудники привыкли к ситуации, когда им на планерке говорят, что делать, и сами не спешат вовлекаться в принятие решений.
Поэтому, если вы руководитель, лучше наймите стороннего фасилитатора, чтобы он для вас проводил встречи.
2. Пока идет процесс изменения культуры компании, фокусируйтесь на том, чтобы не присутствовать лично на всех встречах — дайте команде почувствовать, что они могут сами принимать решения. Иначе вы столкнетесь с тем, что будете и принимать решения, и исполнять их, и все будет исключительно от вас зависеть.
Согласитесь, это хорошая цель — уйти от микроменеджмента и посвятить освободившееся время более важным задачам.
Интересный вопрос, который нам задали на тренинге.
Здесь мы сталкиваемся с одной из организационных дисфункций, которая особенно ярко проявляется в консервативной корпоративной среде, где принято не перечить начальникам.
Что делать?
1. Как руководителю, нужно менять культуру: максимально вовлекаться в процесс работы команды и лично ходить на встречи. Чтобы команда начала воспринимать вас не как начальника, а как человека, который участвует в процессе работы и готов способствовать ему.
Пока к вам относятся исключительно как к начальнику — без акцента на сотрудничество — невозможно эффективно проводить командные встречи.
Это одна из тех проблем, с которой борется Agile. Часто сотрудники привыкли к ситуации, когда им на планерке говорят, что делать, и сами не спешат вовлекаться в принятие решений.
Поэтому, если вы руководитель, лучше наймите стороннего фасилитатора, чтобы он для вас проводил встречи.
2. Пока идет процесс изменения культуры компании, фокусируйтесь на том, чтобы не присутствовать лично на всех встречах — дайте команде почувствовать, что они могут сами принимать решения. Иначе вы столкнетесь с тем, что будете и принимать решения, и исполнять их, и все будет исключительно от вас зависеть.
Согласитесь, это хорошая цель — уйти от микроменеджмента и посвятить освободившееся время более важным задачам.
Вышла новая версия Scrum 2020
Коротко: это все тот же Scrum. Если вы не занимаетесь процессами на ежедневной основе, кардинальные отличия заметить будет непросто.
Однако есть несколько важных вещей, которые обновились, и мы очень хотим обсудить их с вами:
1. Владелец продукта и Разработчики стали единой командой.
2. Владелец продукта и Скрам-мастер — больше не роли.
3. Владелец продукта может выступать Разработчиком.
4. У продукта, который разрабатывает команда, должна быть определена цель.
5. Уменьшена детализация инструментов фреймворка.
Подробности по каждому пункту в статье на нашем сайте: https://onagile.ru/trends/agile/scrum-2020
Коротко: это все тот же Scrum. Если вы не занимаетесь процессами на ежедневной основе, кардинальные отличия заметить будет непросто.
Однако есть несколько важных вещей, которые обновились, и мы очень хотим обсудить их с вами:
1. Владелец продукта и Разработчики стали единой командой.
2. Владелец продукта и Скрам-мастер — больше не роли.
3. Владелец продукта может выступать Разработчиком.
4. У продукта, который разрабатывает команда, должна быть определена цель.
5. Уменьшена детализация инструментов фреймворка.
Подробности по каждому пункту в статье на нашем сайте: https://onagile.ru/trends/agile/scrum-2020
4 способа совместить в спринте работу по проекту и поддержку
Многим ИТ-командам знакома ситуация: берем задачи в спринт и не успеваем их завершить, потому что часть времени ушла на поддержку уже существующего продукта.
Понятно, что если задачи по поддержке появляются регулярно, при планировании спринта нужно заложить резерв на их выполнение.
Для этого есть четыре основных паттерна:
1. Выделить процент из объема задач, которые команда выполняет за спринт. (Объем оценивается, например, в сторипойнтах.) Соотношение в каждом проекте будет свое и определяется экспериментально.
Соответственно, на планировании спринта мы берем в бэклог задачи суммарным объемом, например, в 70% производительности команды. А 30% оставляем на поддержку.
2. Зарезервировать время. Это не обязательно фиксированные часы — просто мы понимаем, что, например, 2 часа в день уходят на поддержку. Значит на новые фичи остается 6 часов.
Казалось бы, очень просто, но этот паттерн здорово помогает реалистично оценивать силы и не брать в работу больше, чем мы реально способны сделать за казалось бы «целый рабочий день».
3. Выбрать «дежурного по багам». То есть участника команды, который в данном спринте фиксит всё. При планировании спринта мы этого человека не учитываем в командной производительности.
4. Провести отдельное ретро и всей командой порассуждать, почему у нас столько инцидентов? Можем ли мы уменьшить их количество?
Этот паттерн не отменяет предыдущих и, скорее, может стать первым шагом. Такая ретроспектива еще и очень полезна с точки зрения изменения парадигмы: выйти за пределы своего списка задач и вместе с коллегами подумать о продукте и процессах.
А как вы учитываете поддержку при планировании?
Многим ИТ-командам знакома ситуация: берем задачи в спринт и не успеваем их завершить, потому что часть времени ушла на поддержку уже существующего продукта.
Понятно, что если задачи по поддержке появляются регулярно, при планировании спринта нужно заложить резерв на их выполнение.
Для этого есть четыре основных паттерна:
1. Выделить процент из объема задач, которые команда выполняет за спринт. (Объем оценивается, например, в сторипойнтах.) Соотношение в каждом проекте будет свое и определяется экспериментально.
Соответственно, на планировании спринта мы берем в бэклог задачи суммарным объемом, например, в 70% производительности команды. А 30% оставляем на поддержку.
2. Зарезервировать время. Это не обязательно фиксированные часы — просто мы понимаем, что, например, 2 часа в день уходят на поддержку. Значит на новые фичи остается 6 часов.
Казалось бы, очень просто, но этот паттерн здорово помогает реалистично оценивать силы и не брать в работу больше, чем мы реально способны сделать за казалось бы «целый рабочий день».
3. Выбрать «дежурного по багам». То есть участника команды, который в данном спринте фиксит всё. При планировании спринта мы этого человека не учитываем в командной производительности.
4. Провести отдельное ретро и всей командой порассуждать, почему у нас столько инцидентов? Можем ли мы уменьшить их количество?
Этот паттерн не отменяет предыдущих и, скорее, может стать первым шагом. Такая ретроспектива еще и очень полезна с точки зрения изменения парадигмы: выйти за пределы своего списка задач и вместе с коллегами подумать о продукте и процессах.
А как вы учитываете поддержку при планировании?
Как договариваться со стейкхолдерами о сроках в agile-среде
Итак, команда начинает работать инкрементами и от традиционного планирования переходит к гибкому. Стейкхолдеров же по-прежнему интересует, когда будет поставлен тот или иной функционал. Как быть?
Мы рекомендуем в качестве инструмента визуализации для стейкхолдеров использовать дорожную карту продукта. Вот как это работает:
🔹Команда мыслит инкрементами и ориентируется на Цель продукта.
Это позволяет крупными мазками наметить, как мы будем двигаться к продуктовой цели.
🔹Создаем роадмап — например, на полгода. И отражаем на ней все ключевые точки/инкременты. То есть мыслим не числами (когда будет поставлен конкретный функционал), а очередностью.
🔹Стейкхолдер хочет получить определенный функционал быстро? Двигаем эту фичу в верх списка, и она попадает в один из ближайших спринтов.
Занимается созданием и актуализацией роадмап Владелец продукта. Очередность инкрементов определяется вместе со стейкхолдерами.
Такой подход наверняка понравится и команде: мыслить месяцами удобно, а четкое понимание, что мы делаем в январе, что в феврале и тд., помогает фокусироваться на продукте и выстраивать плавный рабочий процесс.
Итак, команда начинает работать инкрементами и от традиционного планирования переходит к гибкому. Стейкхолдеров же по-прежнему интересует, когда будет поставлен тот или иной функционал. Как быть?
Мы рекомендуем в качестве инструмента визуализации для стейкхолдеров использовать дорожную карту продукта. Вот как это работает:
🔹Команда мыслит инкрементами и ориентируется на Цель продукта.
Это позволяет крупными мазками наметить, как мы будем двигаться к продуктовой цели.
🔹Создаем роадмап — например, на полгода. И отражаем на ней все ключевые точки/инкременты. То есть мыслим не числами (когда будет поставлен конкретный функционал), а очередностью.
🔹Стейкхолдер хочет получить определенный функционал быстро? Двигаем эту фичу в верх списка, и она попадает в один из ближайших спринтов.
Занимается созданием и актуализацией роадмап Владелец продукта. Очередность инкрементов определяется вместе со стейкхолдерами.
Такой подход наверняка понравится и команде: мыслить месяцами удобно, а четкое понимание, что мы делаем в январе, что в феврале и тд., помогает фокусироваться на продукте и выстраивать плавный рабочий процесс.
Нужен ли технический бэкграунд Скрам-мастеру?
Короткий ответ - зависит от этапа развития команды.
Если команда только запускается, наличие у Скрам-мастера технического бэкграунда будет плюсом. Практика показывает, что при запуске команда нередко обращается к Скрам-мастеру с проблемами, касающимися реализации (например, не можем поставить стенд для микросервисов) или коммуникации с бизнесом. И важно, чтобы Скрам-мастер понимал, какого плана проблема и как помочь команде ее решить.
По мере взросления команды это влияние снижается и практически не имеет значения, когда команда достигла определенной самоорганизации.
А что делать при найме Скрам-мастера?
Идеальный вариант - выбрать Скрам-мастера из состава команды, чтобы человек совмещал свою обычную роль в команде и роль скрам-мастера.
Но даже если вы берете человека с рынка, его технический бэкграунд должен стать важным плюсом при выборе кандидата.
Даже компаниям в активной фазе трансформации, когда сразу формируются десятки команд и соответственно десятки вакансий, мы рекомендуем набирать Скрам-мастеров не всем скопом (частый аргумент здесь — «потому что в Сбере их сотни»), а все-таки ориентируясь на конкретные команды и их состав.
Повторимся, что в идеале, Скрам-мастер должен участвовать в разработке продукта наравне с остальными участниками команды, а не просто быть Мастером Скрама.
Короткий ответ - зависит от этапа развития команды.
Если команда только запускается, наличие у Скрам-мастера технического бэкграунда будет плюсом. Практика показывает, что при запуске команда нередко обращается к Скрам-мастеру с проблемами, касающимися реализации (например, не можем поставить стенд для микросервисов) или коммуникации с бизнесом. И важно, чтобы Скрам-мастер понимал, какого плана проблема и как помочь команде ее решить.
По мере взросления команды это влияние снижается и практически не имеет значения, когда команда достигла определенной самоорганизации.
А что делать при найме Скрам-мастера?
Идеальный вариант - выбрать Скрам-мастера из состава команды, чтобы человек совмещал свою обычную роль в команде и роль скрам-мастера.
Но даже если вы берете человека с рынка, его технический бэкграунд должен стать важным плюсом при выборе кандидата.
Даже компаниям в активной фазе трансформации, когда сразу формируются десятки команд и соответственно десятки вакансий, мы рекомендуем набирать Скрам-мастеров не всем скопом (частый аргумент здесь — «потому что в Сбере их сотни»), а все-таки ориентируясь на конкретные команды и их состав.
Повторимся, что в идеале, Скрам-мастер должен участвовать в разработке продукта наравне с остальными участниками команды, а не просто быть Мастером Скрама.
Нужен ли Скрам-мастеру технический бэкграунд (продолжение)
Предыдущий пост на эту тему вызвал активное обсуждение. Вопрос действительно многогранный, давайте разбираться дальше;) О деталях выбора Скрам-мастера рассказывает старший консультант OnAgile Consulting Артём Гринякин.
Выбрать Скрам-мастера из команды или привлечь специалиста со стороны — это всегда дилемма. И как у любой монеты есть орел и решка, так и в этом вопросе стоит разобраться и посмотреть, какие плюсы и минусы имеются в наличии.
Скрам-мастер выбирается или назначается из участников команды (совмещение с ИТ-позицией):
❎ Минусы:
· Непонимание своей роли и недостаточная погруженность в Agile-подходы
· Потенциальные конфликты в команде по принципу «почему он, а не я?»
· Отсутвие опыта в решении конфликтных ситуаций
· Невозможность предоставить сервис поддержки Владельцу продукта
· Отсутствие навыков фасилитации, коучинга, обучения
· Отсутствие ответов на базовые вопросы, которые часто возникают у новых команд
· Необходимость постоянно балансировать между ИТ-ролью и Скрам-мастерством
· Отсутвие мутации на уровне команды. Это теория, которая подразумевает, что из одного набора генов (специалистов) невозможно качественно вырасти без привлечения свежей крови (мутации) — новых специалистов, не входящих в состав изначальной группы.
✅ Плюсы:
· Погруженность в предметную область
· Более эффективное использование ресурсов с точки зрения бизнеса
Скрам-мастер привлекается со стороны:
❎ Минусы:
· Временное непонимание предметной области
· Время на адаптацию и первоначальный анализ
✅ Плюсы:
· Новые знания, подходы, которые раньше не присутствовали в организации
· Навыки фасилитации, коучинга, обучения
· Вариативность в методах и практиках
· Уменение ответить на базовые вопросы
· Отсутствие конфликта интересов
· Возможность погрузиться в процесс развития команды и организации
· Предоставление сервиса поддержки Владельцу продукта
· Возможность балансирования Бизнеса и ИТ
· Умение решать конфликты
· Возможность взять до 3 команд (актуально для LeSS и производных от SAFe, где считается оптимальным использование одного Скрам-мастера на 3 команды. В немасшабируемом Scrum такой подход не приветствуется)
Важный момент: чем менее зрелая команда, тем в большем вовлечении Скрам-мастера она нуждается. И соответственно, с развитием это внимание, выраженное в часах, снижается.
Предыдущий пост на эту тему вызвал активное обсуждение. Вопрос действительно многогранный, давайте разбираться дальше;) О деталях выбора Скрам-мастера рассказывает старший консультант OnAgile Consulting Артём Гринякин.
Выбрать Скрам-мастера из команды или привлечь специалиста со стороны — это всегда дилемма. И как у любой монеты есть орел и решка, так и в этом вопросе стоит разобраться и посмотреть, какие плюсы и минусы имеются в наличии.
Скрам-мастер выбирается или назначается из участников команды (совмещение с ИТ-позицией):
❎ Минусы:
· Непонимание своей роли и недостаточная погруженность в Agile-подходы
· Потенциальные конфликты в команде по принципу «почему он, а не я?»
· Отсутвие опыта в решении конфликтных ситуаций
· Невозможность предоставить сервис поддержки Владельцу продукта
· Отсутствие навыков фасилитации, коучинга, обучения
· Отсутствие ответов на базовые вопросы, которые часто возникают у новых команд
· Необходимость постоянно балансировать между ИТ-ролью и Скрам-мастерством
· Отсутвие мутации на уровне команды. Это теория, которая подразумевает, что из одного набора генов (специалистов) невозможно качественно вырасти без привлечения свежей крови (мутации) — новых специалистов, не входящих в состав изначальной группы.
✅ Плюсы:
· Погруженность в предметную область
· Более эффективное использование ресурсов с точки зрения бизнеса
Скрам-мастер привлекается со стороны:
❎ Минусы:
· Временное непонимание предметной области
· Время на адаптацию и первоначальный анализ
✅ Плюсы:
· Новые знания, подходы, которые раньше не присутствовали в организации
· Навыки фасилитации, коучинга, обучения
· Вариативность в методах и практиках
· Уменение ответить на базовые вопросы
· Отсутствие конфликта интересов
· Возможность погрузиться в процесс развития команды и организации
· Предоставление сервиса поддержки Владельцу продукта
· Возможность балансирования Бизнеса и ИТ
· Умение решать конфликты
· Возможность взять до 3 команд (актуально для LeSS и производных от SAFe, где считается оптимальным использование одного Скрам-мастера на 3 команды. В немасшабируемом Scrum такой подход не приветствуется)
Важный момент: чем менее зрелая команда, тем в большем вовлечении Скрам-мастера она нуждается. И соответственно, с развитием это внимание, выраженное в часах, снижается.
ТОП-менеджер в роли РО: особенности работы
Бывает, что развитие продукта курирует стейкхолдер из ТОПов. Может ли он являться Владельцем продукта? Какие особенности возникают в такой ситуации? Давайте разбираться.
1. Нужно понять, готов ли наш стейкхолдер ежедневно участвовать в жизни команды. Scrum декларирует именно это: Владелец продукта постоянно доступен для команды разработки (является ее частью), принимает участие в ключевых командных встречах и процессах — в планировании, актуализации бэклога, ревью спринта.
2. Мы должны убедиться, что иерархической структура не оказывает пагубное влияние на команду: наш высокопоставленный Владелец продукта не раздает команде задачи, а транслирует видение развития и требования к продукту, оставляя другим членам команды свободу выбора элементов бэклога на спринт (в соотвествии с приоритизацией в бэклоге продукта) и способа работы над ними.
3. Если стейкхолдер не готов принимать участие в ежедневной работе команды, имеет смысл найти на роль Владельца продукта другого человека со стороны бизнеса.
Бывает, что развитие продукта курирует стейкхолдер из ТОПов. Может ли он являться Владельцем продукта? Какие особенности возникают в такой ситуации? Давайте разбираться.
1. Нужно понять, готов ли наш стейкхолдер ежедневно участвовать в жизни команды. Scrum декларирует именно это: Владелец продукта постоянно доступен для команды разработки (является ее частью), принимает участие в ключевых командных встречах и процессах — в планировании, актуализации бэклога, ревью спринта.
2. Мы должны убедиться, что иерархической структура не оказывает пагубное влияние на команду: наш высокопоставленный Владелец продукта не раздает команде задачи, а транслирует видение развития и требования к продукту, оставляя другим членам команды свободу выбора элементов бэклога на спринт (в соотвествии с приоритизацией в бэклоге продукта) и способа работы над ними.
3. Если стейкхолдер не готов принимать участие в ежедневной работе команды, имеет смысл найти на роль Владельца продукта другого человека со стороны бизнеса.