Комментарии 8
Ребята, вы молодцы — написано очень доступно, но при этом информативно.
Интересно узнать, как вы находите баланс между описанием требований в Confluence и JIRA:
— описываете всё в Confluence, а в JIRA тикетах даёте ссылки?
— как поддерживаете версионность?
— описываете всё в Confluence, а в JIRA тикетах даёте ссылки?
— как поддерживаете версионность?
Привет. Спасибо за комментарий.
JIRA и Confluence глубоко интегрированы друг в друга.
Постановка задач осуществляется в JIRA. После подготовки требований в Confluence мы линкуем их к задачам в JIRA.
Получается прямая зависимость, которая поддерживается как JIRA, так и Confluence.
Плюс, используя сторонние плагины, можно строить матрицы трассировки на основании такой связки.
JIRA и Confluence глубоко интегрированы друг в друга.
Постановка задач осуществляется в JIRA. После подготовки требований в Confluence мы линкуем их к задачам в JIRA.
Получается прямая зависимость, которая поддерживается как JIRA, так и Confluence.
Плюс, используя сторонние плагины, можно строить матрицы трассировки на основании такой связки.
Спасибо за статью, из любопытства хотелось бы задать пару вопросов :)
Интересно было бы узнать не перекрываются ли у вас user stories и functional requirements?
Что вас привело к использованию user stories вместе с use case + functional req?
Делаете ли вы какой-нибудь mapping типа user story -> use case, или только functional req -> use case?
Интересно было бы узнать не перекрываются ли у вас user stories и functional requirements?
Что вас привело к использованию user stories вместе с use case + functional req?
Делаете ли вы какой-нибудь mapping типа user story -> use case, или только functional req -> use case?
Привет. Рад, что статья оказалась полезной.
Отвечу по порядку.
Да, они перекрываются, но это требования разного уровня.
User Stories находятся между требованиями бизнеса и пользователей. В случае же FR, мы детализируем как это будет сделано с точки зрения приложения.
Во-первых, нам нужно было фиксировать имплементацию и то как должно работать приложение. Необходимость данных действий я описал в статье (да это не совсем практика Agile из-за формализма, но сама методология этого не запрещает)
Во-вторых, у данных требований разный уровень детализации, который постепенно уточняется. Один набор требований поступает на подготовку дизайна. Далее эти требования после подготовки и согласования макетов покрываются спецификацией.
В третьих, заказчику со стороны бизнеса не удобно читать громоздкие документы. Максимум — это Use Cases. (имхо, ситуации разные, но в нашем случае это именно так)
Например: use case хорошо фиксирует логику и взаимодействие пользователя с приложением. Их удобно читать дизайнеру, UX-проектировщику и заказчику, но назвать такие требования полными сложно. Именно поэтому мы дополняем их FR. Вигерс К. тоже рекомендует подобную схему.
Да, мы делаем. Используем трасибилити матрицу. Расписывать нашу стратегию трассировки не буду, так как это тема отдельной статьи как минимум.
Отвечу по порядку.
Интересно было бы узнать не перекрываются ли у вас 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?
Да, мы делаем. Используем трасибилити матрицу. Расписывать нашу стратегию трассировки не буду, так как это тема отдельной статьи как минимум.
Небольшое замечание по оформлению. Я сначала впал в прострацию — как это 3-я неделя предшествует 2-ой? И только потом дошло, что знак «тире» (длинная черта) да еще и с пробелом перед цифрой — это вовсе не тире, а минус (короткая черта). Тщательнее. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Моделирование спринтов Scrum. Решаем проблемы взаимодействия с клиентом и внутри команды