Я не понимаю каким образом в дев тим можно маркетолога запихнуть, может кто просветит?

PO обычно выполняет роль маркетолога, ну или тесно с ними коммуницирует

Это обычно)

А если выделенный маркетолог есть помимо ПО?

Зависит от того, чем он занимается.

Если метриками и аналитикой, то совсем легко.

Есть ли тут те, кто знаком и использует Reliable Scrum?

Слышал dual track scrum, теперь знаю что есть и reliable)

Если коммуникациями и планированием кампаний - наверное он в команде не очень нужен.

http://reliable-scrum.de/

Слышал dual track scrum, теперь знаю что есть и reliable)

Значит обычный скрам не совсем релайебл, или релайебл более релайебл чем класстческий скрам?

Сорри за тавтологию

Значит обычный скрам не совсем релайебл, или релайебл более релайебл чем класстческий скрам?

Reliable более reliable с точки зрения "попасть в deadline". Что далеко не всегда надо, почти всегда бесполезно, но иногда приходится, особенно в аутсорсе.

Блиииииин, всего на пару часов отлучился из чата - 400 новых сообщений! Еле дочитал 😂

Ребята, посоветуйте пожалуйста вменяемые тренинги по TDD и парному программированию/тестированию

Если таковые вообще есть

По TDD есть отличный курс для начинающих в Microsoft Academy

Спасибо! Поизучаю

https://mva.microsoft.com/en-us/training-courses/testdriven-development-16458

Reliable более reliable с точки зрения "попасть в deadline". Что далеко не всегда надо, почти всегда бесполезно, но иногда приходится, особенно в аутсорсе.

Чую что нет тут никого кто знает про надежный скрам. Хотя я на прошлом SECR рассказывал про адаптацию..

Ну это не самая распространенная вариация.

https://mva.microsoft.com/en-us/training-courses/testdriven-development-16458

А так чтобы команду загрузить на тренинг? С живыми примерами

Увы

@sbase возможно что-то подскажет :)

@sbase возможно что-то подскажет :)

Ну тогда можно и статью показать, может они уже применяют но не знают об этом. Хотя что-то не верится... http://bipulse.ru/blog/index.php?post/2015/11/Reliable-SCRUM и тут https://youtu.be/-FqLml9bk0w

Ну тогда можно и статью показать, может они уже применяют но не знают об этом. Хотя что-то не верится... http://bipulse.ru/blog/index.php?post/2015/11/Reliable-SCRUM и тут https://youtu.be/-FqLml9bk0w

Я про курсы по TDD :)

Я про курсы по TDD :)

Значит я не так понял. привязка к треду отвалилась. Пр надежный Sсrum тоже полезное.

Кстати о, а есть ли знакомые с Tame Flow?

Блиииииин, всего на пару часов отлучился из чата - 400 новых сообщений! Еле дочитал 😂

👍🏻🔥🙈

Ребята, посоветуйте пожалуйста вменяемые тренинги по TDD и парному программированию/тестированию

TDD как практика , это часть модульного тестирования. Если само тестирование есть, то можно или доклады посмотреть, или эксперта/консультанта звать, чтобы сидел рядом и на РАБОЧЕМ коде показал как это работает. Вот например, в 2012 году я делал внутренюю лекцию про тестирование https://youtu.be/5_U-i7jannc А работу в паре... - нужно просто сеть вместе за ОДНУ клавиатуту. скорее всего иногда вы это уже деалете когда фиксите баги. Также работает метод: сесть вместе и сказать "Давай попробуем написать снчала тест." тут и парная работа и TDD

Кстати о, а есть ли знакомые с Tame Flow?

Кроме меня, да? %))

Ну да

Всем доброе утро!

👋

🖐

🖖

😎

Привет, есть вопрос про совмещение спринтов и больших ресерчей. Есть такая ситуация: периодически нужно делать всякую аналитику/ресерчи, чтобы понять, в каком виде делать крупные истории и делать ли их вообще. Сейчас не очень получается женить такие ресерчи с целью спринта – она про нанесение конкретного вэлью для клиента за спринт, а ресерч про «может быть в будущем, но это не точно». Уверен, не уникальная ситуация – кто как с этим живет?)

Привет, есть вопрос про совмещение спринтов и больших ресерчей. Есть такая ситуация: периодически нужно делать всякую аналитику/ресерчи, чтобы понять, в каком виде делать крупные истории и делать ли их вообще. Сейчас не очень получается женить такие ресерчи с целью спринта – она про нанесение конкретного вэлью для клиента за спринт, а ресерч про «может быть в будущем, но это не точно». Уверен, не уникальная ситуация – кто как с этим живет?)

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

С таким пониманием легче жить и работать

это понятная вещь

кроме нюанса «ни клиенту» – клиенту все же никак не стало от проведенного ресерча.

В остальном ресёрчи не отличаются от других историй - ограничьте обозримым куском большое исследование, выполните, остановитесь и осмотритесь, на основе полученной информации решите как действовать дальше

кроме нюанса «ни клиенту» – клиенту все же никак не стало от проведенного ресерча.

Стало. Чем меньше неопределенности тем ближе клиент к фиче. Очевидно ли это? Нет.

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

И что тут не так с точки зрения цели?

Стало. Чем меньше неопределенности тем ближе клиент к фиче. Очевидно ли это? Нет.

Окей, предложение расширить определение ценности понятно

Если цель текущего спринта расшить воронку - расшивайте. Будет цель - провести ресёрч - проводите.

И что тут не так с точки зрения цели?

Размытие фокуса. Вижу полезность «Цели спринта» в том, чтобы сфокусировать команду на определенном участке, для решение конкретной проблемы.

Если цель текущего спринта расшить воронку - расшивайте. Будет цель - провести ресёрч - проводите.

Вот цель спринта – расшить воронку. Есть ряд конкретных историй по расшитию + новые идеи приходят команде по мере работы в самом спринте. Но ресерч тоже нужно провести.

Понятно, что проведем, но – опять же кажется размытием фокуса

Размытие фокуса. Вижу полезность «Цели спринта» в том, чтобы сфокусировать команду на определенном участке, для решение конкретной проблемы.

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

Эм.. Поясните пожалуйста, "заказчик" ресёрча - это PO или разработчик?

PO

PO

Тогда не вижу проблемы.. Если обе цели ставит PO, он понимает из ценность, то ресёрч или нет - уже не имеет значения. Если две цели не противоречат друг другу, то можно их соединить в рамках одного спринта. Если противоречат, то берём в разные. Сложности с ресёрчами в моей практике как раз в том чтобы объяснить всем кроме разработчиков в чем ценность..

есть такой эвент как PBR там как раз рефайнится будущее беклога и ресерчи это как раз из этой оперы.

есть такой эвент как PBR там как раз рефайнится будущее беклога и ресерчи это как раз из этой оперы.

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

Тогда не вижу проблемы.. Если обе цели ставит PO, он понимает из ценность, то ресёрч или нет - уже не имеет значения. Если две цели не противоречат друг другу, то можно их соединить в рамках одного спринта. Если противоречат, то берём в разные. Сложности с ресёрчами в моей практике как раз в том чтобы объяснить всем кроме разработчиков в чем ценность..

Спасибо

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

PBR это необязательно отдельный митинг. так то его можно проводить "не более 20% времени от спринта"

интересный поинт

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

да, ресерч как самостоятельная цель – не наша ситуация

бывало мы разбивали PBR на неделю и встречались каждый день на час

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

PBR это необязательно отдельный митинг. так то его можно проводить "не более 20% времени от спринта"

тут https://www.scrumalliance.org/community/articles/2014/october/product-backlog-refinement пишут про 10 процентов, но думаю сама команда должна это решить

ну да, там usually

просто считается что PBR это митинг хотя это процесс доведения сторей до состояния когда их можно брать в спринт.

Да, спасибо, это полезная мысль, поедем с ней.

PBR это необязательно отдельный митинг. так то его можно проводить "не более 20% времени от спринта"

Ограничения в 20% нет, Скрам Гайд говорит что обычно PBR занимает не больше 10% от емкости команды в спринте. И PBR - это постоянная активность, а не событие Скрама. Например, вы с PO с утра попили кофе и прояснили несколько важных деталей касательно эпика - это тоже часть PBR. Скрам команда сама решает когда, где и как проводить PBR.

И нигде не сказано что research обязательно проводить через PBR. В одной из моих команд добрая половина историй была исследовательская.

есть еще такая штука как spike - таски на исследование, это мне кажется больше подходит для вас

http://agiledictionary.com/209/spike/

Ограничения в 20% нет, Скрам Гайд говорит что обычно PBR занимает не больше 10% от емкости команды в спринте. И PBR - это постоянная активность, а не событие Скрама. Например, вы с PO с утра попили кофе и прояснили несколько важных деталей касательно эпика - это тоже часть PBR. Скрам команда сама решает когда, где и как проводить PBR.

👍

Привет, есть вопрос про совмещение спринтов и больших ресерчей. Есть такая ситуация: периодически нужно делать всякую аналитику/ресерчи, чтобы понять, в каком виде делать крупные истории и делать ли их вообще. Сейчас не очень получается женить такие ресерчи с целью спринта – она про нанесение конкретного вэлью для клиента за спринт, а ресерч про «может быть в будущем, но это не точно». Уверен, не уникальная ситуация – кто как с этим живет?)

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

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

Это называется: управление инициативами. Техники проектного управления будут весьма хорошо работать.

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

Привет, есть вопрос про совмещение спринтов и больших ресерчей. Есть такая ситуация: периодически нужно делать всякую аналитику/ресерчи, чтобы понять, в каком виде делать крупные истории и делать ли их вообще. Сейчас не очень получается женить такие ресерчи с целью спринта – она про нанесение конкретного вэлью для клиента за спринт, а ресерч про «может быть в будущем, но это не точно». Уверен, не уникальная ситуация – кто как с этим живет?)

Dual track scrum возможно то что вам нужно

Там как раз дискавери юзают

Всем привет, я Андрей. Работаю в ООО "Моё дело" скрам мастером + full stack разработчиком. Не знаю чем могу быть полезен сообществу, я ещё молодой скрам мастер) Самому интересен опыт других скрам мастеров. Я из Саратова. В группу привёл другой участник)

✋️

Всем привет, я Андрей. Работаю в ООО "Моё дело" скрам мастером + full stack разработчиком. Не знаю чем могу быть полезен сообществу, я ещё молодой скрам мастер) Самому интересен опыт других скрам мастеров. Я из Саратова. В группу привёл другой участник)

Yo

Dual track scrum возможно то что вам нужно

привет Аман, все продвигаешь свой Дуал Скрам ))))