Друзья, всем привет! Помогите, пожалуйста, разобраться со следующим: в скрамгайде говорится, что Скрам-мастер оказывает услуги Владельцу продукта, в частности "способствует лучшему пониманию гибкости и её применения", в оригинале написано "Understanding and practicing agility". Я не до конца понимаю, что здесь имеется ввиду (про понимание ценностей и принципов Agile?), и почему это услуга только Владельца продукта? Какие конкретные действия здесь ожидаются от скрам-мастера?

Друзья, всем привет! Помогите, пожалуйста, разобраться со следующим: в скрамгайде говорится, что Скрам-мастер оказывает услуги Владельцу продукта, в частности "способствует лучшему пониманию гибкости и её применения", в оригинале написано "Understanding and practicing agility". Я не до конца понимаю, что здесь имеется ввиду (про понимание ценностей и принципов Agile?), и почему это услуга только Владельца продукта? Какие конкретные действия здесь ожидаются от скрам-мастера?

В общем и целом речь идёт о следовании манифесту. https://ru.wikipedia.org/wiki/Agile_Manifesto От скрам-мастера необходимо договариваться с владельцем продукта на предмет того, чтобы следовать ценностям и принципам гибкой разработки. Конкретные действия принимаются ситуационно. Самый простой пример действия по ценности "Работающий продукт важнее исчерпывающей документации.": Если видно, что баланс работы команды начинает заваливаться в сторону документирования в тот момент, когда это не надо или чревато - об этом необходимо разговаривать.

@JazzRuster спс)

Ребят, а как у вас реализованны команды дизайнеров и разработчиков по скрам? в спринте по идее не должно быть отдельных дизайн задач ибо они не несут ценности, верно?

Всем привет!

Как построить корпоративный портал на Jira?

вот по п.2 - а если дизайнер долго будет дизайнерить, ведь оценку времени сложнее для них дать

у нас сейчас что-то среднее между 1-2 ближе к 1)

ну я к тому что все же создание дизайн таски это не моветон?) хотя она не несет ценность)

вот вот)) у нас в спринте есть история где диз допиливает то что он немного надизайнерил и все утвердили. и есть так же дизайн таски, чтоб уходили вперед. но у нас 3 диза

Мы разбили дизайн на стадии: UX, прототипирование, дзизайн. UX работает в составе value team c PO, потому что это больше процесс создания требований. В команде есть дизайнер, который отвечает за "прототипирование" дизайна: в ранних спринтах мы создали набор UI elements и гайдлайнов и для каждой стори все, что касается UI дизайнер собирает из них (ну и да, он больше фронтендер, а не дизайнер) Если результат остро требует редизайна (обычно накапливается design debt за пару спринтов в местах, где функционал был совсем уж кастомным и гайдлайны работают плохо) - привлекается отдельный дизайнер, который делает чистый дизайн, как spike, а воплощение вносится в бэклог, как выплата технического долга.

это вот круто, но сложно конечно)

а как задачи ставятся ux дизайнеру?

Приходит идея фичи, команда PO над ней работает. В нейт отдельных "задач" UX дизайнеру - в зависимости от фичи на нем прототипы, пользоательские интервью, тестирование и аналитика.

ну тоесть без досок и тд, просто пилит и пилит

Круто)

ну тоесть без досок и тд, просто пилит и пилит

У value team свой канбан :)

а вот)

Но по нему движется стори, не отдельные задачи

У команды разработки, кстати, тоже

ух) ну вот опять приходим к варианту что дизайнера наверно надо б отделить))

А как переносите с одного борда на другой?

статусами можно думаю

Я так понял что два независимых борда

А как переносите с одного борда на другой?

НИкак. Борд PO команды это бэклог scrum команды :)

а у нас дизайн ин прогресс переходит в рейди ту дев, а это первая колонка в другой борде дева

PO команда работает над достижением definition of ready, скрам команда - над definition of done

По статусу дан в ПО борде отбираются задачи в беклог дев тима?

PO команда не работает в итерациях, а в single piece flow, в основном потому что там много работы с не всегда доступными стейкхолдерами и длинных исследований.

теоретически PO может поместить в топ бэклога элемент, который через PO team не прошел.

Если нет необходимости в исследованиях, например.

PO команда не работает в итерациях, а в single piece flow, в основном потому что там много работы с не всегда доступными стейкхолдерами и длинных исследований.

Это понятно, я имею в виду как два борда взаимодействуют. Ну в общем концепция понятна, остальное детали)

Или два флоу если вам угодно

Это не два флоу. Глобально это все 1 канбан. Всеактивности до, условно ready for sprint идут в рамках PO team

Я просто думал у вас команда по скраму, а ПО по канбану работают

Команда разработки - по скраму.

😁

Если совсем-совсем упростить, то команда PO готовит бэклог для scrum-команды.

А какой у вас инструмент? Жира?

Т.е. в упрощенной модели борды пересекаются как последняя колона команды PO - первая колонка бэклога

А какой у вас инструмент? Жира?

Жира, да.

И aha.io

Все понял) спасибо за подробное пояснение! 👍

Надо глянуть на аха.ио

На ваш взгляд есть преимущества по сравнению с жирой?

В работе с требованиями - да.

aha.io хороо подходит для product manager\product owner, и очень плохо для scrum team :)

Потому мы комбинируем.

Ясно)

spike - исследовательская задача с timebox

Ыоплощение в данном случае - мой кривой русский языка :)

Имел ввиду, что заадчи по реализации того, что надизайнено.

Вот происхождение я, пожалуй, и не знаю.

http://www.extremeprogramming.org/rules/spike.html

все оттуда же

Я не уверен, что оно именно оттуда пошло :)

Ну в safe ссылаются на xp

story, кстати. тоже не из XP в оригинале.

А откуда?

Я тут всех в заблуждение ввел в таком случае😂

Вообще я припоминаю что где то его до xp юзали

В XP story принесли из RAD, если я правильно помню, а в RAD из публикации о типах постановки задач из 80х

но в том виде, в котором мы привыкли - с персоной и goal - это да, XP

А вообще сама идея использования нарратива для передачи технических требований откуда-то из 70х пришла, но тут я уже теряюсь :)

Я про нее самое раннее упоминание помню в книге про проектирование интерфейсов из начала 80х, и там это обсуждалось уже как устоявшаяся концепция, которой активно пользуются.

Может кто привести примеры или дать ссылки, как формулировать DOR

Dor минимальный список этапов, который должна пройти задача, чтобы считаться завершенной.

Договаривайтесь внутри команды + po

Формат не важно, важно чтобы все приняли соглашение

Может корректироваться по результатам ретро

Перепутал это dod

Dor - соглашение, что должно быть , чтобы задачу можно было взять в работу. Тоже важно, чтобы команда и po были согласны

Тоже корректируется по результатам ретро итп

+1 к Михаилу. Команда сама решает, что для них DoR, что DoD

Расшифруйте Dor пож, пойду гуглить))

Definition of ready

Спасибо

http://scrumguides.org/scrum-guide.html#artifact-transparency-done про DOD

+1 к Михаилу. Команда сама решает, что для них DoR, что DoD

Крайне странное определение. Таким образом команда получает теоретическую возможность оттягивать взятие задачи в работу неопределенно долго. Собственно, об этом и мой вопрос, есть ли примеры Дор? Или все на уровне красивых слов?

Крайне странное определение. Таким образом команда получает теоретическую возможность оттягивать взятие задачи в работу неопределенно долго. Собственно, об этом и мой вопрос, есть ли примеры Дор? Или все на уровне красивых слов?

теоретически да, но так работает scrum в частности и agile в целом. Команде доверяют.