Завидная устойчивость!)))

👍

Доброе утро! Вопрос: как лучше организовывать работу ux- дизайнера в скрам? Он работает в рамках своих спринтов с опрежением на 1 итерацию?

Он часть команды?

Это проект?

Он работает с разными командами, но на данный проект планируется полностью занять его, на 2-3 месяца

Тогда он не часть команды, скрам к нему вообще никакого отношения не имеет. Да, он должен начинать работать раньше других, big upfront, все дела

А как лучше отслеживать , планировать его работу и синхронизироваться с командой? Просто составлять план на неделю?

Ресурсное планирование, все дела. Научиться делать план проекта, например в Ганта и один из его элементов завязывать на ux-дисигнера.

Можно пойти также через сервисы. В любом случае это просто нужно уметь планировать

Здравствуйте, у нас две команды. Дизайнер в одной из них и работает на две. Участвует во всех событиях Scrum своей команды, и часто заглядывает на планирование и Ревью второй команды. При планировании Спринта в своей команде берет задачи для своей и также второй команды. Работает в основном с опережением, т.к. отличной практикой является наличие на планировании уже готовых дизайн-макетов или хотя бы wireframe. Но если в ходе планирования возникли идеи с небольшими доработками, то берет их в текущий спринт. Дизайнер должен быть в команде, т.к. тратить время каждый раз на погружение его в контекст накладно, а участвуя как минимум в Дэйли одной команды он всегда в контексте происходящего

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

Да сейчас никто не вникает, главное назвать скрамом, потому что скрам это хорошо и эффективно. Не совсем понимаю, почему людям приятно называть то, что у них, скрамом. Ведь главное же, что у вас есть какие-то практики, которые работают.
Многие не вникают просто, даже скрам гайд не читают (13 страниц в новой версии). Знания черпают из статей на хабре.
Это не про автора поста, а наблюдение. При этом в мире управления работами кучи других работающих подходов. Но нет, будем делать скрам. А если людей много - то сейф.

Есть приятные исключения и их много. Но большинство все же пугает.

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

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

SCRUM is easy to understand, complex to master (c)

А если его ещё и готовить правильно, то можно и много чего, что ему противопоставляют сделать :)

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

Конечно, людей многих можно понять, их часто не спрашивают - сверху спускают HIPPO решение и всем внедрять.

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

🤗

Как в анекдоте:

- Так мне Паваротти не понравился, картавит, в ноты не попадает...
- Вы были на концерте Паваротти?
- Нет, мне Рабинович по телефону напел.

😂Да, лирическое отступление.

Вообще интересно было бы знать, сколько людей, работающих со скрамом, читало скрам гайд.

Сколько читало канбан гайд (некоторые когда слышат канбан система - смотрят с недоверием😪😃).

Вообще, если необходимо, что бы он был в команде и работал вместе с командой, то его исследования и эксперименты будут результатами после PBR (возникающие вопросы у команды при раскапывании задачи) или конкретный эксперимент внутри спринта по проверке той или иной гипотезы. Это может не мачится с Sprint Goal.

Ловушек тут прилично, на самом деле. UX исследования, уезжающие слишком далеко, и идущие вне командных активностей и PBR - это прям потери потерь и антипаттерн, так как потом всем этим осмысленным выводам и результатам придётся столкнуться с суровой реальностью. Плюс, то что команда часть времени выделяет на задачу не в Sprint Goal может нарушить процесс сфокусированной работы.

Это всё возможно и я так делал, но я бы очень аккуратно проводил интеграцию UX в команду =)

У Скрам орга отдельный тренинг есть - https://www.scrum.org/courses/professional-scrumtm-user-experience-training

Это работает во всех сообществах.
А ведь еще можно «не читал, но осуждаю»)