И работа на нем это 80% успешности Спринта, имхо

Вот смотри, зачем, например, нужны product persona?

Ну видимо чтобы как раз продакта все врмя не дергать

А что persona содержит?

Нужды

Давай уточню: почему персона сожержит усредненный портрет, а не конкретного человека?

Описание что и как, каков он наш прльзователь

Потому, что это 80% выручки скорее всего

Хотя по всяому бывает я думаю.

Вот. Потому что пользователей много. Персоны группируют проблемы.

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

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

Это помимо того, что кто-то должен провести spike-like анализ пользователей, чтобы эту персону составить :)

Да я не против. Но зная это, почему к

команда не может принимать сама решения?

Ну честно пихать стори типа построить лунапарк за спринт имхо чересчур

Может. На основе проблем она и принимает решения.

scrum team :)

В большинстве случаев это возможно. И их это мотивирует, кстати. Программист это творчество, это удожни ;)

В том и отличие, что в спринт беклог падает лишь задача уровня все понимают как делать

напомните, пожалуйста, было тут с месяц(два?) назад достаточно формализованное определение различий между PO и PM - листаю, не нашёл пока

scrum team :)

Ну в нашем случае это проблемно. Я повторюсь, сдохнет продакт от такого темпа

В большинстве случаев это возможно. И их это мотивирует, кстати. Программист это творчество, это удожни ;)

как раз в большинсве случаев это не возможно. Даже если на ревью есть живые пользователи :)

ну вы конечно выдали 400 сообщений за пару часов...

как раз в большинсве случаев это не возможно. Даже если на ревью есть живые пользователи :)

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

Т.е. реально - команда _может_ заниматься уточнением PBI самостоятельно. Но большинство процедур уточнения PBI через живых пользователей потребуют времени, которое убъет продуктивность внутри спринта :)

А деливерится чо в промежутке?

ну вы конечно выдали 400 сообщений за пару часов...

С Павлом очень интересно дисаутировать :) Че, правда 400?

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

Сергей, мы вообще о разном говорим, такое ощущение: У программера Васи вопрос по конкретному элементу PBI, Он может а) задать вопрос PO б) найти кого-то из тех юзеров, с которых писалась "as a" часть в юзерстори, задать вопросы им, попытаться понять ответы

Т.е. реально - команда _может_ заниматься уточнением PBI самостоятельно. Но большинство процедур уточнения PBI через живых пользователей потребуют времени, которое убъет продуктивность внутри спринта :)

Тут надо баланс, думаю от ситуации зависит. С умом надо.

Эффективно? Не очень

Второй вариант: команда "тимур и его команда" на второй день спринта закончили сторю, багов нет, все на стейджинге. Они должны ждать спринт ревью, чтоб PO это показать и фидбэк получить?

Опять же вопрос эффективности.

Сергей, мы вообще о разном говорим, такое ощущение: У программера Васи вопрос по конкретному элементу PBI, Он может а) задать вопрос PO б) найти кого-то из тех юзеров, с которых писалась "as a" часть в юзерстори, задать вопросы им, попытаться понять ответы

Ага :)

Опять же вопрос эффективности.

Скрам про резүльтативность, ценность для пользователя, не?

А чат то ожил. (с) :)

Скрам про резүльтативность, ценность для пользователя, не?

во первых, не для пользовтаеля. User-Centric Design частью скрама не является (как и юзерстори) :)

Вто вторых, внутренняя эффективность тоже очень важна. "Почему мы не деливерим больше ценных сторей для юзера? потому что разработчики заняты обработкой фидбэка от юзеров" :)

Не буду спорить. Рука уже писать устала. Хорошо уже, что мы оба понимаем разницу между результативностью и эффективностью. С Тобой приятно общаться :)

А деливерится чо в промежутке?

Не понял вопрос.

Кстати, если уж я упомянул LSC. В рамках этой концепции все предположения нужно проверять самым дешевым из возможных путей. Почти вов сех случаях это будет прототип, а не имплементация на практике.

Но сам процесс выбивается из scrum.

Кстати, если уж я упомянул LSC. В рамках этой концепции все предположения нужно проверять самым дешевым из возможных путей. Почти вов сех случаях это будет прототип, а не имплементация на практике.

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

В итоге получается двухпотоковая структура - PO и его группа отморозков интервюирует юзеров, делает предположения, струячит прототипы и уже на основе вот этого вот всего готовит PBI

И scrum team из инженеров дружно по бэклогу PBI деливерят.

При кажущейся эффективности получается водопад :)

И все счастливы?))

У нас дизайнеры в командах. Нет водопада.

Сергей, это хорошо. А UX у вас в командах?

А Сазерленд поет и танцует как в индийских фильмах

Или у вас UI/UX гибрид?:)

Сергей, это хорошо. А UX у вас в командах?

Все в командах.

А как команда обрабатывает ситуацию, в которой UX проводит интервью? т.е. где его вклад в PBI в пределах спринта?

Интервью можт быть на этапе PBR, вся реалиация в Спринте.

Сергей, интервью занимают 3-5 дней :)

оффсайт чаще всего.

Ну значит мы о разном.

Ага.

Т.е. для полноценной персоны надо иметь данные хотя бы от 5 живых людей (это эпирическе даныне)

Каждое интервью - 2-3 часа занимает.

+ они выматывают, т.е. подряд даже два провести - тот еще подвиг

Горшочек не вари, я сдаюсь.

Ты сколько уже в этой теме?

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

13 лет :)

А я полгода.

Дай осмыслить, мой мозг уже кипит.

:)

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

От ситации зависит, согласен.

В общем, резюмируя - я верю в двухкомпонентную структуру, зацикленную через PO :)

Первый компонент работает над валидацией, верификацией и подготовкой требований, второй - над воплощением.

Я запутался. Ты про предварительную подготовку прототипов?

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

Это все, теоретически, можно делать в одном спринте. Но на практике поулчается ОЧЕНЬ неэффективно. мало того, что команда огромной получается, так еще и пол команды работает неависимо от второй половины.

Не нравится мне такой вариант.

Увеличить длину Спринта в таком случае не вариант?

Во первых, увеличение длинны спринта почти никогда не решение проблемы :)

Вто вторых, да, все в LeSS Guide написано верно.

Делать командой один Спринт прототипы, второй реализаию?