Здравствуйте!

Я участвую в написании ТЗ на АС.
ТЗ пишем, ориентируясь на ГОСТ 34.
Недавно руководство проекта решило доработать ТЗ и добавить в него ... "пользовательские истории", и поручили мне сделать это.
До этого я, конечно, про пользовательские истории слышал, однако сам никогда их не писал и в ТЗ не использовал.
Приходится самому кое-что додумывать.

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

Вот что я надумал.
1) Самый важный вопрос. Правильно ли я понимаю суть пользовательских историй?
Пользовательские истории - это способ представления пользовательских требований (один из способов, есть и другие способы их представления, например сценарии использования).
Отличаются они тем, что написаны просто и кратко наиболее понятным для пользователей языком, без лишней детализации.
2) Вопрос о месте пользовательских историй в структуре ТЗ:
    2.1) Вообще пользовательские требования формируются еще до формирования ТЗ. И вообще говоря в ТЗ им не место.
    2.2) Ну раз уж их нужно добавить в ТЗ, то я думаю, что лучше это сделать в разделе "Характеристика объекта автоматизации". Для этого планирую сделать в этом разделе подраздел - так и назову его - "Пользовательские истории".
3) Вообще у нас не одно ТЗ, а целый комплект. Основное ТЗ - это ТЗ на систему в целом, и есть еще несколько ТЗ по подсистемам. Одна из подсистем - это программная часть системы. И руководство предлагает включить пользовательские истории не в ТЗ на систему, а в ТЗ на программный продукт, который реализует основную функциональность всей системы. Я с этим не согласен, но как переубедить руководство? Они считают: так как функциональность реализуется программно, то и написать пользовательские истории надо в ТЗ на программную подсистему.

Что скажете, что посоветуете?

Что скажете, что посоветуете?

Пользовательские истории не предназначены для такого использования. Им нет места в ТЗ по ГОСТу. Зафискировав user stories в статическом документе, вы получите просто очень плохие требования.

Вот, совсем недавно делился своими соображениями по этому поводу:
https://www.webursitet.ru/article/polzovatelskie-istorii--trebovaniya-ili-net.html

Здравствуйте!

Я участвую в написании ТЗ на АС.
ТЗ пишем, ориентируясь на ГОСТ 34.
Недавно руководство проекта решило доработать ТЗ и добавить в него ... "пользовательские истории", и поручили мне сделать это.

До этого я, конечно, про пользовательские истории слышал, однако сам никогда их не писал и в ТЗ не использовал.
Приходится самому кое-что додумывать.

У меня созрели некоторые тезисы по решению поставленной мне задачи,

А в чём заключается задача? Вы выяснили, зачем засовывать user stories в ТЗ? Кому это и зачем нужно?

но есть некоторая доля неуверенности в правильности.

А вы вообще уверены, что руководство имело в виду именно user stories? А то терминология сейчас такая, что под этим могут иметься в виду и пользовательские сценарии и use cases.

В связи с этим прошу обсудить сложившееся у меня решение

Это решение чего? Как избежать повторного разговора с руководством, чтобы не выглядеть неграмотным специалистом, но всё-таки сделать то, «не знаю что», которого ОНО просит?

, и поправить меня в чем я не прав.

Вот что я надумал.
1) Самый важный вопрос. Правильно ли я понимаю суть пользовательских историй?
Пользовательские истории - это способ представления пользовательских требований (один из способов, есть и другие способы их представления, например сценарии использования).

Не требований, а пожеланий. Если более точно — это трассировка представлений о пользовательских задачах на пользовательские цели.

Отличаются они тем, что написаны просто и кратко наиболее понятным для пользователей языком, без лишней детализации.

Отличаются они тем, что дают наглядное представление о том, кому, что и зачем надо, но без понимания, как именно это будет работать. И отсутствие детализации — и плюс и минус. Для детализации к истории могут прилагаться многочисленные приложения, которые выясняются по мере необходимости.

2) Вопрос о месте пользовательских историй в структуре ТЗ:
    2.1) Вообще пользовательские требования формируются еще до формирования ТЗ. И вообще говоря в ТЗ им не место.
    2.2) Ну раз уж их нужно добавить в ТЗ, то я думаю, что лучше это сделать в разделе "Характеристика объекта автоматизации". Для этого планирую сделать в этом разделе подраздел - так и назову его - "Пользовательские истории".

Характеристика объекта автоматизации — это описание того, что как сейчас работает, модель AS-IS. А пользовательские истории совершенно точно относятся к целевой модели, как должно быть, TO BE.

3) Вообще у нас не одно ТЗ, а целый комплект. Основное ТЗ - это ТЗ на систему в целом, и есть еще несколько ТЗ по подсистемам. Одна из подсистем - это программная часть системы. И руководство предлагает включить пользовательские истории не в ТЗ на систему, а в ТЗ на программный продукт,…

Включить чтобы что?

который реализует основную функциональность всей системы. Я с этим не согласен,
но как переубедить руководство?
Они считают: так как функциональность реализуется программно, то и написать пользовательские истории надо в ТЗ на программную подсистему.

Почему вы не согласны?

Они считают: так как функциональность реализуется программно, то и написать пользовательские истории надо в ТЗ на программную подсистему.
Что скажете, что посоветуете?

Выясните, в чём суть намерения включать в ТЗ по ГОСТу конструкции, которые для этого не предназначены.

Т.е. напишите хотя одну главную пользовательскую историю — «Я, как руководство (обло, стозевно и лаяй) специалиста, хочу, чтобы он разместил в ТЗ пользовательские истории, для того, чтобы … »

Давайте ещё в папку с ТЗ вместо распечатанного текста будем просто вклеивать липкие жёлтые листочки Post It?

Пользовательские истории не предназначены для такого использования. Им нет места в ТЗ по ГОСТу. Зафискировав user stories в статическом документе, вы получите просто очень плохие требования.

В принципе согласен.
Пользовательские истории - это не требования. Это "заготовка", материал для разработки требований.
Но ведь я так их и обозначу в документе, я их не буду называть "требованиями".
В ТЗ будет два раздела: первый - пользовательские истории, второй - полноценные требования.
Хуже ведь не будет, если в документе появится еще один раздел, предшествующий требованиям.

Вот, совсем недавно делился своими соображениями по этому поводу:
https://www.webursitet.ru/article/polzovatelskie-istorii--trebovaniya-ili-net.html

Статью читал позавчера, когда "вникал" в пользовательские истории

Хуже ведь не будет, если в документе появится еще один раздел, предшествующий требованиям.

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

Пользовательские истории - это инструмент, который работает в ситуации быстро меняющихся и уточняемых по ходу разработки продукта требований.

Если ваш проект позволяет выявить все истории заранее, и вы уверены, что их состав не будет меняться в процессе разработки (а иначе нет смысла фиксировать их в документе), то ваши истории превращаются просто в плохо проработанные пользовательские требования - набор "хотелок", которые нужно анализировать, выделять роли пользователей, какие-то истории отбрасывать сразу, а какие-то превращать в юзкейсы или в функциональные требования вида "система должна".

Денис начал с самого главного вопроса: "Кому это и зачем нужно?" У руководства проекта ведь были какие-то соображения, чтобы принять такое решение.

Разделю свой ответ на пункты в контексте своих вопросов...
Но всплыл еще и самый главный вопрос, который я обозначу пунктом 0.

0) Что хочет от меня руководство и зачем оно заставляет меня сделать такое "неправедное" действие

А в чём заключается задача? Вы выяснили, зачем засовывать user stories в ТЗ? Кому это и зачем

нужно?

Задача заключается в доработке ТЗ: добавление в него пользовательских историй (ПИ).
Нужно менеджеру проекта, видимо он знаком с гибкими методологиями.
Считается, что у нас опытный менеджер.
Нужно для того, чтобы участники проекта могли ознакомиться с ПИ.
Программисты кстати тоже выразили такое желание.

А вы вообще уверены, что руководство имело в виду именно user stories? А то терминология сейчас такая, что под этим могут иметься в виду и пользовательские сценарии и use

cases.

Да, именно так мне их и назвали - user stories.

Это решение чего? Как избежать повторного разговора с руководством, чтобы не выглядеть неграмотным специалистом, но всё-таки сделать то, «не знаю что», которого ОНО просит?

Это решение проблемы: куда в ТЗ поместить ПИ исходя из их сути.
Разговора с руководством действительно не хочется.
Да и почему "не знаю что"?
Я знаю "что" надо сделать, руководство это выразило вполне определенно.
Правильно и целесообразно ли это - это другой вопрос.

Выясните, в чём суть намерения включать в ТЗ по ГОСТу конструкции, которые для этого не предназначены.
Т.е. напишите хотя одну главную пользовательскую историю — «Я, как руководство (обло, стозевно и лаяй) специалиста, хочу, чтобы он разместил в ТЗ пользовательские истории, для

того, чтобы … »
Давайте ещё в папку с ТЗ вместо распечатанного текста будем просто вклеивать липкие жёлтые листочки Post It?

Нет, листочки не надо.
Я, как руководство ... специалиста, хочу, чтобы он разместил в ТЗ пользовательские истории, для того, чтобы ... (ну например) менеджер проекта и программисты ознакомились с ПИ

и таким образом получили более полное представление о будущей системе.

---

Еще добавлю.
На данный момент ПИ у нас не существует, как-то так мы перепрыгнули этот шаг.
Руководство хочет восполнить этот пробел, но вот таким необычным способом.
Можно, конечно, попытаться доказать, что они не правы.
Как вариант я предложу руководству оформить ПИ отдельным документом.
Но все-таки, хотелось бы найти наиболее подходящее место для ПИ в структуре ТЗ, исходя из всех условий данной ситуации.

1) Суть пользовательских историй.

Не требований, а пожеланий. Если более точно — это трассировка представлений о пользовательских задачах на пользовательские цели.

С тем что ПИ - это не требования - соглашусь.
А какое этому обоснование? Приведенная выше статья от Григория?

Насчет трассировки - сомневаюсь.
Ведь чтобы "трассировать" уже должны существовать задачи и цели. А на момент формирования ПИ их еще не сформулировано.
Скорее пользовательские цели и задачи создаются в результате анализа ПИ.
Ведь может же быть такое что для достижения одной цели необходимо решить несколько задач. Как в этом случае оформляются ПИ?

Отличаются они тем, что дают наглядное представление о том, кому, что и зачем надо, но без понимания, как именно это будет работать. И отсутствие детализации — и плюс и минус.

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

Угу

2.1) ПИ в ТЗ - не место

Выясните, в чём суть намерения включать в ТЗ по ГОСТу конструкции, которые для этого не предназначены.

Денис, исходя из этого ответа я делаю вывод, что по этому пункту у нас противоречий нет - ПИ не должны присутствовать в ТЗ.

2.2) В какое место ТЗ следует вставить ПИ.

Характеристика объекта автоматизации — это описание того, что как сейчас работает, модель AS-IS. А пользовательские истории совершенно точно относятся к целевой модели, как

должно быть, TO BE.

Здесь я согласен.
От размещения ПИ в разделе "Характеристика объекта автоматизации" отказываюсь.

Тогда предлагаю сделать новый раздел в ТЗ после раздела "3. Характеристика объекта автоматизации" и перед разделом "4. Требования к системе".
Так наверное будет логичнее.
Как раз получится что ПИ - это промежуточное звено между объектом автоматизации и требованиями к будущей системе.

3) В какое ТЗ следует включать ПИ: в ТЗ на систему в целом или в ТЗ на программную часть системы

Почему вы не согласны?

Потому что, как мне кажется,  ПИ относятся к системе в целом.
А включение ПИ в ТЗ для какой-то конкретной подсистемы уже накладывает какие-то ограничения на их реализацию.

Этот вопрос пока остается открытым

Только если вы готовы менять ТЗ на каждом спринте, добавляя, уточняя и выбрасывая пользовательские истории. Но это будет уже не ТЗ.
Пользовательские истории - это инструмент, который работает в ситуации быстро меняющихся и уточняемых по ходу разработки продукта требований.

А какой документ для требований создается " ... в ситуации быстро меняющихся и уточняемых по ходу разработки продукта требований ..."?
Если "...это будет уже не ТЗ"?

Если ваш проект позволяет выявить все истории заранее, и вы уверены, что их состав не будет меняться в процессе разработки (а иначе нет смысла фиксировать их в документе), то ваши истории превращаются просто в плохо проработанные пользовательские требования - набор "хотелок", которые нужно анализировать, выделять роли пользователей, какие-то истории отбрасывать сразу, а какие-то превращать в юзкейсы или в функциональные требования вида "система должна".

Точно подмечено.
Состав историй существенно не изменится.
Пусть так и будет, как ты говоришь: пусть наши ПИ превратятся в в плохо проработанные пользовательские требования.
Пусть это будет очередная версия нашего "ТЗ", содержащая сверх обычных разделов еще и "плохие" пользовательские требования.
После того как с ним ознакомится весь наш коллектив, ПИ будут доработаны и плавно превратятся в "хорошо" проработанные пользовательские требования.
И хотя понятно, что пользовательские требования не должны содержаться в ТЗ, серьезно от этого ведь никто не пострадает?

Денис начал с самого главного вопроса: "Кому это и зачем нужно?" У руководства проекта ведь были какие-то соображения, чтобы принять такое решение.

На этот вопрос попытался выше ответить.
Может быть не очень убедительно, но как есть.
А действовать надо.

ТЗ — это юридический документ.

User Stories — это рабочий информационный артефакт.

Если вы хотите, чтобы с ними ознакомились, совсем не обязательно засовывать их в текстовый документ. Показать и, что важно, объяснить, можно и на реестре US — backlog'е.

Задача заключается в доработке ТЗ: добавление в него пользовательских историй (ПИ).

Я напомню один из важнейших принципов формулирования постановки задач.
Формулировка постановки задачи должна содержать критерии её приёмки.
Без критериев приёмки это не задача, а название содержания вашей деятельности.

По 34 ГОСТу перед ТЗ есть ещё 2 этапа:
1. Формирование требований к АС
2. Разработка концепции АС
http://standards.narod.ru/gosts/gost34/34-601-90.htm

имхо пользовательские истории более уместны в отчете по первому этапу (формирование требований), чем в ТЗ. Как вариант решения, если просто хочется "чтобы было по ГОСТу", создайте этот отчёт. Там много пересечений с ТЗ, требования к содержанию отчета есть здесь: http://standards.narod.ru/gosts/gost34/50-34698-90.htm, приложение 1.

ТЗ — это юридический документ.
User Stories — это рабочий информационный артефакт.
Если вы хотите, чтобы с ними ознакомились, совсем не обязательно засовывать их в текстовый документ. Показать и, что важно, объяснить, можно и на реестре US — backlog'е.

Мы уже в который раз говорим о том, что "...совсем не обязательно засовывать их в текстовый документ...", а именно в ТЗ.
С этим вообще никто не спорит.

Я напомню один из важнейших принципов формулирования постановки задач.
Формулировка постановки задачи должна содержать критерии её приёмки.
Без критериев приёмки это не задача, а название содержания вашей деятельности.

Критерий простой - согласование с руководством проекта и заказчиком.
Если с точки зрения указанных лиц требования в ТЗ верны, а также пользовательские истории, которые будут добавлены в ТЗ, будут соответствовать этим требованиям, то моя задача будет считаться выполненной.

Критерий простой - согласование с руководством проекта и заказчиком.
Если с точки зрения указанных лиц требования в ТЗ верны, а также пользовательские истории, которые будут добавлены в ТЗ, будут соответствовать этим требованиям, то моя задача будет считаться выполненной.

Что, реально заказчик и ПМ будут садиться и сверять списки из 120 user stories и 50 ФТ между собой? Им больше заняться нечем?

Что, реально заказчик и ПМ будут садиться и сверять списки из 120 user stories и 50 ФТ между собой? Им больше заняться нечем?

А разве user stories и ФТ не должны быть согласованы между собой когда они находятся в разных документах?
Кто-то же их сверяет.
И какая тогда принципиальная разница с тем, если они находятся в одном документе?

А разве другие части ТЗ не должны быть согласованы между собой?
Да и не только ТЗ...
В проекте много документации, и все документы должны быть согласованы друг с другом.
Кто-то же сидит и читает все это и при обнаружении разногласий - исправляют.
Им - этим "читателям" проектной документации - получается тоже больше заняться нечем?

Почему же нельзя сделать проверку того, что ФТ учитывают все что было описано в ПИ?