Комментарии 12
Я понимаю, что это перевод, но…
Во всей статье прямо-таки не разу не разъясняется, что вообще значит словосочетание «Пользовательские истории»! Нет сноски, что это не пользовательские истории вообще (ну типа, приходит пользователь и рассказывает историю… Не, ну а чего — сейчас все уже настолько в agile, что это очевидно? А я вот гуглил...), а термин agile-философии… Ссылочку бы на определение. Да и сама статья откровенно ни о чем.
Во всей статье прямо-таки не разу не разъясняется, что вообще значит словосочетание «Пользовательские истории»! Нет сноски, что это не пользовательские истории вообще (ну типа, приходит пользователь и рассказывает историю… Не, ну а чего — сейчас все уже настолько в agile, что это очевидно? А я вот гуглил...), а термин agile-философии… Ссылочку бы на определение. Да и сама статья откровенно ни о чем.
+4
Как видите Ваш риквест дефиниции пользовательских историй показался анонимусу токсичным.
PS. формально мой каммент написан на русском.
-3
Хорошо, что вы мне объяснили, плохо, что я ничего не понял… ;)
+2
"Ваша просьба дать определения понятия "пользовательские истории" не понравилась неназванным пользователям хабра" (это судя по минусам Вашему камменту).
Та же фигня с "пользовательскими историями" — неумение автора по-людски переводить термины заменяется прямым гуглепереводом и контекстом "ну все же знают".
0
А, теперь понял… ) Я примерно так и предполагал, но…
Я просто с телефона читал — там детально посмотреть сложно, а общая оценка была нейтральной.
Ну, анонимусу виднее! ) Я свое мнение высказал: я считаю, что словосочетание «пользовательские истории» состоит из обычных общеупотребимых слов и если речь идет не об общем их применении, а о специальной терминологии из определённой области, то нужно давать сноску! А там может и правда я от жизни отстал и не понимаю устоявшихся выражений…
Я просто с телефона читал — там детально посмотреть сложно, а общая оценка была нейтральной.
Ну, анонимусу виднее! ) Я свое мнение высказал: я считаю, что словосочетание «пользовательские истории» состоит из обычных общеупотребимых слов и если речь идет не об общем их применении, а о специальной терминологии из определённой области, то нужно давать сноску! А там может и правда я от жизни отстал и не понимаю устоявшихся выражений…
+1
Коллеги, "пользовательские истории" — это вполне устоявшийся русскоязычный термин. Если вдруг он не знаком… ну вы сами знаете, как исправить эту ситуацию.
0
Пользовательские истории — это прежде всего шанс увидеть различные варианты реализации, чтобы потом можно было воспользоваться открывшимися возможностями. А требования… это решить все наперед, чтобы потом в этом увязнуть.
Только хреновый аналитик пытается в требованиях решить все наперед. И таким можно и нужно давать по рукам, потому что требования не должны всегда описывать детали реализации, и должны также оставлять возможности.
+4
Оно то так, только аналитики так делают не от хорошей жизни. Чем детальнее требования — тем тяжелее потом заказчику сыграть в 'misunderstanding' на этапе приемки продукта.
Требования которые детально описывают желаемое поведение системы или ее части обычно очень тяжело проходят согласование с заказчиком, потому что тот — видя что читать требования двояко становится все сложнее — углубляется в детали предполагаемого поведения. Т.е. время в этом случае больше тратится на проработку требований и описание будущего решения а не на изменение того что уже имплементировано.
Требования которые детально описывают желаемое поведение системы или ее части обычно очень тяжело проходят согласование с заказчиком, потому что тот — видя что читать требования двояко становится все сложнее — углубляется в детали предполагаемого поведения. Т.е. время в этом случае больше тратится на проработку требований и описание будущего решения а не на изменение того что уже имплементировано.
0
Ну это понятно. Компромисс всегда есть, какие-то вещи нужно зафиксировать — или реализовано будет совсем не то, что хотели.
Но вот скажем, живой пример аналитика не просто плохого, а очень плохого, какого я наблюдал живем: пишет она задание на реализацию мониторинга. В потрохах продукта ничего при этом не понимает. И на выходе получаем примерно следующее:
— мониторьте состояние базы — далее следует SQL запрос, который приводит к фуллскану на таблице с миллионами записей.
— запрос выполнять раз в минуту (фуллскан на миллионах, угу).
— если мониторинг показал, что данные не поступают, нужно рестартовать приложение. Что сначала хорошо бы разобраться, почему не поступают — пофиг. Что в приложении много модулей, и рестартовать возможно нужно только модуль — пофиг. Что это уже не задание на реализацию мониторинга, а инструкция для поддержки — пофиг.
Мораль — указаны куча деталей, большая часть из которых нафиг не нужна, и только ограничивает разработчика. При этом именно требований к мониторингу за горами этого хлама найти почти невозможно.
Но вот скажем, живой пример аналитика не просто плохого, а очень плохого, какого я наблюдал живем: пишет она задание на реализацию мониторинга. В потрохах продукта ничего при этом не понимает. И на выходе получаем примерно следующее:
— мониторьте состояние базы — далее следует SQL запрос, который приводит к фуллскану на таблице с миллионами записей.
— запрос выполнять раз в минуту (фуллскан на миллионах, угу).
— если мониторинг показал, что данные не поступают, нужно рестартовать приложение. Что сначала хорошо бы разобраться, почему не поступают — пофиг. Что в приложении много модулей, и рестартовать возможно нужно только модуль — пофиг. Что это уже не задание на реализацию мониторинга, а инструкция для поддержки — пофиг.
Мораль — указаны куча деталей, большая часть из которых нафиг не нужна, и только ограничивает разработчика. При этом именно требований к мониторингу за горами этого хлама найти почти невозможно.
0
Конечно пользовательские истории не требования, это скорее описание тех возможностей которые заказчик хочет предоставить конечному пользователю через свой продукт. Это описание ценности продукта через его функциональные особенности.
И я считаю, что это в большей степени призма, через которую смотрит бизнес, чем разработчик. Реализация пользовательского сценария — условная галочка — ничего не говорит о том, как он был реализован. Не избавляет от багов, интеграционных сюрпризов и прочего.
Они не упраздняют работу системного аналитика, и системного инженера. Потому что именно эти ребята скажут, о чем нужно серьезно задуматься реализуя такой функционал. Не упраздняет работу интерфейс-дизайнеров, которые скажут как реализовать этот функционал так чтобы пользователю хотелось и было удобно им пользоваться. Не упраздняют работу программного архитектора, который сделает работу разработчиков с кодом быстрой, а результат предсказуемым.
Однако, пользовательские истории упрощают диалог о продукте и дают всем участникам проекта возможность легко понимать его назначение. Ведь не все приложения — музыкальный плеер, или социальная сеть, где многие имеют личный опыт пользования. Это могут быть какие-то «суровые» приложения для производственного планирования, и тут без таких «обьяснялочек» в виде сценариев не обойтись. Ткнул в историю, и сразу всем ясен контекст. Упрощает, ускоряет коммуникацию.
И я считаю, что это в большей степени призма, через которую смотрит бизнес, чем разработчик. Реализация пользовательского сценария — условная галочка — ничего не говорит о том, как он был реализован. Не избавляет от багов, интеграционных сюрпризов и прочего.
Они не упраздняют работу системного аналитика, и системного инженера. Потому что именно эти ребята скажут, о чем нужно серьезно задуматься реализуя такой функционал. Не упраздняет работу интерфейс-дизайнеров, которые скажут как реализовать этот функционал так чтобы пользователю хотелось и было удобно им пользоваться. Не упраздняют работу программного архитектора, который сделает работу разработчиков с кодом быстрой, а результат предсказуемым.
Однако, пользовательские истории упрощают диалог о продукте и дают всем участникам проекта возможность легко понимать его назначение. Ведь не все приложения — музыкальный плеер, или социальная сеть, где многие имеют личный опыт пользования. Это могут быть какие-то «суровые» приложения для производственного планирования, и тут без таких «обьяснялочек» в виде сценариев не обойтись. Ткнул в историю, и сразу всем ясен контекст. Упрощает, ускоряет коммуникацию.
+1
Требования — это всё, что отражает потребности заказчика. Пользовательские истории это отлично делают, а значит это требования.
Автора статьи, возможно, смутило то, что пользовательские истории как правило не достаточно конкретные, чтобы можно было начинать разработку.
Есть несколько видов требований: бизнес требования (business requirements), требования заинтересованных сторон (stakeholder requirements), требования к решению (solution requirements). Функциональные требования (functional requirement) — это подкатегория требований к решению.
В процессе бизнес анализа, нужно понимать потребности бизнеса, потребности конкретных пользователей, и т. п., чтобы убедиться, что тот функционал, то решение, которое мы разрабатываем, это то, что нужно заказчику. Пользовательские истории выполняют эту функцию. В большинстве это не то, что сразу можно брать в разработку, это скорее промежуточный этап.
В контракте же нужно фиксировать требования, с одной стороны, не очень детально, чтобы у разработчиков была возможность для маневров, а с другой стороны — достаточно детально, чтобы нельзя было позже раздуть объем работ. Это на грани искусства, но любой опытный бизнес-аналитик должен быть способен это сделать. Некоторые пользовательские истории удовлетворяют этим требования, и могут быть использованы в контракте.
Из IIBA BABoK:
Need — a problem or opportunity to be addressed.
Requirement — a usable representation of a need.
Business requirements — statements of goals, objectives, and outcomes that describe why a change has been initiated.
Stakeholder requirement — a description of the needs of a particular stakeholder or class of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business requirements and the various categories of solution requirements.
Solution requirements — describes the capabilities and qualities of a solution that meets the stakeholder requirements.
Functional requirements — (a subcategory of solution requirements) describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage.
User story — a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.
Автора статьи, возможно, смутило то, что пользовательские истории как правило не достаточно конкретные, чтобы можно было начинать разработку.
Есть несколько видов требований: бизнес требования (business requirements), требования заинтересованных сторон (stakeholder requirements), требования к решению (solution requirements). Функциональные требования (functional requirement) — это подкатегория требований к решению.
В процессе бизнес анализа, нужно понимать потребности бизнеса, потребности конкретных пользователей, и т. п., чтобы убедиться, что тот функционал, то решение, которое мы разрабатываем, это то, что нужно заказчику. Пользовательские истории выполняют эту функцию. В большинстве это не то, что сразу можно брать в разработку, это скорее промежуточный этап.
В контракте же нужно фиксировать требования, с одной стороны, не очень детально, чтобы у разработчиков была возможность для маневров, а с другой стороны — достаточно детально, чтобы нельзя было позже раздуть объем работ. Это на грани искусства, но любой опытный бизнес-аналитик должен быть способен это сделать. Некоторые пользовательские истории удовлетворяют этим требования, и могут быть использованы в контракте.
Из IIBA BABoK:
Need — a problem or opportunity to be addressed.
Requirement — a usable representation of a need.
Business requirements — statements of goals, objectives, and outcomes that describe why a change has been initiated.
Stakeholder requirement — a description of the needs of a particular stakeholder or class of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business requirements and the various categories of solution requirements.
Solution requirements — describes the capabilities and qualities of a solution that meets the stakeholder requirements.
Functional requirements — (a subcategory of solution requirements) describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage.
User story — a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.
0
статья в стиле «Сон это не сон а не сон это сон». Пользовательские истории это не требования а один из форматов описания требований. Из них разработчик понимает контекст использования продукта. Например — не только требование сделать зеленую кнопку, но и то как ей будут пользоваться, как она может измениться и т.д.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пользовательские истории – это не требования