Не глупые, Наиль. Глупых вопросов вообще нет. Но да - термин "требование" нагружен отрицательными смыслами, от которых я точно хочу дистанцироваться (Денис, скорее всего, тоже). Один из параметров дистанцирования он уже обозначил - верификация/валидация. Есть и другие.

Вооот, это уже другой вопрос. Я просто хочу сказать, что валидация/верификация - это процесс исследования, поиска потребностей. Когда потребность понятна, рождаются требования для ее решения. Ну или задачи. Как это ни назови, но это в каком-то виде должно быть формализовано, хоть устно на митинге. Чтобы было понятно - что делаем то. И я не понимаю, какими отрицательными смыслами нагружено это слово...

Не глупые, Наиль. Глупых вопросов вообще нет. Но да - термин "требование" нагружен отрицательными смыслами, от которых я точно хочу дистанцироваться (Денис, скорее всего, тоже). Один из параметров дистанцирования он уже обозначил - верификация/валидация. Есть и другие.

и как вы в данном случае переводите requirements?

Дайте, пожалуйста, ссыль на определение user story, которое является тру. Потому как ещё раз освежив память и пройдясь по первым ссылкам в гугл, все же фигурирует слово - требование в основе определения. Взять ту же Википедию, хотя сейчас меня, похоже, закидают тухлыми яйцами) https://ru.m.wikipedia.org/wiki/Пользовательские_истории

Изначально user story применялись в xp, куда он пришел из какой-то другой компании насколько я помню. Как таковые user story обозначают предмет обсуждения, никак не требования.

Изначально user story применялись в xp, куда он пришел из какой-то другой компании насколько я помню. Как таковые user story обозначают предмет обсуждения, никак не требования.

Обсудили, что в итоге рождается?

User story)

То есть команда обсуждает историю, в итоге рождается другая история?)

Кажется я непонятно выразил свою точку зрения. Перефразирую. Требования являются окончательными, user story- открыты для обсуждения в течения спринта.

Кажется я непонятно выразил свою точку зрения. Перефразирую. Требования являются окончательными, user story- открыты для обсуждения в течения спринта.

Я про то же

US по сути формализация потребности, которую надо решить 100500 способами

Команда обсуждаеи как это сделать максимально эффективно в рамках действующих ограничений

После чего появляются уже конкретные требования

Я так вижу этот процесс...

http://www.extremeprogramming.org/rules/userstories.html

Обратите внимание на то, что чтобы получить детали разработчики идут к клиенту. В рамках скрама они уже к продакт оунеру идут.

Именно это я имел в виду под открытостью для обсуждения)

Не глупые, Наиль. Глупых вопросов вообще нет. Но да - термин "требование" нагружен отрицательными смыслами, от которых я точно хочу дистанцироваться (Денис, скорее всего, тоже). Один из параметров дистанцирования он уже обозначил - верификация/валидация. Есть и другие.

Тоже думаю требования перегружены смыслом. У меня сразу ассоциация с ТЗ. Представляю что тз пишут на каждую историю))

Обратите внимание на то, что чтобы получить детали разработчики идут к клиенту. В рамках скрама они уже к продакт оунеру идут.

Хмм, не думаю, что в scrum есть ограничения к кому идти за уточнениями, РО не должен работать передастом

В общем, понятно) Цель - сделать акцент на user needs. А требование делает акцент на хотелку пользователя, которая на самом деле его истинную потребность не решит

Вообще в скрам гайде и про доску ничего не написано. Не то что про юзер стори)

Может не решить

В общем, понятно) Цель - сделать акцент на user needs. А требование делает акцент на хотелку пользователя, которая на самом деле его истинную потребность не решит

Думается мне что так и есть

Вообще в скрам гайде и про доску ничего не написано. Не то что про юзер стори)

А разве должно быть написано?

Вспомним манифест

Вообще в скрам гайде и про доску ничего не написано. Не то что про юзер стори)

Что бы Вы написали про доску?

А разве должно быть написано?

Это я к тому, что у многих юзер стори со скрамом ассоциируется, как и доска

Что бы Вы написали про доску?

Не понял сути вопроса. Предлагаете мне скрам гайд V2 выпустить?))

Мне интересно, чем бы дополнили

А как задача должна диктовать реализацию?

Задача предьявляет изменения в сценарии использования

Мне интересно, чем бы дополнили

К сожалению ничем) мне бы изучить что уже есть

В общем, понятно) Цель - сделать акцент на user needs. А требование делает акцент на хотелку пользователя, которая на самом деле его истинную потребность не решит

Да, перенос акцента с "как" на "что". Требование зачастую слишком детализировано, содержит описание реализации а не проблемы. User story - это постановка проблемы, то есть "что хочу", а "как мы это сделаем" решает уже команда

Вообще в скрам гайде и про доску ничего не написано. Не то что про юзер стори)

Ну да 🙂 И про стори пойнты тоже ни слова 😉

Да, перенос акцента с "как" на "что". Требование зачастую слишком детализировано, содержит описание реализации а не проблемы. User story - это постановка проблемы, то есть "что хочу", а "как мы это сделаем" решает уже команда

👍 и следствие команда разработчиков гибкая и в текущем контексте находит лучшие решения из возможных

Это все практики. Скрам же фреймворк, не методология

Отличие существенное

Животрепещащая дискусия про пользовательские истории\требования/пожелания к продукту продолжится ?

yep

Глаголь :)

Нет, я хочу сказать, user story по сути и есть требование. Написано в другой форме, да. Но по итогам рождаются задачи для доработки продукта. И для проверки идеи тоже нужно сформулировать требования, чтобы получить MVP. Все об одном и том же.

если исходить из идеологии формалистов, не признающих ничего кроме требований, и считающих, что главное в них это описание функции или целевого свойства, то user story — это не требование, а диполь, трассировка из 2-х требований

Плохие user story являются трассировкой технического требования на пользовательское

Хорошие user story — трассировка пользовательского требования на бизнесовое

но нужно быть совсем технократом и человеком чуждым логике, чтобы игнорировать модальность высказываний

понятно, что «я хочу» — это совершенно другая модальность, нежели «система должна X», «система должна позволять Y»

говорить, что пользовательская история эквивалентна требованию это всё равно, что считать, что «я тебя хочу» эквивалентно «ты должен меня трахнуть»

говорить, что пользовательская история эквивалентна требованию это всё равно, что считать, что «я тебя хочу» эквивалентно «ты должен меня трахнуть»

Нет, есть еще история - "ты не знаешь, что ты хочешь меня трахнуть" :))

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

да, всё так

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

В любом случае на выходе должны сформироваться требования, после всех филосфских рассуждений о том, что нужно пользователю и проверки этих суждений. Требования могут быть сформированы да хоть в голове конкртеного исполнителя

"В любом случае на выходе должны сформироваться требования" — Наиль, классный авто-пример! ) Почему должны? кому должны?

"В любом случае на выходе должны сформироваться требования" — Наиль, классный авто-пример! ) Почему должны? кому должны?

Ну, ок, не должны. Если хочешь сделать задачу, сформулируй, пожалуйста конкретные требования для себя :)) Ну, пожалуйста :)

Но месседж Дениса и Андрея понятен - надо уходить от совковой интерпретации что кто-то должен к клиентоориенториентированности и постоянному поиску. Ну, я так понял, по крайней мере

Можно заменить слово "требования" на "задачи". Тогда предмет спора будет исчерпан? :)

А то Денис реагирует как на красную тряпку)

"В любом случае на выходе должны сформироваться требования" — Наиль, классный авто-пример! ) Почему должны? кому должны?

ну вот приходит чувак тачку покупать и общается с менеджером, менеджер формирует юзер стори какая примерно тачка нужна покупателю, а потом идет в гараж и кладовщику грубо говоря говорит дай мне вот ту модель такогото цвета и кожаным салоном

это не требования?

клиент конечно не с требованиями прихоит а с историей

не так разве?

а это что, продуктовая разработка?

давайте я буду себя копипастить

в заказной и внутренней разработке при создании систем и решений могут вполне существовать «требования», хотя местами это мешает хорошей работе в продуктовой разработке при создании продуктов для открытого рынка большинство здоровых компаний понимают, что у них не требования, а идеи

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

это не требования?

У РО идеи, а исполнителям то все равно нужны конкретные указания к действию, разве нет? Что система «должна», а что «не должна». «Должна» не кому-то в плане морального долга, а «должна делать», чтобы «воплотить идею в жизнь». По-моему тут просто каламбур..

В любом случае на выходе должны сформироваться требования, после всех филосфских рассуждений о том, что нужно пользователю и проверки этих суждений. Требования могут быть сформированы да хоть в голове конкртеного исполнителя

Эмм, я не скажу за всю Одессу, но мне кажется. что не многие люди формулируют требования в голове. Мне всегда казалось,что оперируют задачами

Прикол. Нет конкретные задачи не нужны. Менеджер приходит к кладовщику и объясняет историю клиента, кладовщик сам решает что лучше со склада подойдет

Остальные приёмы, что бы потерь в коммуникации избежать

Критерии приёмки например

Прикол. Нет конкретные задачи не нужны. Менеджер приходит к кладовщику и объясняет историю клиента, кладовщик сам решает что лучше со склада подойдет

а когда он это решил чтобы выбрать к какому месту склада пойти за конкретной тачкой ему нужно сформировать для себя конкретные требования

Ну для того как в голове работает эсть отдельный тред, там бич многозадачность

Это зависит от скилла команды. Кому-то ничего не надо объяснять, а с кем-то за ручку приходится ходить. Или хотите сказать, что надо сходу отсекать тех, кому надо разжевывать, и работать только с профи? (Где ж их взять то еще)

Это зависит от скилла команды. Кому-то ничего не надо объяснять, а с кем-то за ручку приходится ходить. Или хотите сказать, что надо сходу отсекать тех, кому надо разжевывать, и работать только с профи? (Где ж их взять то еще)

Нет, есть придусмотреная скрамом система улучшений

Ретро, например

На 30м клиенте соберемся с кладовщиком и решим что улучшить, что бы довольные клиенты были

Там же таймбоксинг важнее

Итерации какие то еще

Эмм, я не скажу за всю Одессу, но мне кажется. что не многие люди формулируют требования в голове. Мне всегда казалось,что оперируют задачами

Философский вопрос, как и наше обсуждение)

Да нет, у нас методологическое обсуждение в свободной форме

говорить, что пользовательская история эквивалентна требованию это всё равно, что считать, что «я тебя хочу» эквивалентно «ты должен меня трахнуть»

Денис, отлично 🙂

Философский вопрос, как и наше обсуждение)

Наиль, вопрос же в следующем. Зачем нам формализованные требования ?

Зачем мы используем пользовательские истории ?