Статья о том, почему вам не подходит #scrum
https://blog.kaiten.ru/9-фактов-о-скраме-которые-стоит-знать
Если коротко:
✅ выкидываешь что-то из scrum получаешь что-то другое, но точно не scrum
✅ не scrum под организацию, а организация под scrum
✅ нужны кроссфункциональные команды с единой общей целью, а не отделы и матричная структура с параллельными проектами
✅ придётся нанять дорогого scrum master, с опытом и соответствующим образованием (и это не тренинг от scrum.org)
https://blog.kaiten.ru/9-фактов-о-скраме-которые-стоит-знать
Если коротко:
✅ выкидываешь что-то из scrum получаешь что-то другое, но точно не scrum
✅ не scrum под организацию, а организация под scrum
✅ нужны кроссфункциональные команды с единой общей целью, а не отделы и матричная структура с параллельными проектами
✅ придётся нанять дорогого scrum master, с опытом и соответствующим образованием (и это не тренинг от scrum.org)
Ford vs Ferrari
Посмотрел отличный фильм 🎥 и из-за профессиональной деформации, кроме отличной истории про дружбу 👬 и достижения 🎯 , я увидел историю про внутренний стартап 🥚 в большой и сильно забюрократизированной корпорации 🏢.
Как живет стартап?
1️⃣ в отдельном юридическом лице
2️⃣ в месте, где можно максимально быстро производить тестирование с пользователем
3️⃣ с человеком, принимающим решения (РО и гендиректором) в непосредственной близости, работающий вместе с командой
4️⃣ Короткими итерациями, в конце каждой работающий продукт.
По сути по #scrum
Как выглядит жизнь корпорации?
🔸Внешне все хорошо 👌
🔸Много денег 💰 ,
🔸Выстроенная иерархическая лестница, где у секретарши 🧚есть курьер и секретарша🤦♂️,
🔸Заевшаяся и в то же время импотентная верхушка👨💼, неспособная на решительные действия 👎
И единственное, что дало страртапу путевку в жизнь — это падающие продажи📉,то есть возможная (ибо денег все ещё очень много 🏦) внешняя угроза существованию компании 💀
Собственно, все как и в жизни.
Посмотрел отличный фильм 🎥 и из-за профессиональной деформации, кроме отличной истории про дружбу 👬 и достижения 🎯 , я увидел историю про внутренний стартап 🥚 в большой и сильно забюрократизированной корпорации 🏢.
Как живет стартап?
1️⃣ в отдельном юридическом лице
2️⃣ в месте, где можно максимально быстро производить тестирование с пользователем
3️⃣ с человеком, принимающим решения (РО и гендиректором) в непосредственной близости, работающий вместе с командой
4️⃣ Короткими итерациями, в конце каждой работающий продукт.
По сути по #scrum
Как выглядит жизнь корпорации?
🔸Внешне все хорошо 👌
🔸Много денег 💰 ,
🔸Выстроенная иерархическая лестница, где у секретарши 🧚есть курьер и секретарша🤦♂️,
🔸Заевшаяся и в то же время импотентная верхушка👨💼, неспособная на решительные действия 👎
И единственное, что дало страртапу путевку в жизнь — это падающие продажи📉,то есть возможная (ибо денег все ещё очень много 🏦) внешняя угроза существованию компании 💀
Собственно, все как и в жизни.
Forwarded from Agile Collage
30 января пройдёт митам по несильно популярному, но очень мощному подходу работе с требованиями и тестированию: Specification by Example
Подробности
“Традиционная модель сбора требований и создания спецификации основана на большом количестве формальностей, передач и переводов “с одного языка на другой”. Бизнес-аналитики извлекают знания из заказчика, и делают по ним спецификацию, затем перекидывают их разработчикам и тестировщикам. Разработчики извлекают знания из спецификации и переводят их в исполняемый код, который потом передается тестировщикам. Затем тестировщики берут спецификации. извлекают знания из них и переводят их в проверочные скрипты которые исполняются над готовой системой, которая передается им от разработчиков.
В теории это должно замечательно работать и все должны быть счастливы. На практике этот процесс имеет существенные недостатки и обычно приводит к огромной разнице между изначально просил заказчик и что он на самом деле получает. Существуют огромные разрывы в коммуникации на каждом шаге. Важные идеи попадают в эти провалы и загадочным способом исчезают. После каждого “перевода” информация искажается и неправильно понимается, увеличивая степень отклонения от ожидаемого изначально поведения разрабатываемой системы. Независимая интерпретация может помочь исправить ошибочную интерпретацию разработчиков или может быть совершенно другой неправильной интерпретацией требований к системе.”
При помощи Agile-процессов разработки циклы обратной становятся значительно короче, поэтому проблемы обнаруживаются раньше. […] Однако, вместо обнаружения проблем нам в первую очередь нужно работать над тем как избавиться от их появления.”
Это выдержка из книги Gojko Adzic “Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing” вышедшей в свет в 2009 году. Прошло десятилетие, однако индустрия разработки ПО по-прежнему страдает старыми болячками. Давайте лечиться :)
На первом митапе в этом году мы начнем знакомиться с подходом Specification by Example(Spec.by Example, SbE). SbE - это когда все люди, участвующие в создании решения, совместно определяют требования. Подход помогает выявить пробелы и несоответствия в требованиях ещё до создания софта. При его помощи мы можем создать достаточный объем спецификаций, который потом превращается в “живую документацию” в виде автотестов и конечно же это сильно упрощает работу разработчиков и снижает риск создания “неправильного” ПО. Само название “Specification by Example” появилось на свет в 2004 году с легкой руки Мартина Фаулера, однако, сам подход “совместного анализа” уходит корнями в 90е (а может и ещё раньше) и имеет другие разные названия - Behavior Driven Development (BDD), Acceptance Test Driven Development (ATDD), Test-Driven Requirements и тд.
Нам предстоит поучаствовать в так называемом Specification Workshop, в ходе которого мы совместно создадим требования для настоящей IT-системы :)
https://www.meetup.com/ru-RU/Technical-Excellence/events/267932278/
#DevOps #Agile #Scrum
Подробности
“Традиционная модель сбора требований и создания спецификации основана на большом количестве формальностей, передач и переводов “с одного языка на другой”. Бизнес-аналитики извлекают знания из заказчика, и делают по ним спецификацию, затем перекидывают их разработчикам и тестировщикам. Разработчики извлекают знания из спецификации и переводят их в исполняемый код, который потом передается тестировщикам. Затем тестировщики берут спецификации. извлекают знания из них и переводят их в проверочные скрипты которые исполняются над готовой системой, которая передается им от разработчиков.
В теории это должно замечательно работать и все должны быть счастливы. На практике этот процесс имеет существенные недостатки и обычно приводит к огромной разнице между изначально просил заказчик и что он на самом деле получает. Существуют огромные разрывы в коммуникации на каждом шаге. Важные идеи попадают в эти провалы и загадочным способом исчезают. После каждого “перевода” информация искажается и неправильно понимается, увеличивая степень отклонения от ожидаемого изначально поведения разрабатываемой системы. Независимая интерпретация может помочь исправить ошибочную интерпретацию разработчиков или может быть совершенно другой неправильной интерпретацией требований к системе.”
При помощи Agile-процессов разработки циклы обратной становятся значительно короче, поэтому проблемы обнаруживаются раньше. […] Однако, вместо обнаружения проблем нам в первую очередь нужно работать над тем как избавиться от их появления.”
Это выдержка из книги Gojko Adzic “Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing” вышедшей в свет в 2009 году. Прошло десятилетие, однако индустрия разработки ПО по-прежнему страдает старыми болячками. Давайте лечиться :)
На первом митапе в этом году мы начнем знакомиться с подходом Specification by Example(Spec.by Example, SbE). SbE - это когда все люди, участвующие в создании решения, совместно определяют требования. Подход помогает выявить пробелы и несоответствия в требованиях ещё до создания софта. При его помощи мы можем создать достаточный объем спецификаций, который потом превращается в “живую документацию” в виде автотестов и конечно же это сильно упрощает работу разработчиков и снижает риск создания “неправильного” ПО. Само название “Specification by Example” появилось на свет в 2004 году с легкой руки Мартина Фаулера, однако, сам подход “совместного анализа” уходит корнями в 90е (а может и ещё раньше) и имеет другие разные названия - Behavior Driven Development (BDD), Acceptance Test Driven Development (ATDD), Test-Driven Requirements и тд.
Нам предстоит поучаствовать в так называемом Specification Workshop, в ходе которого мы совместно создадим требования для настоящей IT-системы :)
https://www.meetup.com/ru-RU/Technical-Excellence/events/267932278/
#DevOps #Agile #Scrum
Meetup
Вход в Meetup | Meetup
Not a Meetup member yet? Log in and find groups that host online or in person events and meet people in your local community who share your interests.
Cargo cult и user story
Кто-то умный 🧠 что-то придумал, рассказал второму, тот третьему, и так далее и уже через пару пересказов от первоначальной идеи осталась только механика, и почти полностью пропало содержание (смысл).
Сейчас уже у многих есть «бэклоги», внутри которых «пользовательские истории» (или просто «истории») и, если забить в google, как их писать, то первая страница поисковой выдачи будет про дебильный шаблон:
Я, как <РОЛЬ>, хочу <ПОТРЕБНОСТЬ>, чтобы <ЦЕЛЬ>.
У людей не так много потребностей и точно тяжело себе представить условного пользователя интернет банка, который хочет «заходить по логину и паролю в интернет банк», но это встречается сплошь и рядом.
Почему вдруг «потребности» заменились на «функциональные требования»⁉️
Полагаю, причина в том, что последние в индустрии больше 50 лет, а этим вашим историям — в лучшем случае со времён ХР (который такое себе получил распространение), и опять же пересказы не способствовали правильному внедрению подхода.
«Истории» получили своё название не из того, как мы их записываем, а из того, как используем.
Давайте использовать их правильно (3 ‘C’):
❇️ card (карточка ), на которой пользователь написал свои хотелки
❇️ conversation (обсуждение) этой хотелки, выявление потребностей, выяснение деталей
❇️ confirmation (подтверждение) наших договоренностей
Кстати,
1️⃣ В #scrum никаких историй нет, а только — «элементы бэклога».
2️⃣ Кому интересно, то есть и 5С https://www.pinterest.com/amp/pin/650840583620800007/
#userstory
Кто-то умный 🧠 что-то придумал, рассказал второму, тот третьему, и так далее и уже через пару пересказов от первоначальной идеи осталась только механика, и почти полностью пропало содержание (смысл).
Сейчас уже у многих есть «бэклоги», внутри которых «пользовательские истории» (или просто «истории») и, если забить в google, как их писать, то первая страница поисковой выдачи будет про дебильный шаблон:
Я, как <РОЛЬ>, хочу <ПОТРЕБНОСТЬ>, чтобы <ЦЕЛЬ>.
У людей не так много потребностей и точно тяжело себе представить условного пользователя интернет банка, который хочет «заходить по логину и паролю в интернет банк», но это встречается сплошь и рядом.
Почему вдруг «потребности» заменились на «функциональные требования»⁉️
Полагаю, причина в том, что последние в индустрии больше 50 лет, а этим вашим историям — в лучшем случае со времён ХР (который такое себе получил распространение), и опять же пересказы не способствовали правильному внедрению подхода.
«Истории» получили своё название не из того, как мы их записываем, а из того, как используем.
Давайте использовать их правильно (3 ‘C’):
❇️ card (карточка ), на которой пользователь написал свои хотелки
❇️ conversation (обсуждение) этой хотелки, выявление потребностей, выяснение деталей
❇️ confirmation (подтверждение) наших договоренностей
Кстати,
1️⃣ В #scrum никаких историй нет, а только — «элементы бэклога».
2️⃣ Кому интересно, то есть и 5С https://www.pinterest.com/amp/pin/650840583620800007/
#userstory
Вкратце про #scrum«Солнечный свет ☀️ – лучшая дезинфекция 🧼».
Луи Брандейс, американский судья 👨⚖️
Привал ⛺️ или причал ⚓️ , пока не решил, но точно пауза...
С 15.09.2020 на этом канале не выходят посты.
У этого есть ряд причин:
🔗 Смена работы и позиции
🔗 Огромная загрузка по приоритетам
🔗 Тема agile стала для меня слишком узкой
Однако интересные (возможно только мне 💆♂️) темы никуда не делались, и теперь они почти на 💯% никакого отношения к #agile #scrum не имеют (этим в моей команде занимаются другие люди, и они вроде справляются отлично;)), а крутятся вокруг данных🗄, их обработки и аналитики📈.
В более сжатом формате (иногда даже просто репост) я делюсь ими в другом канале https://t.me/VisualElephant
Сейчас там 66 постов, которые выходят с разной периодичности (ибо не может быть интересно ровно Х элементов в день 🧐), но в следующие пару лет я планирую его наполнить изрядно ♾
Если есть желание, присоединяйтесь.
Что будет с этим каналом я пока не знаю 🤷♂️
🤷🏻 возможно, у меня найдутся силы продолжить вести его (контента ещё много из неизданного),
🤷🏻 может появятся ребята, кто готов подхватить канал — будем посмотреть (контакты все есть — велкам).
Спасибо всем, кто был здесь все это время, комментировал 📝, писал в личку, всячески говорил спасибо и тем, кто просто читал 📚. Надеюсь, кроме моей личной прокачки, это ещё помогло кому-то в бизнесе 💰 или в работе с командами 🤗
Telegram
Visual Elephant
Каждому, кто работает с визуализацией данных нужна насмотренность на красивые графики, подходы и проч. В канале будут re-посты всех понравившихся мне визуализаций, статей по цветам, UI|UX, art и проч.
Видео от Simon Wardly про его #WardlyMaps у некоторых особенно рьяных #agile коучей может вызвать приступ неприятия.
У адекватных людей, которые хорошо знаю модель Киневин, про отсутствие серебряных пуль и ошибочность желания притянуть #scrum/agile/что-угодно к решению всех проблем, получат истинное удовольствие, как от контента, так и от манеры подачи.
Саймон с юмором и троллингом приводит интересные примеры необоснованных #digital-трансформаций.
Рекомендую к просмотру
У адекватных людей, которые хорошо знаю модель Киневин, про отсутствие серебряных пуль и ошибочность желания притянуть #scrum/agile/что-угодно к решению всех проблем, получат истинное удовольствие, как от контента, так и от манеры подачи.
Саймон с юмором и троллингом приводит интересные примеры необоснованных #digital-трансформаций.
Рекомендую к просмотру
YouTube
An Introduction to Wardley Maps (Simon Wardley)
Simon will be taking to the stage again at SEACON 2023 on Thursday 19th October in-person (The Oval, London) and live-streamed.
Join Simon, 30+ other amazing speakers and 400+ like-minded attendees by getting your ticket via https://www.seacom.online/seacon…
Join Simon, 30+ other amazing speakers and 400+ like-minded attendees by getting your ticket via https://www.seacom.online/seacon…
Мне одному кажется решение не сертифицировать россиян (и не давать делать бизнес в РФ местным PST) нарушением ценностей #scrum, например, честность?
А гаденькая формулировка, что они это делают не из-за того, что США сказала: мы всех прижмем, если попробуете сунуться — нет, что вы — все потому, что людей им жалко.
Такая себе «смелость».
Я молчу, что они кинули ребят, которые впахивали на PST (даже представить не могу себе, сколько им стоило трудов) - вот такая, понимаешь, открытость и приверженность.
А гаденькая формулировка, что они это делают не из-за того, что США сказала: мы всех прижмем, если попробуете сунуться — нет, что вы — все потому, что людей им жалко.
Такая себе «смелость».
Я молчу, что они кинули ребят, которые впахивали на PST (даже представить не могу себе, сколько им стоило трудов) - вот такая, понимаешь, открытость и приверженность.
Scrum.org
Pausing Training and Certifications in Russia
We are deeply concerned about the Russian invasion of Ukraine and stand with all of the people who are suffering as a result of this violence. Over the past few days we have been working together with members of our community to decide on a response to the…
Авторизация результата
Я всегда думал что авторизация результата непосредственно связана с наградой и казалось, что если хотя бы не похвалить (то есть не дать себе или другим оценку), то и достижения нет, но кажется я здесь сильно ошибался 🤦♂️
Почему нужно разносить авторизацию и награду?
Смотрим на цикл работы над задачей е2е:
1️⃣ контекст задачи и что требовалось сделать
2️⃣ что делалось для ее решения
3️⃣ какой результат в итоге получился
Казалось бы: начальная постановка и итоговый результат могут сильно отличаться друг от друга и хвалить не за что?
Смотрим на эти 3 пункта и задаём вопросы
➖можно было сделать лучше в указанном контексте?
➖достаточны ли были усилия, которые предпринимались для того, чтобы gap был минимальным?
➖ насколько приемлем для нас полученный gap между план-фактом?
Слушая восхитительную Аню Обухову я вспомнил одно выступление дедушки Woody Zuill о том, как у него получилась крутая команда благодаря ежедневной ретроспективе: они
подводили итоги дня формате
🤩«что нам сегодня помогало?»
Из этого вопроса родились
💎 mob programming
💎 #noEstimate
💎И другие прекрасные вещи (про #scrum скоромно умолчим)
Кстати, авторизовывать результат можно делать как про себя так и письменно
Я всегда думал что авторизация результата непосредственно связана с наградой и казалось, что если хотя бы не похвалить (то есть не дать себе или другим оценку), то и достижения нет, но кажется я здесь сильно ошибался 🤦♂️
Почему нужно разносить авторизацию и награду?
Смотрим на цикл работы над задачей е2е:
1️⃣ контекст задачи и что требовалось сделать
2️⃣ что делалось для ее решения
3️⃣ какой результат в итоге получился
Казалось бы: начальная постановка и итоговый результат могут сильно отличаться друг от друга и хвалить не за что?
Смотрим на эти 3 пункта и задаём вопросы
➖можно было сделать лучше в указанном контексте?
➖достаточны ли были усилия, которые предпринимались для того, чтобы gap был минимальным?
➖ насколько приемлем для нас полученный gap между план-фактом?
Слушая восхитительную Аню Обухову я вспомнил одно выступление дедушки Woody Zuill о том, как у него получилась крутая команда благодаря ежедневной ретроспективе: они
подводили итоги дня формате
🤩«что нам сегодня помогало?»
Из этого вопроса родились
💎 mob programming
💎 #noEstimate
💎И другие прекрасные вещи (про #scrum скоромно умолчим)
Кстати, авторизовывать результат можно делать как про себя так и письменно
YouTube
Анна Обухова. Хочу хотеть, как захотеть сделать любую задачу. Вебинар 10 ноября 2020
Есть мнение, что самое главное - это захотеть, чтобы сделать. И мотивация для этого либо есть, либо нет. А если мотивации вдруг нет, нужно взять кнут, пряник, плюшку, палку и замотивировать себя или другого. Но все и сложнее, и проще.
Мало захотеть. Нужно…
Мало захотеть. Нужно…
Нашёл у Макса Дорофеева одну статью, откуда процитирую отрывок про #waterfall:
1. Сначала мы напишем все-все требования учтем в них всё-всё
2. Потом по этим требованиям мы сделаем архитектуру. Хорошую-прехорошую, чтоб не переделывать. Это будет не сложно, у нас же будут все-все требования
3. Дальше мы все это закодируем. По понятной архитектуре это просто.
4. Потом протестируем. По идее ошибок много быть не должно. Ведь все будет описано в ТЗ, нам будет все понятно. Ну и архитектура будет продумана до мелочей
5. Потом мы исправим те незначительные баги, которые найдут тестировщики
6. Затем мы напишем пользовательскую документацию. По готовому софту оно же легко
7. Дальше мы всех пользователей обучим. Тем более, когда документация есть, какие тут сложности?
8. Внедрим систему. Это уже будет совсем просто, так как пользователи обучены, документация готовая, ошибки исправлены, архитектура понятна…
9. Получаем профит. Ну и редкие запросы на незначительные доработки. Мы же в самом начале всё учли…
#scrum #agile
1. Сначала мы напишем все-все требования учтем в них всё-всё
2. Потом по этим требованиям мы сделаем архитектуру. Хорошую-прехорошую, чтоб не переделывать. Это будет не сложно, у нас же будут все-все требования
3. Дальше мы все это закодируем. По понятной архитектуре это просто.
4. Потом протестируем. По идее ошибок много быть не должно. Ведь все будет описано в ТЗ, нам будет все понятно. Ну и архитектура будет продумана до мелочей
5. Потом мы исправим те незначительные баги, которые найдут тестировщики
6. Затем мы напишем пользовательскую документацию. По готовому софту оно же легко
7. Дальше мы всех пользователей обучим. Тем более, когда документация есть, какие тут сложности?
8. Внедрим систему. Это уже будет совсем просто, так как пользователи обучены, документация готовая, ошибки исправлены, архитектура понятна…
9. Получаем профит. Ну и редкие запросы на незначительные доработки. Мы же в самом начале всё учли…
#scrum #agile
Что такое #продукт?
Когда я работал в ЦК Agile довольно часто возникал холивар по поводу продуктового подхода в целом и продукта в частности.
На эту тему в новой версии scrum guide есть определение
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
1️⃣ Продукт — это средство для доставки ценности.
То есть подразумевается, что есть ценность.
Нигде не сказано, что за ценность за такая, но точно сказано, что она есть. О видах ценности было ранее.
2️⃣ Продукт — это, что имеет границы.
Можно подумать, что тут как бы идёт кивок в сторону проектов (у хороших РМ проекты имеют чёткие границы по фичам, чтобы вписаться в бюджет), но мне кажется тут про другое — про цели, с которой создаётся продукт, видение, которое есть у основателя/ РО и проч.
Важный момент: SG как бы само собой разумеющееся говорит, что продукт есть (хотя не понятно, по где по жизненному циклу он находится находится)
3️⃣ У продукта (для многих открытие) есть заинтересованные лица (условный «бизнес», спонсор, заказчик и проч)
То есть как бы РО максимизирует ценность, мини-СЕО, но и у СЕО есть Совет Директоров и Акционеры, которые в случае чего могут и устроить СЕО ☠️
4️⃣ У продукта есть пользователи или клиенты
То есть либо те, кто использует продукт в своей жизни/работе, либо есть те, кто заплатил за то, чтобы продукт появился в пользовании у них, в компании, у пользователей.
5️⃣ Продуктом может быть что угодно: физический продукт, услуга (сервис) или ещё что-то абстрактное, у которой есть перечисленные 4 свойства
Хочется обратить внимание на «настоящие» продукты и ненастоящие продукты.
SG в определении не проводит границы между ними, поэтому может хрестоматийная CRMка быть продуктом? Проверяем по чек-листу — да, может. Лучше было бы, если CRM входила как «компонент» в продукт «система продаж» — конечно, лучше (про компонентные команды Ларман лучше меня расскажет https://t.me/tw0_percent/8 — офигеть, это был 8й пост в этом канале), но хочется подсветить, что в компании может быть команда развития CRM и она даже может использовать #scrum для того, чтобы «помогать людям, командам … создавать ценность через адаптивные решения комплексных задач»
Когда я работал в ЦК Agile довольно часто возникал холивар по поводу продуктового подхода в целом и продукта в частности.
На эту тему в новой версии scrum guide есть определение
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
1️⃣ Продукт — это средство для доставки ценности.
То есть подразумевается, что есть ценность.
Нигде не сказано, что за ценность за такая, но точно сказано, что она есть. О видах ценности было ранее.
2️⃣ Продукт — это, что имеет границы.
Можно подумать, что тут как бы идёт кивок в сторону проектов (у хороших РМ проекты имеют чёткие границы по фичам, чтобы вписаться в бюджет), но мне кажется тут про другое — про цели, с которой создаётся продукт, видение, которое есть у основателя/ РО и проч.
Важный момент: SG как бы само собой разумеющееся говорит, что продукт есть (хотя не понятно, по где по жизненному циклу он находится находится)
3️⃣ У продукта (для многих открытие) есть заинтересованные лица (условный «бизнес», спонсор, заказчик и проч)
То есть как бы РО максимизирует ценность, мини-СЕО, но и у СЕО есть Совет Директоров и Акционеры, которые в случае чего могут и устроить СЕО ☠️
4️⃣ У продукта есть пользователи или клиенты
То есть либо те, кто использует продукт в своей жизни/работе, либо есть те, кто заплатил за то, чтобы продукт появился в пользовании у них, в компании, у пользователей.
5️⃣ Продуктом может быть что угодно: физический продукт, услуга (сервис) или ещё что-то абстрактное, у которой есть перечисленные 4 свойства
Хочется обратить внимание на «настоящие» продукты и ненастоящие продукты.
SG в определении не проводит границы между ними, поэтому может хрестоматийная CRMка быть продуктом? Проверяем по чек-листу — да, может. Лучше было бы, если CRM входила как «компонент» в продукт «система продаж» — конечно, лучше (про компонентные команды Ларман лучше меня расскажет https://t.me/tw0_percent/8 — офигеть, это был 8й пост в этом канале), но хочется подсветить, что в компании может быть команда развития CRM и она даже может использовать #scrum для того, чтобы «помогать людям, командам … создавать ценность через адаптивные решения комплексных задач»
Видео на бранч
Короткое видео (00:17:33) про #UserStory vs #Requirements, в котором автор приводит определение того, что такое «Требования» от IEEE:
A condition or capability needed by a user to solve a problem or achieve an objective.
Что можно перевести как
«Условие/возможность, необходимое пользователю для решения проблемы или достижения цели»
И тут возникает неловкая пауза, так как из определения не следует, что «Требование» — это адский документ со спецификацией реализации.
Советую посмотреть видео самому и занять свою позицию по поводу работы аналитиков в команде, а то как бывает:
- Мы работаем по «#scrum»!
- Поставки хотя бы раз в 2 недели по задачам взятым на планировании?
- Не, у нас сначала спринт аналитики, потом спринт разработки, а в конце спринт тестирования, после которого спринт сборки и выкатки на ПРОМ/PROD. Так что да: поставка у нас раз в 2 недели, но по тем задачам, которые мы взяли в работу 3 спринта назад.
- У вас не scrum, а «scrum, но…»🤦
Короткое видео (00:17:33) про #UserStory vs #Requirements, в котором автор приводит определение того, что такое «Требования» от IEEE:
A condition or capability needed by a user to solve a problem or achieve an objective.
Что можно перевести как
«Условие/возможность, необходимое пользователю для решения проблемы или достижения цели»
И тут возникает неловкая пауза, так как из определения не следует, что «Требование» — это адский документ со спецификацией реализации.
Советую посмотреть видео самому и занять свою позицию по поводу работы аналитиков в команде, а то как бывает:
- Мы работаем по «#scrum»!
- Поставки хотя бы раз в 2 недели по задачам взятым на планировании?
- Не, у нас сначала спринт аналитики, потом спринт разработки, а в конце спринт тестирования, после которого спринт сборки и выкатки на ПРОМ/PROD. Так что да: поставка у нас раз в 2 недели, но по тем задачам, которые мы взяли в работу 3 спринта назад.
- У вас не scrum, а «scrum, но…»🤦
YouTube
Requirement Specification vs User Stories
What are software requirements and how do they relate to user stories? Is it requirement vs user story, or user story as requirement? An important part of agile software development is its user or customer focus. Our aim as software developers is to deliver…
#ШколаAgile #ПерваяСтупень #Scrum
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о первом воркшопе про Scrum, в котором разбираются зоны ответственности (или роли, если ссылаться на SG'17) 👨🔬👷♀️👨🏭👩🔧
Данный воркшоп делался на базе scrum puzzle от AgileVerse, в которой работают 2 бывших agile-коуча из #СБЕР (Лева и Миша привет). Ребята большие молодцы, что сделали для community puzzle по #Scrum
Зачем мы проводим этот, казалось бы непрактичный воркшоп?
Ребята, завершившие первую ступень, либо участвуют в трансформации, либо могут способствовать трансформации работы своей команды, и им важно знать, что предлагает scrum (условно "революционный метод") и kanban (условно «эволюционный»).
C другой стороны, scrum легко прочитать, но тяжело понять, поэтому делать это нужно в растянутом формате и как можно раньше.
За деталями по вокршопа можно обратиться к документу, внутри которого есть:
🎯 цели этой встречи;
🎁 результаты, с которыми нужно с нее выйти;
📋 таблица с таймингом.
В настоящий момент пока еще доступна доска в miro
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, что мы забыли включить в основы, то есть что нужно добавить, а что нам стоит выкинуть, так как тайминг не резиновый 🤦♂️?
🤙 Остаемся на связи
Канал 2%
____
Материалы подготовлены Натальей Варакиной в рамках запроса о помощи community.
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о первом воркшопе про Scrum, в котором разбираются зоны ответственности (или роли, если ссылаться на SG'17) 👨🔬👷♀️👨🏭👩🔧
Данный воркшоп делался на базе scrum puzzle от AgileVerse, в которой работают 2 бывших agile-коуча из #СБЕР (Лева и Миша привет). Ребята большие молодцы, что сделали для community puzzle по #Scrum
Зачем мы проводим этот, казалось бы непрактичный воркшоп?
Ребята, завершившие первую ступень, либо участвуют в трансформации, либо могут способствовать трансформации работы своей команды, и им важно знать, что предлагает scrum (условно "революционный метод") и kanban (условно «эволюционный»).
C другой стороны, scrum легко прочитать, но тяжело понять, поэтому делать это нужно в растянутом формате и как можно раньше.
За деталями по вокршопа можно обратиться к документу, внутри которого есть:
🎯 цели этой встречи;
🎁 результаты, с которыми нужно с нее выйти;
📋 таблица с таймингом.
В настоящий момент пока еще доступна доска в miro
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, что мы забыли включить в основы, то есть что нужно добавить, а что нам стоит выкинуть, так как тайминг не резиновый 🤦♂️?
🤙 Остаемся на связи
Канал 2%
____
Материалы подготовлены Натальей Варакиной в рамках запроса о помощи community.
Google Docs
Scrum 1
Воркшоп. Scrum 1 Цель Познакомиться с Руководством по Scrum Изучить ценности Scrum. Обозначить зону применимости фреймворка Scrum Разобрать предлагаемые Scrum зоны ответственности (роли). Подробнее разобрать навыки и компетенции scrum master, его зону ответственности.…
#ШколаAgile #ПерваяСтупень #Scrum
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile и сегодня поговорим о втором воркшопе про Scrum, в котором детально разбирается фреймворк Scrum: события, артефакты и углубленное понимание зон ответственности в команде.
Детальный разбор направлен на то, чтобы у участников воркшопа сформировалось понимание насколько сильно связаны между собой элементы и отказ от одного из них может привести к тому, что фреймворк распадется и потенциально может сделать элементы бесполезными.
Данный воркшоп делался на базе scrum puzzle от AgileVerse, в которой работают 2 бывших agile-коуча из сбера (Миши и Лева). Ребята большие молодцы, что сделали для community их puzzle.
Важное место в воркшопе занимает X-Team Silos Game, ведь это отличный способ через игру привести людей к сотрудничеству и развивать «T-образных специалистов» (T-shaped people).
За деталями по вокршопа можно обратится к документу, внутри которого есть:
🎯 цели этой встречи;
🎁 результаты, с которыми нужно с нее выйти;
📋 таблица с таймингом.
В настоящий момент пока еще доступна доска в miro
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах давайте немного похоливарим, от какого элемента Scrum активно отбивается ваша команда 😈 и что вы с этим делаете?
🤙 Остаемся на связи
Канал 2%
____
Материалы подготовлены Лобанова Елена в рамках запроса о помощи community.
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile и сегодня поговорим о втором воркшопе про Scrum, в котором детально разбирается фреймворк Scrum: события, артефакты и углубленное понимание зон ответственности в команде.
Детальный разбор направлен на то, чтобы у участников воркшопа сформировалось понимание насколько сильно связаны между собой элементы и отказ от одного из них может привести к тому, что фреймворк распадется и потенциально может сделать элементы бесполезными.
Данный воркшоп делался на базе scrum puzzle от AgileVerse, в которой работают 2 бывших agile-коуча из сбера (Миши и Лева). Ребята большие молодцы, что сделали для community их puzzle.
Важное место в воркшопе занимает X-Team Silos Game, ведь это отличный способ через игру привести людей к сотрудничеству и развивать «T-образных специалистов» (T-shaped people).
За деталями по вокршопа можно обратится к документу, внутри которого есть:
🎯 цели этой встречи;
🎁 результаты, с которыми нужно с нее выйти;
📋 таблица с таймингом.
В настоящий момент пока еще доступна доска в miro
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах давайте немного похоливарим, от какого элемента Scrum активно отбивается ваша команда 😈 и что вы с этим делаете?
🤙 Остаемся на связи
Канал 2%
____
Материалы подготовлены Лобанова Елена в рамках запроса о помощи community.
Google Docs
Scrum 2
Статистика канала за #октябрь
Подбиваем статистику в канале по сделанным публикациям.
Получилось: 2️⃣3️⃣ публикаций в октябре (на 5 меньше, чем в сентябре – тренд на лицо: из-за загрузки писать времени нет совсем, живу на старых запасах).
Довольно необычно читать посты, написанные в прошлом – иногда не сразу понятно, что их писал я каких-то пару месяцев назад. Кажется, что автор кто-то другой (и иногда за него немного стыдно)👻
❗️В этом месяце был опубликован последний пост про первою ступень открытого проекта обучения scrum-мастеров, agile-коучей и агентов изменений Школа Agile🎉
Все материалы в открытом доступе можно найти в этом канале по хэштегу #ШколаAgile. Все посты по Школе агрегируются в googledocs.
Пользуясь случаем напоминаю, что желающие поволонтерить могут еще присоединиться, во второй ступени еще есть неразобранные воркшопы).
Ниже будет традиционная подборка лучших публикаций («лучшесть», как и «ценность», у каждого своя) за месяц.
👅 Самые обсуждаемые (🔝 по комментариям)
♦ Длительность использования сервиса не гарантирует его качество
♦ Чтобы получить результат нужно уметь создавать условия. Немного «буддизма» в ленту
♦ Внимание как индикатор проблем или почему рецепты «как правильно» работают не везде
🎁 Самые виральные (🔝по количеству public и private шарингу)
♦ #ШколаAgile: описание воркшопа по пользовательским историям #userstory
♦ #ШколаAgile: описание воркшопа по планированию спринта #scrum
♦ Зачем на самом деле нужна фасилитация
🤪 Самые пятничные посты
♦ Порефлексировал как хожу на некоторые встречи🤨
♦ Продукт для всех - продукт для никого😇
♦ Что происходит, когда не соблюдаешь спринт и впихиваешь невпихуемое🤯
Ps
Леша Пятов начал делать модель для оценки виральности постов (За что ему огромное спасибо 🤗).
Такие дела за месяц. Посмотрим, что будет в ноябре👋
Подбиваем статистику в канале по сделанным публикациям.
Получилось: 2️⃣3️⃣ публикаций в октябре (на 5 меньше, чем в сентябре – тренд на лицо: из-за загрузки писать времени нет совсем, живу на старых запасах).
Довольно необычно читать посты, написанные в прошлом – иногда не сразу понятно, что их писал я каких-то пару месяцев назад. Кажется, что автор кто-то другой (и иногда за него немного стыдно)
❗️В этом месяце был опубликован последний пост про первою ступень открытого проекта обучения scrum-мастеров, agile-коучей и агентов изменений Школа Agile🎉
Все материалы в открытом доступе можно найти в этом канале по хэштегу #ШколаAgile. Все посты по Школе агрегируются в googledocs.
Пользуясь случаем напоминаю, что желающие поволонтерить могут еще присоединиться, во второй ступени еще есть неразобранные воркшопы).
Ниже будет традиционная подборка лучших публикаций («лучшесть», как и «ценность», у каждого своя) за месяц.
👅 Самые обсуждаемые (🔝 по комментариям)
♦ Длительность использования сервиса не гарантирует его качество
♦ Чтобы получить результат нужно уметь создавать условия. Немного «буддизма» в ленту
♦ Внимание как индикатор проблем или почему рецепты «как правильно» работают не везде
🎁 Самые виральные (🔝по количеству public и private шарингу)
♦ #ШколаAgile: описание воркшопа по пользовательским историям #userstory
♦ #ШколаAgile: описание воркшопа по планированию спринта #scrum
♦ Зачем на самом деле нужна фасилитация
🤪 Самые пятничные посты
♦ Порефлексировал как хожу на некоторые встречи
♦ Продукт для всех - продукт для никого
♦ Что происходит, когда не соблюдаешь спринт и впихиваешь невпихуемое
Ps
Леша Пятов начал делать модель для оценки виральности постов (За что ему огромное спасибо 🤗).
Такие дела за месяц. Посмотрим, что будет в ноябре
Please open Telegram to view this post
VIEW IN TELEGRAM
#ШколаAgile #ВтораяСтупень #JIRA #Scrum #Sprint
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе «Основы JIRA» 📊.
Чтобы мочь управлять чем-то, это необходимо увидеть. Многие крупные компании используют Jira/GitLab для организации работ своих команд. Мы даем этот воркшоп для будущих агентов изменений с целью научить их делать работу команд прозрачной, знакомим с тем, какими возможностями обладает инструмент. Для опытных Jira пользователей тема может показаться простой, но на наших воркшопах присутствуют участники, впервые открывающие для себя этот инструмент управления задачами проекта/продукта. Обучение инструменту получается через работу с бэклогом “обучение работе с task tracker”.
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, какой инструмент используется у вас в компании? Сказались ли на вас санкции, планируете ли миграцию на opensource инструменты?
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовлены Анастасией Фединой (ведет аккаунт в instagram) в рамках запроса о помощи community.
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе «Основы JIRA» 📊.
Чтобы мочь управлять чем-то, это необходимо увидеть. Многие крупные компании используют Jira/GitLab для организации работ своих команд. Мы даем этот воркшоп для будущих агентов изменений с целью научить их делать работу команд прозрачной, знакомим с тем, какими возможностями обладает инструмент. Для опытных Jira пользователей тема может показаться простой, но на наших воркшопах присутствуют участники, впервые открывающие для себя этот инструмент управления задачами проекта/продукта. Обучение инструменту получается через работу с бэклогом “обучение работе с task tracker”.
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, какой инструмент используется у вас в компании? Сказались ли на вас санкции, планируете ли миграцию на opensource инструменты?
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовлены Анастасией Фединой (ведет аккаунт в instagram) в рамках запроса о помощи community.
Atlassian
Jira | Issue & Project Tracking Software | Atlassian
Make the impossible, possible in Jira. Plan, track, and release world-class software with the number one project management tool for agile teams.
#ШколаAgile #ВтораяСтупень #Scrum
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе «Advanced Scrum» 👨🏻🎓.
Scrum - обширная тема, поэтому на 2 ступени ему посвящен еще один воркшоп. Данный воркшоп строится на базе игры Scrum Value Game. Так же в данном воркшопе более подробно разбираются DoD, DoR и АС и разница между ними.
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, играли ли вы когда-нибудь в Scrum Value Game и если да, было ли полезно?
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовила Шумилова Таня в рамках запроса о помощи community.
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе «Advanced Scrum» 👨🏻🎓.
Scrum - обширная тема, поэтому на 2 ступени ему посвящен еще один воркшоп. Данный воркшоп строится на базе игры Scrum Value Game. Так же в данном воркшопе более подробно разбираются DoD, DoR и АС и разница между ними.
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, играли ли вы когда-нибудь в Scrum Value Game и если да, было ли полезно?
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовила Шумилова Таня в рамках запроса о помощи community.
#ШколаAgile #ВтораяСтупень #PBR #Приоритизация
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе «Приоритизация Бэклога» 🗃️.
Бэклог обладает важным свойством эмерджентности, т.е. он постоянно развивается во времени. Действительно, любой член команды может добавить новый элементы в бэклог продукта (если PO держит backlog открытым и/или делегирует функцию создания в нем новых элементов своим коллегам. В какой-то момент времени у всей команды может возникнуть вопрос: “Что же надо делать первее?” или “Почему этот элемент выше по порядку, чем другой?”.
Скрамгайд достаточно точно отвечает на этот вызов: “Scrum Master способствовал возникновению среды, в которой Product Owner упорядочивает работу по решению комплексной проблемы в Product Backlog.”
Чтобы скрам мастер мог подсказывать продакту практики приоритизации, в программе Школы есть данный воркшоп.
Как его проводить описано в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, сколько элементов бэклога находится бэклоге вашей команды?
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовлены Александром Остроуховым в рамках запроса о помощи community.
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе «Приоритизация Бэклога» 🗃️.
Бэклог обладает важным свойством эмерджентности, т.е. он постоянно развивается во времени. Действительно, любой член команды может добавить новый элементы в бэклог продукта (если PO держит backlog открытым и/или делегирует функцию создания в нем новых элементов своим коллегам. В какой-то момент времени у всей команды может возникнуть вопрос: “Что же надо делать первее?” или “Почему этот элемент выше по порядку, чем другой?”.
Скрамгайд достаточно точно отвечает на этот вызов: “Scrum Master способствовал возникновению среды, в которой Product Owner упорядочивает работу по решению комплексной проблемы в Product Backlog.”
Чтобы скрам мастер мог подсказывать продакту практики приоритизации, в программе Школы есть данный воркшоп.
Как его проводить описано в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, сколько элементов бэклога находится бэклоге вашей команды?
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовлены Александром Остроуховым в рамках запроса о помощи community.
#ШколаAgile #ДопМатериалы #DSM #Daily #Scrum #AddOn
Всем привет!👋
Мы завершили публикацию материалов двух ступеней Школы Agile, но за время проведения потоков Школы возникали темы, которые с одной стороны несли ощутимую ценность, а с другой не вписывались в программу потока из-за ограничений и/или поставленных целей. Мы будем делиться такими темами с вами, чтобы вы использовали их для межмодульной практики или в качестве дополнительных поводов для встречи с самыми стойкими слушателелями :).
Сегодня поговорим о воркшопе “Фасилитация Daily Scrum Meeting” 🕒.
Daily Scrum Meeting длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время. Является одним из 5 событий Scrum. В нем принимают участие все разработчики Scrum Team. Казалось бы, о чем тут можно рассказать? По опыту запуска этого события в командах, в нем присутствует 100500 дисфункций, а при должном внимании именно из DSM можно вытащить массу инсайтов о том, как и чем живет команда (Димка Блинов, привет).
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, с какими трудностями вы сталкиваетесь в проведении Daily, разберемся вместе!
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовлены Натальей Варанкиной в рамках запроса о помощи community.
Всем привет!👋
Мы завершили публикацию материалов двух ступеней Школы Agile, но за время проведения потоков Школы возникали темы, которые с одной стороны несли ощутимую ценность, а с другой не вписывались в программу потока из-за ограничений и/или поставленных целей. Мы будем делиться такими темами с вами, чтобы вы использовали их для межмодульной практики или в качестве дополнительных поводов для встречи с самыми стойкими слушателелями :).
Сегодня поговорим о воркшопе “Фасилитация Daily Scrum Meeting” 🕒.
Daily Scrum Meeting длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время. Является одним из 5 событий Scrum. В нем принимают участие все разработчики Scrum Team. Казалось бы, о чем тут можно рассказать? По опыту запуска этого события в командах, в нем присутствует 100500 дисфункций, а при должном внимании именно из DSM можно вытащить массу инсайтов о том, как и чем живет команда (Димка Блинов, привет).
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, с какими трудностями вы сталкиваетесь в проведении Daily, разберемся вместе!
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовлены Натальей Варанкиной в рамках запроса о помощи community.