Пользовательские истории и ГОСТ 34(Прочитано 29283 раз)
Здравствуйте!

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

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

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

Что скажете, что посоветуете?
« Последнее редактирование: 19 Ноября 2013, 19:30:56 от Сергей (es3000) »



Re: Пользовательские истории и ГОСТ 34 Ответ #1 : 19 Ноября 2013, 19:36:08
Что скажете, что посоветуете?

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Пользовательские истории и ГОСТ 34 Ответ #2 : 19 Ноября 2013, 19:38:05
Вот, совсем недавно делился своими соображениями по этому поводу:
https://www.webursitet.ru/article/polzovatelskie-istorii--trebovaniya-ili-net.html
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Пользовательские истории и ГОСТ 34 Ответ #3 : 19 Ноября 2013, 20:02:12
Здравствуйте!

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Re: Пользовательские истории и ГОСТ 34 Ответ #4 : 19 Ноября 2013, 20:53:10
Пользовательские истории не предназначены для такого использования. Им нет места в ТЗ по ГОСТу. Зафискировав user stories в статическом документе, вы получите просто очень плохие требования.
В принципе согласен.
Пользовательские истории - это не требования. Это "заготовка", материал для разработки требований.
Но ведь я так их и обозначу в документе, я их не буду называть "требованиями".
В ТЗ будет два раздела: первый - пользовательские истории, второй - полноценные требования.
Хуже ведь не будет, если в документе появится еще один раздел, предшествующий требованиям.

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



Re: Пользовательские истории и ГОСТ 34 Ответ #5 : 19 Ноября 2013, 21:22:42
Хуже ведь не будет, если в документе появится еще один раздел, предшествующий требованиям.

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

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

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

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Пользовательские истории и ГОСТ 34 Ответ #6 : 20 Ноября 2013, 01:51:59
Разделю свой ответ на пункты в контексте своих вопросов...
Но всплыл еще и самый главный вопрос, который я обозначу пунктом 0.

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

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

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

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

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

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

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

того, чтобы … »
Давайте ещё в папку с ТЗ вместо распечатанного текста будем просто вклеивать липкие жёлтые листочки Post It?
Нет, листочки не надо.
Я, как руководство ... специалиста, хочу, чтобы он разместил в ТЗ пользовательские истории, для того, чтобы ... (ну например) менеджер проекта и программисты ознакомились с ПИ

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

---

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

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

Не требований, а пожеланий. Если более точно — это трассировка представлений о пользовательских задачах на пользовательские цели.
С тем что ПИ - это не требования - соглашусь.
А какое этому обоснование? Приведенная выше статья от Григория?

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

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

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

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

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

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

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

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

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

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

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

Этот вопрос пока остается открытым
« Последнее редактирование: 20 Ноября 2013, 02:14:27 от Сергей (es3000) »



Re: Пользовательские истории и ГОСТ 34 Ответ #7 : 20 Ноября 2013, 02:06:20
Только если вы готовы менять ТЗ на каждом спринте, добавляя, уточняя и выбрасывая пользовательские истории. Но это будет уже не ТЗ.
Пользовательские истории - это инструмент, который работает в ситуации быстро меняющихся и уточняемых по ходу разработки продукта требований.
А какой документ для требований создается " ... в ситуации быстро меняющихся и уточняемых по ходу разработки продукта требований ..."?
Если "...это будет уже не ТЗ"?

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

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



Re: Пользовательские истории и ГОСТ 34 Ответ #8 : 20 Ноября 2013, 03:28:56
ТЗ — это юридический документ.

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

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



Re: Пользовательские истории и ГОСТ 34 Ответ #9 : 20 Ноября 2013, 03:36:08
Задача заключается в доработке ТЗ: добавление в него пользовательских историй (ПИ).

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



Re: Пользовательские истории и ГОСТ 34 Ответ #10 : 20 Ноября 2013, 14:20:43
По 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.



Re: Пользовательские истории и ГОСТ 34 Ответ #11 : 20 Ноября 2013, 15:13:08
ТЗ — это юридический документ.
User Stories — это рабочий информационный артефакт.
Если вы хотите, чтобы с ними ознакомились, совсем не обязательно засовывать их в текстовый документ. Показать и, что важно, объяснить, можно и на реестре US — backlog'е.
Мы уже в который раз говорим о том, что "...совсем не обязательно засовывать их в текстовый документ...", а именно в ТЗ.
С этим вообще никто не спорит.



Re: Пользовательские истории и ГОСТ 34 Ответ #12 : 20 Ноября 2013, 15:21:52
Я напомню один из важнейших принципов формулирования постановки задач.
Формулировка постановки задачи должна содержать критерии её приёмки.
Без критериев приёмки это не задача, а название содержания вашей деятельности.
Критерий простой - согласование с руководством проекта и заказчиком.
Если с точки зрения указанных лиц требования в ТЗ верны, а также пользовательские истории, которые будут добавлены в ТЗ, будут соответствовать этим требованиям, то моя задача будет считаться выполненной.



Re: Пользовательские истории и ГОСТ 34 Ответ #13 : 20 Ноября 2013, 15:25:04
Критерий простой - согласование с руководством проекта и заказчиком.
Если с точки зрения указанных лиц требования в ТЗ верны, а также пользовательские истории, которые будут добавлены в ТЗ, будут соответствовать этим требованиям, то моя задача будет считаться выполненной.
Что, реально заказчик и ПМ будут садиться и сверять списки из 120 user stories и 50 ФТ между собой? Им больше заняться нечем?



Re: Пользовательские истории и ГОСТ 34 Ответ #14 : 20 Ноября 2013, 15:44:36
Что, реально заказчик и ПМ будут садиться и сверять списки из 120 user stories и 50 ФТ между собой? Им больше заняться нечем?

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

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

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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19