IT Blog

В пятницу утром мой хороший знакомый прислал мне ссылку на занимательную статью The only 3 Milestones you will ever need, в которой изложена достаточно простая и, в тоже время, очень полезная идея об организации версий при agile-разработке.
«Разделите все задачи на 3 кучи:

1. Задачи, которые нужно выполнить к текущему релизу
2. Задачи, которые можно отложить до следующего релиза
3. Задачи, про которые не известно, когда их следует выполнять»

В проекте, над которым я сейчас работаю, принята именно такая организация задач в JIRA. Похожим образом устроена разработка Zend Framework.
Пока команда была небольшой острой необходимости в строгом соблюдении версий не было — задачи закрывались и объединялись в релизы постфактум. Однако последняя неделя стала для меня в этом вопросе переломной. Группа качества, занимающаяся проектом, удвоилась и просто затопила разработчиков сообщениями об ошибках. Число задач на моем JIRA dashboard перевалило за 50, и не было решительно никакой возможности понять, что же нужно сделать к надвигающемуся релизу. Статья о 3х вехах пришлась как нельзя кстати. Я разбросал задачи по версиям и реорганизовал свой рабочий стол.

До реорганизации на столе основными элементами были два списка отфильтрованных задач — «My bugs» и «My tasks». Иметь отдельные списки ошибок и задач мне кажется достаточно удобным. Ошибки мне видятся более важными, и я стараюсь браться за них как можно скорее, т.к. их наличие влияет на общее качество, тогда как разработку новой функциональности часто можно отложить на следующий релиз. Также ошибки можно быстро передать свободному разработчику, а задачи раздаются при планировании релиза (это скорее особенность команды и проекта).
Реорганизация свелась к созданию новых фильтров, где кроме поля «Assignee» и типа задачи указаны версии (с названиями «Current release», «Next Release» и Unscheduled).
После реорганизации на рабочем столе оказались 5 блоков:

1. Ошибки, которые нужно исправить в текущем релизе
2. Функции, которые нужно реализовать в текущем релизе
3. Ошибки с неуказанной версией для исправления
4. Функции с неуказанной версией реализации
5. Большой блок — задачи к следующему релизу

Как только релиз произошел «Current release» переименовывается в номер версии, «Next release» — в «Current release», создается новая версия с именем «Next release» и корректируются фильтры.

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