Привет. Рад, что статья оказалась полезной.
Отвечу по порядку.
Интересно было бы узнать не перекрываются ли у вас user stories и functional requirements?
Да, они перекрываются, но это требования разного уровня.
User Stories находятся между требованиями бизнеса и пользователей. В случае же FR, мы детализируем как это будет сделано с точки зрения приложения.
Что вас привело к использованию user stories вместе с use case + functional req?
Во-первых, нам нужно было фиксировать имплементацию и то как должно работать приложение. Необходимость данных действий я описал в статье (да это не совсем практика Agile из-за формализма, но сама методология этого не запрещает)
Во-вторых, у данных требований разный уровень детализации, который постепенно уточняется. Один набор требований поступает на подготовку дизайна. Далее эти требования после подготовки и согласования макетов покрываются спецификацией.
В третьих, заказчику со стороны бизнеса не удобно читать громоздкие документы. Максимум — это Use Cases. (имхо, ситуации разные, но в нашем случае это именно так)
Например: use case хорошо фиксирует логику и взаимодействие пользователя с приложением. Их удобно читать дизайнеру, UX-проектировщику и заказчику, но назвать такие требования полными сложно. Именно поэтому мы дополняем их FR. Вигерс К. тоже рекомендует подобную схему.
Делаете ли вы какой-нибудь mapping типа user story -> use case, или только functional req -> use case?
Да, мы делаем. Используем трасибилити матрицу. Расписывать нашу стратегию трассировки не буду, так как это тема отдельной статьи как минимум.
JIRA и Confluence глубоко интегрированы друг в друга.
Постановка задач осуществляется в JIRA. После подготовки требований в Confluence мы линкуем их к задачам в JIRA.
Получается прямая зависимость, которая поддерживается как JIRA, так и Confluence.
Плюс, используя сторонние плагины, можно строить матрицы трассировки на основании такой связки.
Учтём!
Отвечу по порядку.
Да, они перекрываются, но это требования разного уровня.
User Stories находятся между требованиями бизнеса и пользователей. В случае же FR, мы детализируем как это будет сделано с точки зрения приложения.
Во-первых, нам нужно было фиксировать имплементацию и то как должно работать приложение. Необходимость данных действий я описал в статье (да это не совсем практика Agile из-за формализма, но сама методология этого не запрещает)
Во-вторых, у данных требований разный уровень детализации, который постепенно уточняется. Один набор требований поступает на подготовку дизайна. Далее эти требования после подготовки и согласования макетов покрываются спецификацией.
В третьих, заказчику со стороны бизнеса не удобно читать громоздкие документы. Максимум — это Use Cases. (имхо, ситуации разные, но в нашем случае это именно так)
Например: use case хорошо фиксирует логику и взаимодействие пользователя с приложением. Их удобно читать дизайнеру, UX-проектировщику и заказчику, но назвать такие требования полными сложно. Именно поэтому мы дополняем их FR. Вигерс К. тоже рекомендует подобную схему.
Да, мы делаем. Используем трасибилити матрицу. Расписывать нашу стратегию трассировки не буду, так как это тема отдельной статьи как минимум.
JIRA и Confluence глубоко интегрированы друг в друга.
Постановка задач осуществляется в JIRA. После подготовки требований в Confluence мы линкуем их к задачам в JIRA.
Получается прямая зависимость, которая поддерживается как JIRA, так и Confluence.
Плюс, используя сторонние плагины, можно строить матрицы трассировки на основании такой связки.