Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Сергей() от 19 Ноября 2013, 19:23:23
-
Здравствуйте!
Я участвую в написании ТЗ на АС.
ТЗ пишем, ориентируясь на ГОСТ 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 и ФТ не должны быть согласованы между собой когда они находятся в разных документах?
Кто-то же их сверяет.
И какая тогда принципиальная разница с тем, если они находятся в одном документе?
А разве другие части ТЗ не должны быть согласованы между собой?
Да и не только ТЗ...
В проекте много документации, и все документы должны быть согласованы друг с другом.
Кто-то же сидит и читает все это и при обнаружении разногласий - исправляют.
Им - этим "читателям" проектной документации - получается тоже больше заняться нечем?
Почему же нельзя сделать проверку того, что ФТ учитывают все что было описано в ПИ?
-
По 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.
Да, мы в курсе про этап формирования требований.
Но дело в том, что не просто " хочется чтобы было по ГОСТу", а чтобы было как я написал в исходном вопросе: чтобы ПИ были добавлены в ТЗ.
Мы все время уходим от моего главного вопроса, пытаемся его обойти.
Я попросил высказать свои мнения о том, в какое место ТЗ лучше всего вставить ПИ с учетом логики изложения ТЗ и особенностей ПИ.
Я предложил добавить новый раздел между разделом "3. Характеристика объекта автоматизации" и разделом "4. Требования к системе".
Есть лучший вариант?
Еще остался вопрос: могут ли пользовательские истории иметь отношение не к системе в целом, а к какой-то ее части?
Ну и еще появился вопрос чисто по формулировке ПИ - но это лучше в отдельной теме обсудить
-
А какой документ для требований создается " ... в ситуации быстро меняющихся и уточняемых по ходу разработки продукта требований ..."?
Если "...это будет уже не ТЗ"?
В том-то и дело, что "документ" в привычном виде не создаётся. Для таких условий Agile и придумали.
User stories обычно пишут на отдельных листочках. Можно загнать их в какой-то инструмент для представления в электронном виде (сейчас таких всё больше благодаря росту популярности распределённой разработки). Например, в devprom (http://devprom.ru/). Оттуда их даже можно, наверное, экспортировать в .doc файл. Но при правильном использовании user stories этот "документ" будет изменяться постоянно: еженедельно или ежедневно. Его создание оказывается бессмысленным: работать с историями в онлайн-инструменте намного удобнее (можно искать, группировать, обсуждать, просматривать историю изменений и т. п.)
ГОСТ же изначально ориентирован на бумажный документооборот. Во-первых, потому что во времена, когда он писался, других инструментов обмена информацией ещё не было. Во-вторых, потому что ГОСТ стандартизирует отношения не людей, а организаций.
Мы поэтому и не можем дать ответа на "главный вопрос": как втиснуть user stories в ТЗ по ГОСТу. Там для них просто нет места.
Но если руководство требует, то вставляйте в любое. А лучше оформите в виде приложения.
-
А разве user stories и ФТ не должны быть согласованы между собой когда они находятся в разных документах?
Кто-то же их сверяет.
Мне таких случаев не представлялось, но полагаю, что за их консистентность должен отвечать автор.
И какая тогда принципиальная разница с тем, если они находятся в одном документе?
А разве другие части ТЗ не должны быть согласованы между собой?
Да и не только ТЗ...
В проекте много документации, и все документы должны быть согласованы друг с другом.
Кто-то же сидит и читает все это и при обнаружении разногласий - исправляют.
Им - этим "читателям" проектной документации - получается тоже больше заняться нечем?
Вы написали так критерии приёмки, что их них получается, что консистентность контролирует не автор.
Если контролировать её будете вы, то тогда получится, что просто им придётся делать двойную работу по вычитке.
Почему же нельзя сделать проверку того, что ФТ учитывают все что было описано в ПИ?
Конечно нужно, если вы мешаете мягкий подход с жёстким.
-
В целом, насколько я понимаю, проблема не стоит выеденного яйца.
Какая разница, куда вы вставите и как назовёте?
Коллеги правы, сущностно US ближе к описанию функций из документа требований заказчика, на уровне ТЗ можно создавать любые приложения.
-
ОК, я все понял, спасибо
-
Прошу тогда еще обсудить следующий вопрос, на который мы не обратили внимания.
Пользовательские истории имеют отношение к системе в целом, или к программному обеспечению системы?
Вроде получается так.
ПИ могут относиться как к системе в целом так и к ПО.
На стадии формирования требований к АС, т.е. когда еще не ясна архитектура всей системы, их следует рассматривать как описание работы пользователя с системой в целом.
А дальше, уже при формировании требований к ПО, когда становится ясно какой функциональностью нужно "наделить" ПО, часть ПИ "перекочует" в описание работы пользователя с ПО.
Что думаете?
-
Я попросил высказать свои мнения о том, в какое место ТЗ лучше всего вставить ПИ с учетом логики изложения ТЗ и особенностей ПИ.
В "Приложение [буква]".
Пользовательские истории имеют отношение к системе в целом, или к программному обеспечению системы?
Если в истории будут слова, что пользователь посидел на стуле, входящем в комплект АРМ, и почитал Положение об отделе, в котором он работает, а потом поклацал кнопками (или наоборот) - то ко всей системе. Если только поклацал - можно к ПО.
На стадии формирования требований к АС, т.е. когда еще не ясна архитектура всей системы, их следует рассматривать как описание работы пользователя с системой в целом.
Да. Но конкретное ТЗ(ЧТЗ) - про вполне конкретные составляющие системы.
-
Какая разница, куда вы вставите и как назовёте?
Разница может быть продиктована процессом взаимоотношений с Заказчиком. Если отношения ведутся в официальном ключе и с соблюдением стандартов, то на приемке потребуется строгое соответствие сдаваемого техническому заданию. Чтобы обеспечить это соответствие, в ТЗ придется вносить изменения. Изменения в тело ТЗ вносятся специальными документами, которые согласовываются и утверждаются в том же порядке (и теми же должностями), что и ТЗ.
Поэтому изменения в теле ТЗ желательно свести к минимуму. Дабы не раздражать властьимущих и контролирующих.
-
Если отношения ведутся в официальном ключе и с соблюдением стандартов…
То при чём тут user story? Тут, как говорится, надо или крестик снять или трусы надеть.
-
То при чём тут user story? Тут, как говорится, надо или крестик снять или трусы надеть.
User story совершенно не при чем, дело в общем подходе.
В официальное ТЗ надо вставить нечто чужеродное, что имеет тенденцию часто меняться. Зачем надо - я обсуждать не готов, вот такая забористая дурь в команде автора. Что реально могу - ответить автору на его вопрос "куда вставить последнюю..." так, чтобы потом не было мучительно больно.
А так... Если начальник/заказчик возжелал сделать что-то непотребное, платит за это достаточно денег и не ведется на вразумления, скорее всего придется плясать в крестике, без трусов и в шапке-ушанке. Или отказаться от работы, что не каждый работник/организация может себе позволить.
-
...
В официальное ТЗ надо вставить нечто чужеродное, что имеет тенденцию часто меняться. Зачем надо - я обсуждать не готов, вот такая забористая дурь в команде автора. Что реально могу - ответить автору на его вопрос "куда вставить последнюю..." так, чтобы потом не было мучительно больно. ...
спасибо за понимание :)
-
Я бы добавил user stories в раздел Требования к Системе в подраздел Требования к функциональным характеристикам.
-
Я бы добавил user stories в раздел Требования к Системе в подраздел Требования к функциональным характеристикам.
понятно, спасибо за помощь