Здравствуйте!
Я участвую в написании ТЗ на АС.
ТЗ пишем, ориентируясь на ГОСТ 34.
Недавно руководство проекта решило доработать ТЗ и добавить в него ... "пользовательские истории", и поручили мне сделать это.
До этого я, конечно, про пользовательские истории слышал, однако сам никогда их не писал и в ТЗ не использовал.
Приходится самому кое-что додумывать.
У меня созрели некоторые тезисы по решению поставленной мне задачи,
А в чём заключается задача? Вы выяснили, зачем засовывать user stories в ТЗ? Кому это и зачем нужно?
но есть некоторая доля неуверенности в правильности.
А вы вообще уверены, что руководство имело в виду именно user stories? А то терминология сейчас такая, что под этим могут иметься в виду и пользовательские сценарии и use cases.
В связи с этим прошу обсудить сложившееся у меня решение
Это решение чего? Как избежать повторного разговора с руководством, чтобы не выглядеть неграмотным специалистом, но всё-таки сделать то, «не знаю что», которого ОНО просит?
, и поправить меня в чем я не прав.
Вот что я надумал.
1) Самый важный вопрос. Правильно ли я понимаю суть пользовательских историй?
Пользовательские истории - это способ представления пользовательских требований (один из способов, есть и другие способы их представления, например сценарии использования).
Не требований, а пожеланий. Если более точно — это трассировка представлений о пользовательских задачах на пользовательские цели.
Отличаются они тем, что написаны просто и кратко наиболее понятным для пользователей языком, без лишней детализации.
Отличаются они тем, что дают наглядное представление о том, кому, что и зачем надо, но без понимания, как именно это будет работать. И отсутствие детализации — и плюс и минус. Для детализации к истории могут прилагаться многочисленные приложения, которые выясняются по мере необходимости.
2) Вопрос о месте пользовательских историй в структуре ТЗ:
2.1) Вообще пользовательские требования формируются еще до формирования ТЗ. И вообще говоря в ТЗ им не место.
2.2) Ну раз уж их нужно добавить в ТЗ, то я думаю, что лучше это сделать в разделе "Характеристика объекта автоматизации". Для этого планирую сделать в этом разделе подраздел - так и назову его - "Пользовательские истории".
Характеристика объекта автоматизации — это описание того, что как сейчас работает, модель AS-IS. А пользовательские истории совершенно точно относятся к целевой модели, как должно быть, TO BE.
3) Вообще у нас не одно ТЗ, а целый комплект. Основное ТЗ - это ТЗ на систему в целом, и есть еще несколько ТЗ по подсистемам. Одна из подсистем - это программная часть системы. И руководство предлагает включить пользовательские истории не в ТЗ на систему, а в ТЗ на программный продукт,…
Включить чтобы что?
который реализует основную функциональность всей системы. Я с этим не согласен,
но как переубедить руководство?
Они считают: так как функциональность реализуется программно, то и написать пользовательские истории надо в ТЗ на программную подсистему.
Почему вы не согласны?
Они считают: так как функциональность реализуется программно, то и написать пользовательские истории надо в ТЗ на программную подсистему.
Что скажете, что посоветуете?
Выясните, в чём суть намерения включать в ТЗ по ГОСТу конструкции, которые для этого не предназначены.
Т.е. напишите хотя одну главную пользовательскую историю — «Я, как руководство (обло, стозевно и лаяй) специалиста, хочу, чтобы он разместил в ТЗ пользовательские истории, для того, чтобы … »
Давайте ещё в папку с ТЗ вместо распечатанного текста будем просто вклеивать липкие жёлтые листочки Post It?
Просмотр сообщений
