Комментарии 12
Я понимаю, что это перевод, но…
Во всей статье прямо-таки не разу не разъясняется, что вообще значит словосочетание «Пользовательские истории»! Нет сноски, что это не пользовательские истории вообще (ну типа, приходит пользователь и рассказывает историю… Не, ну а чего — сейчас все уже настолько в agile, что это очевидно? А я вот гуглил...), а термин agile-философии… Ссылочку бы на определение. Да и сама статья откровенно ни о чем.
Во всей статье прямо-таки не разу не разъясняется, что вообще значит словосочетание «Пользовательские истории»! Нет сноски, что это не пользовательские истории вообще (ну типа, приходит пользователь и рассказывает историю… Не, ну а чего — сейчас все уже настолько в agile, что это очевидно? А я вот гуглил...), а термин agile-философии… Ссылочку бы на определение. Да и сама статья откровенно ни о чем.
Как видите Ваш риквест дефиниции пользовательских историй показался анонимусу токсичным.
PS. формально мой каммент написан на русском.
Хорошо, что вы мне объяснили, плохо, что я ничего не понял… ;)
"Ваша просьба дать определения понятия "пользовательские истории" не понравилась неназванным пользователям хабра" (это судя по минусам Вашему камменту).
Та же фигня с "пользовательскими историями" — неумение автора по-людски переводить термины заменяется прямым гуглепереводом и контекстом "ну все же знают".
А, теперь понял… ) Я примерно так и предполагал, но…
Я просто с телефона читал — там детально посмотреть сложно, а общая оценка была нейтральной.
Ну, анонимусу виднее! ) Я свое мнение высказал: я считаю, что словосочетание «пользовательские истории» состоит из обычных общеупотребимых слов и если речь идет не об общем их применении, а о специальной терминологии из определённой области, то нужно давать сноску! А там может и правда я от жизни отстал и не понимаю устоявшихся выражений…
Я просто с телефона читал — там детально посмотреть сложно, а общая оценка была нейтральной.
Ну, анонимусу виднее! ) Я свое мнение высказал: я считаю, что словосочетание «пользовательские истории» состоит из обычных общеупотребимых слов и если речь идет не об общем их применении, а о специальной терминологии из определённой области, то нужно давать сноску! А там может и правда я от жизни отстал и не понимаю устоявшихся выражений…
Коллеги, "пользовательские истории" — это вполне устоявшийся русскоязычный термин. Если вдруг он не знаком… ну вы сами знаете, как исправить эту ситуацию.
Пользовательские истории — это прежде всего шанс увидеть различные варианты реализации, чтобы потом можно было воспользоваться открывшимися возможностями. А требования… это решить все наперед, чтобы потом в этом увязнуть.
Только хреновый аналитик пытается в требованиях решить все наперед. И таким можно и нужно давать по рукам, потому что требования не должны всегда описывать детали реализации, и должны также оставлять возможности.
Оно то так, только аналитики так делают не от хорошей жизни. Чем детальнее требования — тем тяжелее потом заказчику сыграть в 'misunderstanding' на этапе приемки продукта.
Требования которые детально описывают желаемое поведение системы или ее части обычно очень тяжело проходят согласование с заказчиком, потому что тот — видя что читать требования двояко становится все сложнее — углубляется в детали предполагаемого поведения. Т.е. время в этом случае больше тратится на проработку требований и описание будущего решения а не на изменение того что уже имплементировано.
Требования которые детально описывают желаемое поведение системы или ее части обычно очень тяжело проходят согласование с заказчиком, потому что тот — видя что читать требования двояко становится все сложнее — углубляется в детали предполагаемого поведения. Т.е. время в этом случае больше тратится на проработку требований и описание будущего решения а не на изменение того что уже имплементировано.
Ну это понятно. Компромисс всегда есть, какие-то вещи нужно зафиксировать — или реализовано будет совсем не то, что хотели.
Но вот скажем, живой пример аналитика не просто плохого, а очень плохого, какого я наблюдал живем: пишет она задание на реализацию мониторинга. В потрохах продукта ничего при этом не понимает. И на выходе получаем примерно следующее:
— мониторьте состояние базы — далее следует SQL запрос, который приводит к фуллскану на таблице с миллионами записей.
— запрос выполнять раз в минуту (фуллскан на миллионах, угу).
— если мониторинг показал, что данные не поступают, нужно рестартовать приложение. Что сначала хорошо бы разобраться, почему не поступают — пофиг. Что в приложении много модулей, и рестартовать возможно нужно только модуль — пофиг. Что это уже не задание на реализацию мониторинга, а инструкция для поддержки — пофиг.
Мораль — указаны куча деталей, большая часть из которых нафиг не нужна, и только ограничивает разработчика. При этом именно требований к мониторингу за горами этого хлама найти почти невозможно.
Но вот скажем, живой пример аналитика не просто плохого, а очень плохого, какого я наблюдал живем: пишет она задание на реализацию мониторинга. В потрохах продукта ничего при этом не понимает. И на выходе получаем примерно следующее:
— мониторьте состояние базы — далее следует SQL запрос, который приводит к фуллскану на таблице с миллионами записей.
— запрос выполнять раз в минуту (фуллскан на миллионах, угу).
— если мониторинг показал, что данные не поступают, нужно рестартовать приложение. Что сначала хорошо бы разобраться, почему не поступают — пофиг. Что в приложении много модулей, и рестартовать возможно нужно только модуль — пофиг. Что это уже не задание на реализацию мониторинга, а инструкция для поддержки — пофиг.
Мораль — указаны куча деталей, большая часть из которых нафиг не нужна, и только ограничивает разработчика. При этом именно требований к мониторингу за горами этого хлама найти почти невозможно.
Конечно пользовательские истории не требования, это скорее описание тех возможностей которые заказчик хочет предоставить конечному пользователю через свой продукт. Это описание ценности продукта через его функциональные особенности.
И я считаю, что это в большей степени призма, через которую смотрит бизнес, чем разработчик. Реализация пользовательского сценария — условная галочка — ничего не говорит о том, как он был реализован. Не избавляет от багов, интеграционных сюрпризов и прочего.
Они не упраздняют работу системного аналитика, и системного инженера. Потому что именно эти ребята скажут, о чем нужно серьезно задуматься реализуя такой функционал. Не упраздняет работу интерфейс-дизайнеров, которые скажут как реализовать этот функционал так чтобы пользователю хотелось и было удобно им пользоваться. Не упраздняют работу программного архитектора, который сделает работу разработчиков с кодом быстрой, а результат предсказуемым.
Однако, пользовательские истории упрощают диалог о продукте и дают всем участникам проекта возможность легко понимать его назначение. Ведь не все приложения — музыкальный плеер, или социальная сеть, где многие имеют личный опыт пользования. Это могут быть какие-то «суровые» приложения для производственного планирования, и тут без таких «обьяснялочек» в виде сценариев не обойтись. Ткнул в историю, и сразу всем ясен контекст. Упрощает, ускоряет коммуникацию.
И я считаю, что это в большей степени призма, через которую смотрит бизнес, чем разработчик. Реализация пользовательского сценария — условная галочка — ничего не говорит о том, как он был реализован. Не избавляет от багов, интеграционных сюрпризов и прочего.
Они не упраздняют работу системного аналитика, и системного инженера. Потому что именно эти ребята скажут, о чем нужно серьезно задуматься реализуя такой функционал. Не упраздняет работу интерфейс-дизайнеров, которые скажут как реализовать этот функционал так чтобы пользователю хотелось и было удобно им пользоваться. Не упраздняют работу программного архитектора, который сделает работу разработчиков с кодом быстрой, а результат предсказуемым.
Однако, пользовательские истории упрощают диалог о продукте и дают всем участникам проекта возможность легко понимать его назначение. Ведь не все приложения — музыкальный плеер, или социальная сеть, где многие имеют личный опыт пользования. Это могут быть какие-то «суровые» приложения для производственного планирования, и тут без таких «обьяснялочек» в виде сценариев не обойтись. Ткнул в историю, и сразу всем ясен контекст. Упрощает, ускоряет коммуникацию.
Требования — это всё, что отражает потребности заказчика. Пользовательские истории это отлично делают, а значит это требования.
Автора статьи, возможно, смутило то, что пользовательские истории как правило не достаточно конкретные, чтобы можно было начинать разработку.
Есть несколько видов требований: бизнес требования (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.
статья в стиле «Сон это не сон а не сон это сон». Пользовательские истории это не требования а один из форматов описания требований. Из них разработчик понимает контекст использования продукта. Например — не только требование сделать зеленую кнопку, но и то как ей будут пользоваться, как она может измениться и т.д.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пользовательские истории – это не требования