Накопление и детализация фичи (функциональности) происходит в пользовательской истории в разделе с функциональными требованиями (системный дизайн).
После того, как будет описано очередное бизнес правило и покрыто примерами, член команды разработки, описывающий историю, внесет изменения в функциональные требования.
В случае "Интерфейс не позволяет пользователю выбрать адрес вне зоны доставки" будут описаны детали функциональности, например заданы условия для возникновения ошибки и ее описание.
Не столько единственное отличие, сколько наиболее очевидное для меня. Вот еще несколько отличий, которые пришли на ум: - Сценарии использования описывают полную функциональность, со всеми альтернативными вариантами и исключениями. Пользовательские истории зачастую описывают только ту часть функциональности, которая в ней разрабатывается или изменяется. - Формат описания различается. В сценариях использования он более полный, с указанием триггера, актеров, пред- и пост-условий. Также указываются все основные шаги. В пользовательской истории все гораздо более упрощённо. - Цель документов разная. Сценарий использования дает представление прежде всего бизнес-стейкхолдерам и позволяет согласовать общее поведение системы. Пользовательская история прежде всего дает понять что нужно имплементировать.
В первой версии пользовательская история может совподать со сценарием использования по смыслу, но не по содержанию, формату и детальности.
Я вижу системное поведение, описанное в пользовательской истории скорее как набор упрощенных и ограниченных вариантов из сценария пользователя.
Пользовательские истории являются лишь частным случаем технического задания. Вместе с эпиками, фичами, и порой, тасками они описывают то, что нужно сделать.
Помимо этого, мы имеем набор сценариев использования, описывающих взаимодействие с системами. Эти артефакты являются своего рода контрактами с бизнесом, утверждающими общее поведение систем. В дополнение к самим сценариям есть и общее описание контекста, в котором все происходит. Этим типом документации охотно пользуются интеграторы.
Также у нас присутствует и техническая документация, такая как диаграммы активностей, последовательностей, классов, компонент. Она нужна уже для фиксации конкретного детального дизайна систем, чтобы передавать эти знания между разработчиками. Как в нашей команде, так и между командами.
Плюс, мы описываем gherkin сценарии, они пошагово описывают поведение системы и используются в тестировании (е2е). Такие сценарии покрываются кодом и встраиваются в devops pipeline.
ЕА действительно является инструментом очень широкого профиля. Мы не используем его "на полную", так как считаем что некоторые типы документации можно вести быстрее и проще используя другие инструменты.
Концепты — те же диаграммы, но отражающие возможное будущее состояние системы.
Трейсобилити матрицы
Что мы не делаем в ЕА, но он это может:
Сами сценарии использования
Генерация спецификаций / документов
Генерация кода
Интеграция со средствами публикации, например confluence
Если интересно узнать про современные практики ведение документации для разработки ПО, то можно почитать про Solution Intent. Это термин фреймворка SAFe, которые описывает базовые принципы того, как должна выглядеть подобная документация. У каждого проекта, конечно же, своё понимание реализации этого подхода, но тем не менее общие принципы там описаны и могут быть полезными.
Use Case это сценарий использования. Его цель — описать взаимодействие пользователя с системой или системы с системой, чтобы бизнесу, интеграторам или другим заинтересованным лицам можно было быстро и просто понять как работать с системой. Сценарии использования имеют другой жизненный цикл. Зачастую сценариями использования пользуются гораздо дольше, чем пользовательскими историями.
Например, в пользовательской истории US001 мы ввели некую функциональность. В сценарии использовании UC01 мы описали взаимодействие с системой по этой функциональности. Затем в истории US127 мы изменили изначальную функциональность. После этого обновили сценарий использования UC01 в соответствии с изменениями.
Пользовательская история "живет" пока происходит разработка соответствующей функциональности. Возможно она "оживет" еще раз, если по ней найдут баг. В этом случае кто-то из команды прочтет ее, чтобы вспомнить в чем была задумка.
Сценарий использования же "живет" всегда пока жива сама функциональность. Он обновляется и в любой момент времени должен быть актуальным.
Но некая схожесть раздела "Системное поведение" пользовательской истории со сценарием использования все же есть, вы правы. Зачастую, определенные примеры системного поведения описывают альтернативные потоки и исключения соответствующего сценария использования.
Да, действительно. Критерии приемки в сокращенном виде отражают большую часть сценариев поведения. Мы оставили их раздельными, потому что они заполняются в разное время и разными людьми.
Критерии приемки заполняются владельцем продукта, и в нашей команде принято, что история не может быть создана без критериев. Это самые важные особенности функциональности, по которым владелец продукта будет определять выполнена сторя или нет.
Сценарии поведения системы заполняются членом команды разработки, который проводит анализ истории, а впоследствии дополняются и изменяются на сессии трех друзей. Это происходит во время так называемого груминга, процесса проработки истории. Цель этого раздела более обширна. Тут нужно учесть все варианты поведения системы, которые впоследствии надо будет покрыть тестами. Часть из них не так важна для владельца продукта, и вполне вероятно, даже не будет показана на спринт ревью.
Что касается базы данных BR и FR. Мы практикуем создание матрицы прослеживаемости (traceability matrix) для каждой истории. В Enterprise Architect (инструмент для моделирования) на каждый спринт мы создаем несколько диаграм, по числу пользовательских историй. На каждой из диаграм на матрице отображаются отдельными элементами требования и артефакты. Матрица состоит из столбцов и строк. Столбцы описывают:
бизнес-требования
функциональные и (не-) требования
артефакты: активности, которые были изменены из-за реализации требования. Могут быть также интерфейсы, объекты дата-модели и так далее. Все они есть на других диаграммах как часть технической документации
тесты: названия или ссылки на конфлюенс с конкретными геркин-сценариями
Строками описываются разные системы. Мы стараемся делить стори, в которых затронуты несколько систем, но не всегда это имеет смысл. Если история влияет на несколько систем, то они описываются в разных строчках.
Между элементами диаграммы проставляются ассоциации. Они помогают понять какое бизнес требование породило те или иные функциональные требования, и как функциональные требования повлияли на конкретные активности или данные.
Соответственно, если элемент из колонки слева не имеет связи хотя бы на один элемент из следующей колонки - то появляется гэп, пробел в требованиях или реализации.
Enterprise Architect также позволяет находить в каких спринтах и из-за каких требований менялась активность на диаграмме. Очень удобно.
По поводу компаний, успешно внедривших подобные фреймворки — у нас (Deutschetelekom IT Solutions) получилось масштабно внедрить, а также слышал про Deutsche Bank, они пару лет назад выпускали видеоролики с позитивными результатами. Это по РФ. По миру — примеров гораздо больше. Но успешность тут во многом зависит от культуры компании и от процесса внедрения. Сам по себе фреймворк не гарантирует позитивных изменений.
Я пока сфокусировался на том, чтобы писать понятно и не сложно. Как только у меня начнет это получаться — буду писать длиннее, может даже на несколько печенек хватит.
Для команды компоненты: продукт — это компонента, для команды биллинга — это биллинг.
Вот именно это и побудило меня написать первую статью. Никто не понимает точно, что нужно считать продуктом, а что просто промежуточная компонента. В итоге некоторые владельцы продуктов по сути являются аналитиками, просто расписывающими юзер стори для команд.
Сейчас я склонен считать, что продукт определяется только тем, что он решает какую-то конечную задачу для определенной группы пользователей. Подробнее я планировал раскрыть эту мысль в часте про пользователей. Там, с помощью подхода JTBD можно будет наглядно увидеть как формируется ценность того или иного продукта.
Биллинг, конечно тоже имеет ценность в контексте оказания услуги, но его роль в сценарии использования в большинстве известных мне случаев будет на уровне подфункции. Про уровни целей пользователя очень хорошо писал Алистер Коберн. Постараюсь это подробно объяснить в четвертой части этого цикла.
Т.е. как происходит организация команд для реализации мега-продуктов?
Чуть-чуть терпения. Про организацию команд, координацию работы продактов и наиболее популярные фреймворки я еще расскажу.
Спасибо! Вообще это статья про накипевшее.
Сейчас я активно изучаю продакт-менеджмент и думаю как все эти практики можно применить в устоявшемся энтерпрайзе. Если вам интересно продолжение по развитию именно этой идеи — то я боюсь, что продолжение я смогу написать только после первых удачных (или не очень) результатах. По моим прикидкам, это в лучшем случае случится через пол года.
Однако у меня есть достаточно опыта в SAFe трансформациях, я мог бы рассказать про набор типичных ошибок при переходе на него, к примеру.
P.S. Это первая моя статья на хабре, и я понял что писать сюда очень не просто. Но с другой стороны это отлично развивает.
Кстати, Андрей Круз, автор очень хорошей серии книг по зомби-апокалипсису как то высказывал желание написать сценарий и принять активное участие в создании игры в жанре его книг. (ЖЖ andrey-cruz.livejournal.com/34296.html)
Вот еще некоторые его идеи по особенностям игры (Опять ЖЖ andrey-cruz.livejournal.com/152702.html). Может Вам стоит ему написать?
А как вариант — улучшить экономические условия в нашей стране не рассматривается? Ну чтобы выгоднее было заниматься бизнесом здесь а не продавать из-за границы. Очевидное решение же. Жаль что у государства несколько иные цели чем обслуживание и создание комфортных условий населению.
Вообще-то имел ввиду диаграмму по одному конкретному пользователю, но мысль интересная. То есть можно быстро определить по диаграмме статистические показатели целой команды исполнителей. Звучит как удобная фича.
Ok, можно сделать проще. При публикации негативного отзыва опционально указывать категорию проблемы. При просмотре профиля будет выводиться, к примеру, следующая информация:
Количество сделок: 500
Позитивные отзывы: 90%
И ниже пристроить радиальную диаграмму со смещениями в сторону главных недостатков — не достаточная скорость, низкое качество работы, адекватность общения и так далее.
Соответственно если отзыв оставлен позитивный, то указывать недостатки не надо.
Можно ввести также дополнительные субъективные критерии фидбека по определенной шкале, как то: скорость работы, её качество, адекватность общения и так далее.
Альтернативный вариант — система отзывов как у торговых площадок наподобие eBay. С показателями в виде количества работ и процента позитивных отзывов, которые можно оставлять только после завершения сделки.
Накопление и детализация фичи (функциональности) происходит в пользовательской истории в разделе с функциональными требованиями (системный дизайн).
После того, как будет описано очередное бизнес правило и покрыто примерами, член команды разработки, описывающий историю, внесет изменения в функциональные требования.
В случае "Интерфейс не позволяет пользователю выбрать адрес вне зоны доставки" будут описаны детали функциональности, например заданы условия для возникновения ошибки и ее описание.
Не столько единственное отличие, сколько наиболее очевидное для меня. Вот еще несколько отличий, которые пришли на ум:
- Сценарии использования описывают полную функциональность, со всеми альтернативными вариантами и исключениями. Пользовательские истории зачастую описывают только ту часть функциональности, которая в ней разрабатывается или изменяется.
- Формат описания различается. В сценариях использования он более полный, с указанием триггера, актеров, пред- и пост-условий. Также указываются все основные шаги. В пользовательской истории все гораздо более упрощённо.
- Цель документов разная. Сценарий использования дает представление прежде всего бизнес-стейкхолдерам и позволяет согласовать общее поведение системы. Пользовательская история прежде всего дает понять что нужно имплементировать.
В первой версии пользовательская история может совподать со сценарием использования по смыслу, но не по содержанию, формату и детальности.
Я вижу системное поведение, описанное в пользовательской истории скорее как набор упрощенных и ограниченных вариантов из сценария пользователя.
Пользовательские истории являются лишь частным случаем технического задания. Вместе с эпиками, фичами, и порой, тасками они описывают то, что нужно сделать.
Помимо этого, мы имеем набор сценариев использования, описывающих взаимодействие с системами. Эти артефакты являются своего рода контрактами с бизнесом, утверждающими общее поведение систем. В дополнение к самим сценариям есть и общее описание контекста, в котором все происходит. Этим типом документации охотно пользуются интеграторы.
Также у нас присутствует и техническая документация, такая как диаграммы активностей, последовательностей, классов, компонент. Она нужна уже для фиксации конкретного детального дизайна систем, чтобы передавать эти знания между разработчиками. Как в нашей команде, так и между командами.
Плюс, мы описываем gherkin сценарии, они пошагово описывают поведение системы и используются в тестировании (е2е). Такие сценарии покрываются кодом и встраиваются в devops pipeline.
ЕА действительно является инструментом очень широкого профиля. Мы не используем его "на полную", так как считаем что некоторые типы документации можно вести быстрее и проще используя другие инструменты.
Что мы делаем в ЕА:
Техническую документацию (диаграммы активностей, классов, последовательностей, карты сценариев использования, диаграммы компонентов)
Концепты — те же диаграммы, но отражающие возможное будущее состояние системы.
Трейсобилити матрицы
Что мы не делаем в ЕА, но он это может:
Сами сценарии использования
Генерация спецификаций / документов
Генерация кода
Интеграция со средствами публикации, например confluence
Если интересно узнать про современные практики ведение документации для разработки ПО, то можно почитать про Solution Intent. Это термин фреймворка SAFe, которые описывает базовые принципы того, как должна выглядеть подобная документация. У каждого проекта, конечно же, своё понимание реализации этого подхода, но тем не менее общие принципы там описаны и могут быть полезными.
Не совсем.
Use Case это сценарий использования. Его цель — описать взаимодействие пользователя с системой или системы с системой, чтобы бизнесу, интеграторам или другим заинтересованным лицам можно было быстро и просто понять как работать с системой. Сценарии использования имеют другой жизненный цикл. Зачастую сценариями использования пользуются гораздо дольше, чем пользовательскими историями.
Например, в пользовательской истории US001 мы ввели некую функциональность. В сценарии использовании UC01 мы описали взаимодействие с системой по этой функциональности. Затем в истории US127 мы изменили изначальную функциональность. После этого обновили сценарий использования UC01 в соответствии с изменениями.
Пользовательская история "живет" пока происходит разработка соответствующей функциональности. Возможно она "оживет" еще раз, если по ней найдут баг. В этом случае кто-то из команды прочтет ее, чтобы вспомнить в чем была задумка.
Сценарий использования же "живет" всегда пока жива сама функциональность. Он обновляется и в любой момент времени должен быть актуальным.
Но некая схожесть раздела "Системное поведение" пользовательской истории со сценарием использования все же есть, вы правы. Зачастую, определенные примеры системного поведения описывают альтернативные потоки и исключения соответствующего сценария использования.
Всегда пожалуйста.
Да, действительно. Критерии приемки в сокращенном виде отражают большую часть сценариев поведения. Мы оставили их раздельными, потому что они заполняются в разное время и разными людьми.
Критерии приемки заполняются владельцем продукта, и в нашей команде принято, что история не может быть создана без критериев. Это самые важные особенности функциональности, по которым владелец продукта будет определять выполнена сторя или нет.
Сценарии поведения системы заполняются членом команды разработки, который проводит анализ истории, а впоследствии дополняются и изменяются на сессии трех друзей. Это происходит во время так называемого груминга, процесса проработки истории. Цель этого раздела более обширна. Тут нужно учесть все варианты поведения системы, которые впоследствии надо будет покрыть тестами. Часть из них не так важна для владельца продукта, и вполне вероятно, даже не будет показана на спринт ревью.
Что касается базы данных BR и FR. Мы практикуем создание матрицы прослеживаемости (traceability matrix) для каждой истории. В Enterprise Architect (инструмент для моделирования) на каждый спринт мы создаем несколько диаграм, по числу пользовательских историй. На каждой из диаграм на матрице отображаются отдельными элементами требования и артефакты. Матрица состоит из столбцов и строк. Столбцы описывают:
бизнес-требования
функциональные и (не-) требования
артефакты: активности, которые были изменены из-за реализации требования. Могут быть также интерфейсы, объекты дата-модели и так далее. Все они есть на других диаграммах как часть технической документации
тесты: названия или ссылки на конфлюенс с конкретными геркин-сценариями
Строками описываются разные системы. Мы стараемся делить стори, в которых затронуты несколько систем, но не всегда это имеет смысл. Если история влияет на несколько систем, то они описываются в разных строчках.
Между элементами диаграммы проставляются ассоциации. Они помогают понять какое бизнес требование породило те или иные функциональные требования, и как функциональные требования повлияли на конкретные активности или данные.
Соответственно, если элемент из колонки слева не имеет связи хотя бы на один элемент из следующей колонки - то появляется гэп, пробел в требованиях или реализации.
Enterprise Architect также позволяет находить в каких спринтах и из-за каких требований менялась активность на диаграмме. Очень удобно.
По поводу компаний, успешно внедривших подобные фреймворки — у нас (Deutschetelekom IT Solutions) получилось масштабно внедрить, а также слышал про Deutsche Bank, они пару лет назад выпускали видеоролики с позитивными результатами. Это по РФ. По миру — примеров гораздо больше. Но успешность тут во многом зависит от культуры компании и от процесса внедрения. Сам по себе фреймворк не гарантирует позитивных изменений.
Вот именно это и побудило меня написать первую статью. Никто не понимает точно, что нужно считать продуктом, а что просто промежуточная компонента. В итоге некоторые владельцы продуктов по сути являются аналитиками, просто расписывающими юзер стори для команд.
Сейчас я склонен считать, что продукт определяется только тем, что он решает какую-то конечную задачу для определенной группы пользователей. Подробнее я планировал раскрыть эту мысль в часте про пользователей. Там, с помощью подхода JTBD можно будет наглядно увидеть как формируется ценность того или иного продукта.
Биллинг, конечно тоже имеет ценность в контексте оказания услуги, но его роль в сценарии использования в большинстве известных мне случаев будет на уровне подфункции. Про уровни целей пользователя очень хорошо писал Алистер Коберн. Постараюсь это подробно объяснить в четвертой части этого цикла.
Чуть-чуть терпения. Про организацию команд, координацию работы продактов и наиболее популярные фреймворки я еще расскажу.
Сейчас я активно изучаю продакт-менеджмент и думаю как все эти практики можно применить в устоявшемся энтерпрайзе. Если вам интересно продолжение по развитию именно этой идеи — то я боюсь, что продолжение я смогу написать только после первых удачных (или не очень) результатах. По моим прикидкам, это в лучшем случае случится через пол года.
Однако у меня есть достаточно опыта в SAFe трансформациях, я мог бы рассказать про набор типичных ошибок при переходе на него, к примеру.
P.S. Это первая моя статья на хабре, и я понял что писать сюда очень не просто. Но с другой стороны это отлично развивает.
Вот еще некоторые его идеи по особенностям игры (Опять ЖЖ andrey-cruz.livejournal.com/152702.html). Может Вам стоит ему написать?
Количество сделок: 500
Позитивные отзывы: 90%
И ниже пристроить радиальную диаграмму со смещениями в сторону главных недостатков — не достаточная скорость, низкое качество работы, адекватность общения и так далее.
Соответственно если отзыв оставлен позитивный, то указывать недостатки не надо.