Комментарии 13
Спасибо за то что поделились опытом.
У меня есть два вопроса:
Хотелось бы уточнить что мешает совместить раздел Системного поведения и критериев приёмки? По сути, если проблема лежала именно в сфере "обнаружили баги" и это очевидно "баги постановки" это говорит о том что критерии приёмки недостаточно прописаны. В приведённом вами примере критерии приёмки выполняют роль некоего рудимента, о котором необходимо помнить, но в который никто не смотрит, поскольку все очевидно из BR и FR.
И ещё вопрос: ведёте ли вы отдельно базу BR и FR? Опять же из текущего примера не совсем понятно, поскольку везде используется один номер задачи 123, что оставляет за кадром проблему выявления неполноты требований, их перекрестного влияния и разрастания такой базы до размеров, когда с ней становится невозможно работать.
Всегда пожалуйста.
Да, действительно. Критерии приемки в сокращенном виде отражают большую часть сценариев поведения. Мы оставили их раздельными, потому что они заполняются в разное время и разными людьми.
Критерии приемки заполняются владельцем продукта, и в нашей команде принято, что история не может быть создана без критериев. Это самые важные особенности функциональности, по которым владелец продукта будет определять выполнена сторя или нет.
Сценарии поведения системы заполняются членом команды разработки, который проводит анализ истории, а впоследствии дополняются и изменяются на сессии трех друзей. Это происходит во время так называемого груминга, процесса проработки истории. Цель этого раздела более обширна. Тут нужно учесть все варианты поведения системы, которые впоследствии надо будет покрыть тестами. Часть из них не так важна для владельца продукта, и вполне вероятно, даже не будет показана на спринт ревью.
Что касается базы данных BR и FR. Мы практикуем создание матрицы прослеживаемости (traceability matrix) для каждой истории. В Enterprise Architect (инструмент для моделирования) на каждый спринт мы создаем несколько диаграм, по числу пользовательских историй. На каждой из диаграм на матрице отображаются отдельными элементами требования и артефакты. Матрица состоит из столбцов и строк. Столбцы описывают:
бизнес-требования
функциональные и (не-) требования
артефакты: активности, которые были изменены из-за реализации требования. Могут быть также интерфейсы, объекты дата-модели и так далее. Все они есть на других диаграммах как часть технической документации
тесты: названия или ссылки на конфлюенс с конкретными геркин-сценариями
Строками описываются разные системы. Мы стараемся делить стори, в которых затронуты несколько систем, но не всегда это имеет смысл. Если история влияет на несколько систем, то они описываются в разных строчках.
Между элементами диаграммы проставляются ассоциации. Они помогают понять какое бизнес требование породило те или иные функциональные требования, и как функциональные требования повлияли на конкретные активности или данные.
Соответственно, если элемент из колонки слева не имеет связи хотя бы на один элемент из следующей колонки - то появляется гэп, пробел в требованиях или реализации.
Enterprise Architect также позволяет находить в каких спринтах и из-за каких требований менялась активность на диаграмме. Очень удобно.
Мне кажется, или вы начали модифицировать User story, а в итоге реализовали Use case?
Не совсем.
Use Case это сценарий использования. Его цель — описать взаимодействие пользователя с системой или системы с системой, чтобы бизнесу, интеграторам или другим заинтересованным лицам можно было быстро и просто понять как работать с системой. Сценарии использования имеют другой жизненный цикл. Зачастую сценариями использования пользуются гораздо дольше, чем пользовательскими историями.
Например, в пользовательской истории US001 мы ввели некую функциональность. В сценарии использовании UC01 мы описали взаимодействие с системой по этой функциональности. Затем в истории US127 мы изменили изначальную функциональность. После этого обновили сценарий использования UC01 в соответствии с изменениями.
Пользовательская история "живет" пока происходит разработка соответствующей функциональности. Возможно она "оживет" еще раз, если по ней найдут баг. В этом случае кто-то из команды прочтет ее, чтобы вспомнить в чем была задумка.
Сценарий использования же "живет" всегда пока жива сама функциональность. Он обновляется и в любой момент времени должен быть актуальным.
Но некая схожесть раздела "Системное поведение" пользовательской истории со сценарием использования все же есть, вы правы. Зачастую, определенные примеры системного поведения описывают альтернативные потоки и исключения соответствующего сценария использования.
Если это единственное отличие, на ваш взгляд, то Use case - актуальная версия описания функциональности на Confluence, а User stories - каждый отдельный коммит (правка) и в самой первой версии они совпадают.
Я же хотел бы обратить внимание на структурные изменения вашей истории с учетом ориентирования на клиента в сравнении с классической user story (не говоря уж про усечённые): в ней сильно меньше от user story, но значительная часть от use case. Ну окей, живёт не вечно и не актуализируется (как и отдельная версия страницы на confluence), в остальном же это скорее use case.
Или я где-то что-то понимаю не так?
Не столько единственное отличие, сколько наиболее очевидное для меня. Вот еще несколько отличий, которые пришли на ум:
- Сценарии использования описывают полную функциональность, со всеми альтернативными вариантами и исключениями. Пользовательские истории зачастую описывают только ту часть функциональности, которая в ней разрабатывается или изменяется.
- Формат описания различается. В сценариях использования он более полный, с указанием триггера, актеров, пред- и пост-условий. Также указываются все основные шаги. В пользовательской истории все гораздо более упрощённо.
- Цель документов разная. Сценарий использования дает представление прежде всего бизнес-стейкхолдерам и позволяет согласовать общее поведение системы. Пользовательская история прежде всего дает понять что нужно имплементировать.
В первой версии пользовательская история может совподать со сценарием использования по смыслу, но не по содержанию, формату и детальности.
Я вижу системное поведение, описанное в пользовательской истории скорее как набор упрощенных и ограниченных вариантов из сценария пользователя.
Enterprise Architect имеет все инструменты для моделирования как продуктов так и требований к ним. А вы его упомянули как вспомогательный иструмент для построения матриц взаимоотношений , т.е. для моделирования моделирования - выглядит как масло масляное. Или же вы дейтвительно используете EA на полную?
ЕА действительно является инструментом очень широкого профиля. Мы не используем его "на полную", так как считаем что некоторые типы документации можно вести быстрее и проще используя другие инструменты.
Что мы делаем в ЕА:
Техническую документацию (диаграммы активностей, классов, последовательностей, карты сценариев использования, диаграммы компонентов)
Концепты — те же диаграммы, но отражающие возможное будущее состояние системы.
Трейсобилити матрицы
Что мы не делаем в ЕА, но он это может:
Сами сценарии использования
Генерация спецификаций / документов
Генерация кода
Интеграция со средствами публикации, например confluence
Если интересно узнать про современные практики ведение документации для разработки ПО, то можно почитать про Solution Intent. Это термин фреймворка SAFe, которые описывает базовые принципы того, как должна выглядеть подобная документация. У каждого проекта, конечно же, своё понимание реализации этого подхода, но тем не менее общие принципы там описаны и могут быть полезными.
Спасибо за наводку про ЕА и Confluence - не знал, хотя и прошел два ЕА курса и сделал все диаграммы из выше перечисленных для кофейной машины и банковского терминала:). Разные фреймворки тоже конечно интересно, но у нас PLM и соответственно TeamCenter/Polarion и PlanView /ProjectPlace. Конечно разработчики железа их и используют, програмисты все равно на Jira и Confluence, a системным архитекторам приходится работать со всем этим.
Интересно, вы работаете только по историям, вообще без описания сценариев?
Пользовательские истории являются лишь частным случаем технического задания. Вместе с эпиками, фичами, и порой, тасками они описывают то, что нужно сделать.
Помимо этого, мы имеем набор сценариев использования, описывающих взаимодействие с системами. Эти артефакты являются своего рода контрактами с бизнесом, утверждающими общее поведение систем. В дополнение к самим сценариям есть и общее описание контекста, в котором все происходит. Этим типом документации охотно пользуются интеграторы.
Также у нас присутствует и техническая документация, такая как диаграммы активностей, последовательностей, классов, компонент. Она нужна уже для фиксации конкретного детального дизайна систем, чтобы передавать эти знания между разработчиками. Как в нашей команде, так и между командами.
Плюс, мы описываем gherkin сценарии, они пошагово описывают поведение системы и используются в тестировании (е2е). Такие сценарии покрываются кодом и встраиваются в devops pipeline.
Не очень понятно, где происходит накопление детализации фичи по мере её проработки?
Детализация описания свойств и их параметров, логики поведения элементов интерфейса и т.п.
Например, при реализации описанного вами кейса, где будет сформулировано "Интерфейс не позволяет пользователю выбрать адрес вне зоны доставки" или "Если пользователь ввел адрес вне зоны доставки, то кнопка "Сохранить" неактивна и вывести подсказку "Извините, мы не можем доставить посылку по этому адресу".
Накопление и детализация фичи (функциональности) происходит в пользовательской истории в разделе с функциональными требованиями (системный дизайн).
После того, как будет описано очередное бизнес правило и покрыто примерами, член команды разработки, описывающий историю, внесет изменения в функциональные требования.
В случае "Интерфейс не позволяет пользователю выбрать адрес вне зоны доставки" будут описаны детали функциональности, например заданы условия для возникновения ошибки и ее описание.
Размышления о написании пользовательских историй