JIRA: управление требованиями

[lingvo]

Статья хорошая, но к сожалению, слишком длинная и трудная для чтения.
Трудно читать даже мне, хотя я и занимаюсь управлением требованиями.

Следует учесть, что такой подход к управлению требованиями, как описан в статье, очень затратный по ресурсам и без наличия соответствующей команды быстро забывается — это мой опыт.
Поэтому ИМХО применимость его очень ограничена.

[aimfirst]

Спасибо за оценку. Объемность статьи выросла сама собой из-за стремления не забыть мелочи. Я использую эти статьи как неформальный регламент проектной команды. По мере написания статьи, я просто вставлял в нее ответы на вопросы, которые возникали у моих коллег по мере внедрения JIRA. В то же время, действия указанные в статье реализуются по необходимости, т.е. не носят обязательного характера. Поэтому ресурсы, для поддержания этой модели на практике не такие затратные, как может показаться на первый взгляд.

[aimfirst]

1 случай — требования на развитие ПО — например утвержденное ТЗ. Они сразу уходят на аналитика. «Атомизация» — это первичная регистрация в JIRA каждого требования (если хотите абзаца) ТЗ отдельно.

2 случай — это работа по ошибкам. Группа сопровождения — это первая линия — которая берет на себя задачу регистрации, разбиения (атомизации), сбора сопроводительных материалов и других подготовительных действий до передачи аналитику. При невысоком количестве ошибок от пользователей эти функции может выполнять аналитик.
Как то так.
Однако, замечу, что предложенные процессы не есть истина в последней инстанции. То что работает у нас — не факт, что будет эффективно в ваших условиях.

[p0st]

Спасибо вам за серию статей, с удовольствием прочитал и сохранил к себе в копилку.