Как декомпозировать USER STORY, чтобы релизиться КАЖДЫЙ СПРИНТ? - Держите "Pop-it декомпозиции"

[@mur6225]

Спасибо, Дмитрий! Видно, что вы проделали большую исследовательскую работу) Классный стиль съемки и презентации, очень хорошо сочетается Продолжайте снимать, пожалуйста!

[@ЕвгенийКарышев-я1я]

Класс! Спасибо! Первый раз вижу такой всесторонний и системный подход к проблеме.

[@AntonAlekseev-h3s]

Это просто пушка!

[@boniacu]

Классный контент. Спасибо.

[@dblinov]

Спасибо за отзыв! Рад, что понравилось :)

[@rayrayray4653]

nice!

[@ЭркинКадыров-н9и]

Шикарно

[@АндрейК-с5в]

1. Сперва наговнокодить, а потом рефакторить ... ну ну ... рефакторить дороже выйдет. 2. И всё равно есть случаи когда заявка не лезет в спринт, хоть убейся. Например, 1 спринт - анализ, 2й - разработка, 3й - фикс найденных багов. 4й - факс фикса. Наверно, не стоит путать ЗАЯВКУ в спринт и ЗАДАЧУ/US?

[@dblinov]

@@АндрейК-с5в, интересный комментарий, но не совсем понятный. Говнокодить не нужно. Реализация в ключе «спринт на анализ, спринт на разработку, спринт на тестирование» - это не спринты по Скраму, потому что там суть в том, чтобы разработка, СТ, ИнтТ были в одном спринте. При этом спринт может быть и месяц. Если цикл занимает «три 2-недельных спринта», то по факту в команде 6-недельные спринты. И это тоже ок, так тоже работает, и работает хорошо. Только не стоит называть это «тремя спринтами».

[@dw_tv3992]

KISS - keep it simple, stupid! это правильная расшифровка аббривиатуры)

[@dblinov]

Знаю его, но использовал другой вариант :)

[@Alexander-dg5id]

Ох уж эта парадигма мышления манагеров. Сделайте по минимуму, завтрашнего дня не наступит, делаем MVP сегодня, сроки горят. * повторить 100 раз А чо разработка не может мне вставить микрофичу, и требует на нее 2 месяца? А там по просьбам менеджера сделали АД в коде, потому что менеджер убеждал что "Делайте все в одной сущности"

[@Alexander-dg5id]

Так что совет менеджерам: не знаешь - не лезь со своими советами по солюшену. Разрабы сами разберутся, дайте со своей стороны UserStory, UseCase, и отойдите в сторону.

[@dblinov]

Да, в этом и суть - РО дает небольшие US и не мешает по технике. Технические декомпозиции - со стороны команды. Разделение на PO и Developers: PO за бизнесовую составляющую, dev’ы за реализацию.

[@Alexander-dg5id]

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