Эта статья описывает простейшую схему использования
JIRA как единственного инструмента управления agile-проектами.
Одной из основ agile-проектов является отслеживание скорости своей работы. По сути это объем работы, который вы выполняете за определенный период времени. Agile-проекты выполняются итерациями. Итерация может длиться неделю, 2 недели или возможно месяц. Продолжительность итерации зависит от проекта, хорошо начинать с 2-х недельных итераций. Каждая итерация имеет набор назначенных ей story. Story это одна фича, определенная вашим анализом проекта перед первой итерацией. Обратите внимание, что поскольку мы имеем дело с agile-проектом, вам не нужно предварительно анализировать проект и полностью его планировать. Вам нужно лишь то, что позволит двигаться вперед, в процессе работы вы будете создавать и оценивать больше story.
Story в Jira
Список story видим при открытии Jira. В любой версии Jira можно установить тип задач по умолчанию. Имеется тип задач называемый Story. В Jira при анализе требований и создании user story вы можете создать новые типы задач "Story", однако вам не нужно будет сразу же их анализировать и конечно не нужно будет на данном этапе относить их к какой-либо итерации.


Как видно со скриншота, данная story была оценена, а дата ее оценки записана. Оба эти поля настраиваемые пользователем, «Story Points» (очки story) это числовое поле, а Estimation Date (дата оценки) это поле с выбором даты. Jira позволяет добавлять эти настраиваемые поля прямо в конкретный тип задач, в нашем случае это "Story".
Добавление поля «Estimation Date» обосновано тем, что для некоторых отчетов, которые мы хотим генерировать, требуется дата вступления в действие новых story. Для этого можно использовать дату создания задачи, однако может оказаться, что вы пожелаете считать story доступной только после ее оценки и при этом записать по этой story некоторую информацию до такой оценки.
Поле «Story Points» имеет числовое значение, а не часто используемые значения размеров футболок (Small - маленькая, Medium - средняя, Large - большая). Нам требуются числовые значения для расчетов, основанных на величине Story, и мы не хотим угадывать числовые значения, которые соответствуют S/M/L т.к. они будут меняться в зависимости от проекта. В нашем случае мы можем использовать Small=3, Medium=5 и Large=8.
Жизненный цикл story
Story должны проходить определенный жизненный цикл (workflow), моделирующий возможные состояния, в которых они могут быть. Если вы можете себе позволить полную версию Enterprise Jira, то, я уверен, это легко можно сделать c помощью индивидуально настраиваемого workflow, однако установленный по умолчанию workflow достаточно хорошо работает, если принять следующее:
|
Стадия story
|
Стадия в Jira, соответствующая стадии story
|
| Новая story, готовая к оценке |
Открытая задача типа «story» без значения в поле «Story Points» |
| Story, готовая к внесению в график |
Открытая Story со значением в поле «Story Points» и возможно с указанной датой оценки |
| Story, готовая к разработке |
Story в разработке, которая была передана разработчику |
| Story, готовая к тестированию |
Story, помеченная разработчиком как выполненная |
| Протестированная и законченная story |
Story, помеченная тестировщиком как закрытая |
Обратите внимание, что вы можете сделать настраиваемый фильтр, с помощью которого можно найти все story, которые находятся в любой из этих стадий.
Итерации в Jira
Использование встроенной системы версий Jira позволяет достаточно просто создавать итерации.
В этой настройке мы имеем 6 итераций, каждая имеет дату релиза. Релиз двух итераций уже был произведен, а третий состоится в пятницу 24 октября.
Когда вы будете готовы планировать итерации, вам нужно будет лишь отнести созданные story к соответствующим итерациям. Для этого в Jira используется поле «Fix for version»

Как вы видите, впереди у нас запланировано 4 итерации, а итерация 3 уже имеет одну завершенную story и 3 story, которые нужно выполнить.
Обратите внимание, что итерации 5 и 6 еще не имеют запланированных story.
Отчеты по аgile-проектам
Воспользуемся плагином Agile Velocity Tracking Plugin, который генерирует диаграммы на основании ваших «Story Points» и итераций.

Как вы видите, следует выбрать лишь несколько опций при настройке отчета, однако настройки по умолчанию также вполне подходят.
Вы получаете следующий отчет (кликните на рисунке для увеличения):

В верхней части отчета вы видите удобную сводку уже завершенных итераций и то, как ваши stories/points создаются и завершаются. Сводка включает предполагаемую дату завершении работы, которая определяется на основании уже оцененных story и вашей текущей скорости.
Диаграммы под сводкой показывают следующее:
• Stories/points созданные в итерациях
• Stories/points завершенные в итерациях = скорость
• Stories/points оставшиеся в итерациях
• Прогноз оставшихся stories/points
Заключение
Мы вкратце описали возможность использования инструмента отслеживания багов Jira для управления agile-проектом. У некоторых может возникнуть вопрос, зачем использовать его вместо традиционной стены с карточками, которая часто используется в agile-проектах. Стена с карточками это простое и устаревшее решение. Без чьей-то ручной работы невозможно использовать интернет, осуществлять поиск, фильтрацию, комментирование и создавать отчеты.
Перенос нашего рабочего процесса в Jira также позволяет интеграцию с настройкой постоянной интеграции и репозиторием исходного кода, таким образом, изменения и релизы легко отслеживаются и автоматически относятся к story (это тема одного из следующих блогов).
Англоязычный оригинал статьи: http://www.blackpepper.co.uk/black-pepper-blog/Using-Jira-for-an-Agile-project.html