Как декомпозировать USER STORY, чтобы релизиться КАЖДЫЙ СПРИНТ? - Держите "Pop-it декомпозиции"
ฝัง
- เผยแพร่เมื่อ 2 ต.ค. 2024
- Почему история должна быть меньше 1 спринта?
-----------------
Тренинг и воркшоп User Story Mapping dblinov.com/tr...
Статья о User Story Mapping dblinov.com/bl...
Статья о способах декомпозиции Историй dblinov.com/bl...
Статья с 38 доводами "Почему история должна быть меньше 1 спринта?" здесь dblinov.com/bl...
-----------------
Зачем нужно, чтобы Юзер-стори умещалась в один спринт? Чем полезны истории размером меньше 1 итерации? И даже больше - зачем разделять истории на ещё меньшие куски?
В общем и целом, одна или несколько задач, завершаемых до состояния DoD в каждом спринте, позволяют вам соблюдать принцип инкрементальности Скрама. Но что это означает, и зачем этому принципу следовать? У работы инкрементами множество плюсов, и многие из них перечислены ниже.
![เปิดบ้าน พี่ตูน Bodyslam หลังใหม่คนแรก ที่ภูเก็ต l [Nickynachat]](http://i.ytimg.com/vi/flFwcmyDQSk/mqdefault.jpg)
Это просто пушка!
Класс! Спасибо! Первый раз вижу такой всесторонний и системный подход к проблеме.
Классный контент. Спасибо.
Спасибо за отзыв! Рад, что понравилось :)
Спасибо, Дмитрий! Видно, что вы проделали большую исследовательскую работу) Классный стиль съемки и презентации, очень хорошо сочетается
Продолжайте снимать, пожалуйста!
KISS - keep it simple, stupid! это правильная расшифровка аббривиатуры)
Знаю его, но использовал другой вариант :)
nice!
1. Сперва наговнокодить, а потом рефакторить ... ну ну ... рефакторить дороже выйдет. 2. И всё равно есть случаи когда заявка не лезет в спринт, хоть убейся. Например, 1 спринт - анализ, 2й - разработка, 3й - фикс найденных багов. 4й - факс фикса. Наверно, не стоит путать ЗАЯВКУ в спринт и ЗАДАЧУ/US?
@@АндрейК-с5в, интересный комментарий, но не совсем понятный. Говнокодить не нужно.
Реализация в ключе «спринт на анализ, спринт на разработку, спринт на тестирование» - это не спринты по Скраму, потому что там суть в том, чтобы разработка, СТ, ИнтТ были в одном спринте. При этом спринт может быть и месяц. Если цикл занимает «три 2-недельных спринта», то по факту в команде 6-недельные спринты. И это тоже ок, так тоже работает, и работает хорошо. Только не стоит называть это «тремя спринтами».
Ох уж эта парадигма мышления манагеров. Сделайте по минимуму, завтрашнего дня не наступит, делаем MVP сегодня, сроки горят.
* повторить 100 раз
А чо разработка не может мне вставить микрофичу, и требует на нее 2 месяца? А там по просьбам менеджера сделали АД в коде, потому что менеджер убеждал что "Делайте все в одной сущности"
Так что совет менеджерам: не знаешь - не лезь со своими советами по солюшену. Разрабы сами разберутся, дайте со своей стороны UserStory, UseCase, и отойдите в сторону.
Да, в этом и суть - РО дает небольшие US и не мешает по технике. Технические декомпозиции - со стороны команды. Разделение на PO и Developers: PO за бизнесовую составляющую, dev’ы за реализацию.
@@dblinov когда так - да, но часто бывает, что ПО занимает позицию не посередине между бизнесом и разработкой, и выполняет свою функцию, а как бы "проксирует заказчика", забивает на качество регулярно, получая фичи быстро, тем самым в моменте получая профит в моменте, и нанося ущерб в будущем проекту. Если приводить пример, то это как микрозайм - проценты по техдолгу не заставят себя ждать.
Шикарно