Пользовательские истории
Vložit
- čas přidán 12. 09. 2024
- 00:25 Что такое User Story
01:16 INVEST
03:00 Definition of Readiness
03:35 Definition of Done
04:19 Критерии приемки
05:35 User Story & Tasks
06:00 Техническая User Story
06:35 Epic
07:50 Атрибуты User Story
08:45 Пример пользовательской истории с критериями приемки
09:48 Изучение английского языка
🚩Я учу английский язык в Skyeng - по ссылке skyeng.ru/invi...
2 бесплатных урока в случае покупки любого пакета (но первое пробное занятие бесплатно)
⚡ Телеграмм канал: t.me/it_bat
⚡ Второй канал: / @live-hw8dv
Спасибо за Ваше видео!
У Вас полезный контент, не останавливайтесь, пожалуйста.
отличное видео, спасибо. Многое разъяснено очень хорошо. Некоторые вещи не понимал. С примерами тоже прям огонь. И вот что я люблю это встроенная реклама, где рассказывают честно твою и свою ценность :) респект.
Отличное конструктивное описание, спасибо! Можно ли также осветить тему про use cases?
Вы молодец! Полезная информация, рассказываете понятно, спокойно, честно. 👍
Перерыл несколько видео по этой теме, у тебя эта тема понятнее всего раскрыта!
Спасибо за выпуск, очень информативно, особенно если только начинаешь понимать тонкости будущей профессии
Очень полезное видео, спасибо большое, Сергей!!
У вас отличный канал! Когда будут новые выпуски?
Спасибо! Темы есть, осатлось найти время
хотелось бы про бизнес процессы видео)
Спасибо за предложение, учте
Классно что с примерами. Не до конца понял по критериям приемки. Просто какую то вариацию сценариев сами формируем?
Критерии приемки и есть самые обычные требования, которые нужно реализовать чтобы история считалась завершенной с точки зрения Product Owner.
@@it_ba оч классно, я пересмотрел и еще подразобрался. Действительно ведь требование может быть реализованно в соответствии с формулировкой, но не соответствовать ожиданиям здесь и полезно dod и критерии.
Можно осветить тему резюме для новичков?
Обязательно сделаю такой выпуск
Как найти ваш канал в тг?
Ссылка под каждым видео - t.me/it_bat
А почему эпики декомпозируются в стори, а не фичи?
Бэклог продукта содержит 4 элемента, 2 видимых: фичи (как правило описываются в виде стори, эпик - большая стори, которая требует декомпозиции) и баги; 2 невидимых: технические стори и тех.долг.
На планировании для реализации стори определяются конретные задачи (таски).
@@it_ba хз в иностранных проектах иерархия всегда одна была на моем опыте - Эпик - Фичи - Стори (и в них тех.таски уже)
@@mz6180 стори может использоваться чтобы описать фичу, фича не входит в какую-то "иерархию". Можно обратиться к BABOK как "последней" инстанции
"User stories capture the needs of a specific stakeholder and enable teams to define features of value to a stakeholder using short, simple documentation"
"User stories help teams to explore and understand the feature described in the story and the value it will deliver to the stakeholder."
В структуре стори who-what-why: "• What: a necessary action, behaviour, feature, or quality."
Не понятно, что значит "разбивать историю на таски". Таски и истории - независимые элементы в бэклоге. Что тогда в спринт закидывать? Что оценивать? Также не понятно, какие критерии приёмки должны быть у тасок, как они выглядят?
Оценивается история. В спринт закидывается и история и таски - разработка истории завершена, когда все таски по ней реализованы.
История не разбивается на таски - таски это индивидуальные задачи разработчиков. Если у вас не все фулстаки, то над одной историей будут работать как минимум несколько человек - им и нужны индивидуальные таски.
У тасок не критерии приемки, а Definition of Done - например проведено 2 код-ревью, все автотесты успешно прошли и т.п.