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

смотрел? https://youtu.be/NpbvtZV_sD8

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

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

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

Разные задачи по разному. Предполагается, что у всего будет ценность. Рефакторинг включаеться в стори, если рядом изменения. Для ci и тд, роль девопс может себе затягивать в спринт задачки, но там то же есть велью, например тайм ту маркет. Для автотестов и тд есть dod, без них не готова фича. Я часто в начале продукта ёмкость планирую с командой из расчёта, что есть сколько то задач по поддержки и остаток спринта можем что то полезное делать. В Safe спецом спринт предусмотрен, но это к Паше) вот

Мне кажется чисто вопрос о понимании po, что техдолг это расходы в будущем, такие задачи реально нужно продавать, но в конце концов, на ретро поднять вопрос, и пускай команда сама решит. Мне повезло с po, у нас нет такой проблемы)

Кстати а в лесс что они предлагают?

За внутреннее качество отвечает разработчик. Если PO будет приоритезировать технические задачи в бэклоге - это будет конфликт двух ролей - PO и разработчика в одном человеке. Ответственность PO - (в том числе) оптимально использовать мощность команды разработки, которую она готова генерировать. Ответственность команды разработки - (в том числе) поддерживать постоянный темп разработки за счет хорошего внутреннего качества. ИМХО, PO не решает ничего по техническому долгу. Решает команда разработки. И это не говорит о том, что не должно быть прозрачности. Так же это не говорит о том, что им не придется договариваться. Но по тех долгу решает команда. К тому же чаще всего PO некомпетентен в технических вопросах.

Главное что бы бэклог плоский был..

Основной посыл был - в разграничении ответственности команды разработки и PO. Тех долг это ответственность команды разработки. А значит ей и решать когда отдавать долго и можно ли давать в долг PO. PO не может принимать технических решений. Это было бы нарушением автономности, доверия, уважения, сфокусированности.

Команда должна проявить смелость и сказать - стоп, мы отдаем такой-то долг, это тоже важно, это нам мешает. Мешает - значит рушит нашу вовлеченность.

Да, но решать команде разработки. Все что я пишу - ИМХО ) Я не скрам мастер )

Мне очень нравятся твои советы! Они всегда по делу. Спасибо!

О, Бишкек. Привет.

Либо удаленно возьмете - не откажусь)

Да, вот читаешь в этом чате Сергея и думаешь - а scrum-то есть! И сразу охото так же ) Но пока пытаюсь у себя подвинуть коллег в сторону плотных коммуникаций, открытости, уважения и автономсности )

Либо удаленно возьмете - не откажусь)

Да, вот читаешь в этом чате Сергея и думаешь - а scrum-то есть! И сразу охото так же ) Но пока пытаюсь у себя подвинуть коллег в сторону плотных коммуникаций, открытости, уважения и автономсности )

коллеги, давайте про найм в личку)

А то поднадоело участвовать провальных стартапах без продакт вижна, без целей, даже юзер стори и те формулируются всегда от какого-то абстрактного "User" и про секцию "in order to" в половине случаев забывают, а другая половина формулируется спустя рукава и не дает реального понимания контекста

можете JTBD попробовать, там упор на "работы" а не на Персон

можете JTBD попробовать, там упор на "работы" а не на Персон

Сергей, если не сложно, напиши как вы работаете с этим?

Почему Павел ушел?

Речь про Pavel ведь? Он до сих пор тут

Сейчас расскажу как мы работаем с DoR (Defination of Ready). По сути для нас это фильтр для элементов PBI на входе в Спринт (элемент должен быть Sprint Ready). Без выполнения DoR элемент в Спринт не заходит. Мы работаем семью кросс-функциональными командами. У нас DoR состоит из следующих пунктов ( с небольшими пояснениями): 1. У элемента должна быть оценка ценности от Владельца Продукта. Мы используем для этого ряд чисел - 10,20,30,50,100,200,500,1000. Оценку имеет право дать только Владелец Продукта. 2. У элемента доджна быть оценка трудоемкости от команд. Мы используем модифицированный ряд чисел Фибоначчи. Это 1,2,3,5,8,13,21,40. Оценка дается на общем PBR (Overall PBR) с представителями команд с использованием карт и "Покера планирования". Оценку имеют право давать только Команды разработки. 3. Оценка трудоемкости элемента не дожна быть выше 13. Если при оценке получается больше 13 - на Общем PBR мы разбиваем ее на более мелкие фичи, используя в основном Story Mapping. Оценка на 13, это примерно неделя работы (зависит в основном от опытности команды), т.е такой элемент с очень высокой вероятностью будет сделан в Спринте. 4. У сложных элементов с оценкой 8 и 13 должны быть приемочные критерии. Для таких элементов организуется дополнительный PBR, командный или многокомандный. Это решается на общем PBR. Решение о том, какая команда будет брать элемент в Спринт максимально откладывается до планирования. Вся эта работа по превращению элементов в Sptint Ready проводится на PBRах - Общем, многокомандлном или командном. В результате к моменту планирования Спринта у нас есть приоритизированный список элементов со статусом Sptint Ready. На планировании команды просто выбирают себе (последовательно, в соответствии с приоритетом конечно) элементы Бэклога из этого списка. Примерно так.

Спасибо, схожу с ним)

Всем привет! Только вчера к вам присоединилась) Недавно скинули чек лист для тестирования в Экселе. Может кто то использует другие программы?

Всем привет! Только вчера к вам присоединилась) Недавно скинули чек лист для тестирования в Экселе. Может кто то использует другие программы?

доя ведения чеклистов по тестированию?

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

И кейсов. Мне интересно кто что использует и насколько это удобно

Если внутри Jira кейсы вести хотите- самый хороший вариант https://marketplace.atlassian.com/apps/1213259/test-management-for-jira

Мы в джире проекты ведём. Попробую этот модкль. Он бесплатный?

нет, не бесплатный:) хорошего и бесплатного мало ;) единственное бесплатное полностью - https://marketplace.atlassian.com/apps/1214038/qaspace-test-management