2:40 автор, вы историю то погуглите. Не только 20-25, а ровно 27 лет назад user story не просто использовались, но и были придуманы именно для software development. И придумал их Kent Beck в 1997, тот самый, который написал в 1999 книгу Extreme Programming Explained. Так что "в других сферах, но не в ИТ" - это вы выдумали. Этот подход к декомпозиции функциональных требований наряду с use-case широко использовался с 2000х и используется сейчас, и довольно часто эти два метода используются вместе, а не вместо.
Не очень понимаю принцип Independent. Допустим у нас две стори: 1) users list + add/edit users 2) remove users. Вторая зависит от первой, следовательно она dependent. Но первая не зависит от второй, она самодостаточна и independent. Правильное ли это декомпозиция? Полностью избавиться от зависимостей невозможно. Если у вас социальная сеть, например, то без имплементации регистрации юзера ничего нет, т.е. все остальные стори/эпики зависят от регистрации.
я думаю, что тут смысл в том, что бы "зависимые" стори всегда делались ПОСЛЕ тех, от которых они зависят....понятно, что новый функционал часто будет зависеть от уже имеющегося)
@@ДаниилНестеренко-г3ф понятно, то есть это про такую декомпозицию, чтобы не было блокеров в разработке, если идти последовательно от первой до последней Стори.
Чтобы стори не вызывали недопонимания их нужно проговаривать, т.к. их придумали больше не как форму документации, а как способ повествования.
Благодарю! Прекрасный докладчик!
Большое спасибо за вебинар! Информация очень полезная
Очень толковое видео, спасибо.
Отлично. Тестировщикам тоже смотреть!
2:40 автор, вы историю то погуглите. Не только 20-25, а ровно 27 лет назад user story не просто использовались, но и были придуманы именно для software development. И придумал их Kent Beck в 1997, тот самый, который написал в 1999 книгу Extreme Programming Explained. Так что "в других сферах, но не в ИТ" - это вы выдумали. Этот подход к декомпозиции функциональных требований наряду с use-case широко использовался с 2000х и используется сейчас, и довольно часто эти два метода используются вместе, а не вместо.
@@VyacheslavM1 В‘ячеславе, спасибі за уважність!
Не очень понимаю принцип Independent. Допустим у нас две стори:
1) users list + add/edit users
2) remove users.
Вторая зависит от первой, следовательно она dependent. Но первая не зависит от второй, она самодостаточна и independent. Правильное ли это декомпозиция?
Полностью избавиться от зависимостей невозможно. Если у вас социальная сеть, например, то без имплементации регистрации юзера ничего нет, т.е. все остальные стори/эпики зависят от регистрации.
я думаю, что тут смысл в том, что бы "зависимые" стори всегда делались ПОСЛЕ тех, от которых они зависят....понятно, что новый функционал часто будет зависеть от уже имеющегося)
@@ДаниилНестеренко-г3ф понятно, то есть это про такую декомпозицию, чтобы не было блокеров в разработке, если идти последовательно от первой до последней Стори.
@@StasLeo1987 логично, так как вряд ли будут разрабатывать, например, условные чаты, прежде авторизации, без которой эти чаты по сути бесполезны.
так разве это не таски внутри одной стори?
Спасибо за информацию!)
Благодарю за интересное видео!
Спасибо, за полезную информацию
класс, спасибо за вебинар!
Спасибо !
Мне не хватило технического описания процессов.
Мне не хватало реальных примеров из разработки
Посмотрим что тут!!
1:30 привет флешбэки "один икс бэээээээт" ... так вот кто крайний :D
S - Small, почему слева и справа от "-" поставили по два пробела, а у остальных один?_)) Спасибо за видео!
Полагаем, что это опечатка )
спасибо, супер
круто спасибо
thanks
from test pro?)