я бы сразу тимлида и ит-дира кикнул за такой капитальный косяк.)

Господа вопрос ✓ A Scrum Team’s service level expectation (SLE) is an input into the various Scrum events. In which event will SLE provide the most benefit toward helping a Development Team achieve good flow (the best answer) 1.       Sprint retro 2.       Sprint review 3.       Sprint planning 4. Daily scrum

Колеблюсь между несколькими вариантами

Друзья, привет! Нужен совет ваш. Как вы разруливали работу разработки при ситуации, когда: у вас три проекта (концепция одна, но разные платформы: веб, мобайл и смарт, например) и на все эти три проекта одна команда бекенд и разные фронты, разные подходы и один проджект с разными продактами

Привет! Я правильно понял, что у вас несколько компонентых команд (бэк и по одной на каждую платформу) и один продукт?

Но точно не дейли, ибо дейли для девтим, а не скрамтим

Функционал реализуется одинаковый на разных платформах?

Попробуйте сформировать общий бэклог.

еще важно понимать - как приходят задачи в команду - стори это или расписанные таски?

Бэклог это набор требований. Это хотелки. О каких расписанных тасках идет речь?

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

об очень простых :D все очень по разному понимают на сколько свободной должна быть команда. поэтому хотелки эти максимально рассписывают в плодь до того что прописывают реализацию конкретную. и называют это беклогом.

обычно компонентные команды формируются вокруг микро менеджмента.

как надо - это перестраивать продукт на уровне бизнеса.

Так он уже есть, зачем его перестраивать?

#whois Дмитрй Барсуков, Agile-coach, бизнес консультант и классический коуч, фриланс. Помогаю командам и компаниям в agile-трансформации.

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

Привет! Ошибаешься. В Скрам-гайде нет ни слова про мобильные приложения и релиз :) Но посмотри его для начала.

Так можно ответить, наверное, на любой конкретный вопрос про применение скрама) спасибо за ответ

Привет! Кейсов много, гуглится просто "mobile development scrum", или тебе какие то конкретные нужны? Советую прочитать Ценностное предложение от Остервальдера, что бы не только механику Скрама брать, но и начать правильно :)

Так можно ответить, наверное, на любой конкретный вопрос про применение скрама) спасибо за ответ

Ну просто сейчас много всяких статей типа про Скрам, которые может и по твоей теме, но не про Скрам ... поэтому сложно на такой вопрос дать ответ. Давай дам ссылк на Скрам гайд, там 20 страниц. А появятся вопросы - уже спросишь, поможем.

Народ, а где можно про Lean Starup почитать, типа Скрам-гайла чтобы, первоисточник?

по-моему, провокационная статья из соседнего чата, как из вашего опыта? https://vc.ru/hr/46048-glavnaya-oshibka-agile-transformatorov-pochemu-product-manager-i-product-owner-eto-ne-odin-chelovek

с какой целью интересуешься?)

Интересный взгляд на проблему. Только сть некоторое недопонимание Скрама имхо. Скрам не отвергает менеджеров. Поэтому продуктовая группа вполне может иметь менеджера продукта, который как раз и будет вместе с Владльцем этим заниматься. Но он не будет иметь дело с разработкой, он будет смотреть вовне, это не руководитель в традиционном смысле. ... но если компания небольшая, с одной командой, например, то вполне возможно совмещение, не вижу тут противоречий со Скрамом. Очень здорово есть про это на https://less.works/less/framework/product-owner.html Перевод я недавно сделал, скоро будет русская страничка. Там как раз есть про этот дуализм и про менеджеров продукта.

Для саморазвития :) Читал мнение, что это базовые вещи для Владельа Продукта. Мне как Скрам-мастеру это нужно знать, я считаю.

по-моему, полезнее The Lean Product Playbook), как "базу" можно Бланка прочитать 😉

А вот еще у меня вопросик, потихоньку встает в полный рост. В процессе работы у ҡоманд возникает небходимость реализовать различные технические Стори. Там и техдолг и рефакторинг и улучшения связанные с CI/CD. Мы с Владельцем договорились, что все идет через Бэклог. Стори бьются на более мелкие, чтобы они могли быть закончены за Спринт. Собирабтся ообщества, обсуждают, оценивают, сплитят и т.д. Все как с обысными историями. Но вот ка доходит дело до приоритизации Бэклога, движение задач не то чтобы стопорятся, но идут более низким приоритетом что-ли ... все время возникают срочные бизнесовые стори ... Как быть? Есть практики? Не вносить их в бэклог, просто на планировании закладывать командам на это время? Теряем прозрачность ... Выделять некий квант, например, 25% и брать такой же процент технических сторей?

мы делаем "квоту" на баги в 10% времени спринта

А вот еще у меня вопросик, потихоньку встает в полный рост. В процессе работы у ҡоманд возникает небходимость реализовать различные технические Стори. Там и техдолг и рефакторинг и улучшения связанные с CI/CD. Мы с Владельцем договорились, что все идет через Бэклог. Стори бьются на более мелкие, чтобы они могли быть закончены за Спринт. Собирабтся ообщества, обсуждают, оценивают, сплитят и т.д. Все как с обысными историями. Но вот ка доходит дело до приоритизации Бэклога, движение задач не то чтобы стопорятся, но идут более низким приоритетом что-ли ... все время возникают срочные бизнесовые стори ... Как быть? Есть практики? Не вносить их в бэклог, просто на планировании закладывать командам на это время? Теряем прозрачность ... Выделять некий квант, например, 25% и брать такой же процент технических сторей?

https://habr.com/post/417101/ интересная статья про DoR. Примерно так мы рабоиаем с этим инструментом.

Команде тоже чаще всего, в скраме нет позиции архитектора, в итоге через n итераций приходят к разбитому корыту во имя бизнеса)))

архитектура тоже должна быть адаптивной же 😉

С архитектурой все норм у нас. Архитекторов нет, команды сообща вырабатывают решения.