Лучшая практика для создания "Дорожной карты" в Джира
Мы хотим реализовать надежную "дорожную карту" для нашей дорожной карты развития продукта. Мы используем Jira (4.4.3) и Greenhopper для управления проектами и отслеживания ошибок, но функция Jira Roadmap просто показывает вам список версий, которые вы определили.
Однако в настоящее время мы используем наши "Версии" для каждого спринта, например, "Неделя 16", "Неделя 17" и т. Д., Которые содержат все задачи / проблемы для спринта этой недели.
В настоящее время мы используем "Компоненты" для отслеживания основных наборов функций и категоризации (например, "Интеграция с xyz API", "Перенос электронной почты в SendGrid", "Ошибки: код" или "Технический долг").
Функция "Дорожная карта" Jira показывает список версий и прогресс в каждой из них. Тем не менее, мы уже используем Версии для отслеживания наших еженедельных спринтов, и некоторые из этих дорожных карт будут охватывать многие выпуски / версии / спринты.
Как мы можем отслеживать нашу полную дорожную карту в Jira? Мы действительно хотели бы видеть список наших основных инициатив в этой дорожной карте вместо списка всех наших еженедельных спринтов (например, "Включить Selenium на CI-сервере", "Преобразование Extranet MVC3", "Обновить производство до R2").
3 ответа
Обновить
Упомянутая история GHS-945 уже была исправлена в GreenHopper 5.10 - в то время как GreenHopper 6.0 официально предоставляет все упомянутые основные улучшения, касающиеся Kanban, Scrum и особенно настраиваемой гибкой платы, планирования и управления процессами, а также многие другие, не упомянутые или недоступные ранее. Соответственно, промежуточный термин Rapid Board также был исключен, см. Больше не Rapid по названию, но все еще быстрый по своей природе:
В GreenHopper 6.0 новая плата больше не известна как "Rapid Board" - мы полагаем, что все уже знают, что она намного быстрее классических плат. Новая плата была построена с нуля на основе новейших технологий, которые позволяют нам обеспечивать оптимальную производительность и максимально использовать ваше драгоценное время.
Наконец, команда GreenHopper продолжает вносить существенные улучшения почти в двухнедельные точечные выпуски, причем последний из них посвящен одной из немногих потерь, вызванных переходом от классических плат: в версии 6.0.2 снова доступны настраиваемые цвета карт, даже более универсальные, чем у классический вариант, поскольку теперь вы можете основывать раскраску на типе вопроса, приоритете, правопреемнике или даже на собственном JQL-запросе.
Заключение
Наш прежний рабочий процесс, включающий раскраску журналов невыполненных работ (см. " Какой цвет - ваш журнал?"), Теперь полностью перенесен в новый GreenHopper, получив огромное количество значительных новых функций и улучшений на лету и, соответственно, более гибкую и продуктивную команду.
Начальный ответ
Несоответствие между версией и сопротивлением спринта во многих областях JIRA и GreenHopper является хорошо известной проблемой для гибких команд, использующих этот набор инструментов. Мы реализовали различные попытки исправить это тем или иным способом (в основном с помощью иерархий версий, то есть версий продуктов и версий спринтов с родительскими и дочерними отношениями), ни одна из которых не оказалась действительно продуктивной.
Соответственно, относительно устаревшая история Добавление отдельного поля, позволяющего отслеживать спринт и выпускать информацию независимо друг от друга (GHS-945), охватывает эту тему. Несмотря на то, что на сегодняшний день он не решен, GreenHopper в настоящее время подвергается серьезной реструктуризации для решения этой (и связанной с ней) проблемы, и хотя пока еще не завершена, соответствующая функциональность, доступная сегодня, уже (в конечном итоге) относится к вашему варианту использования, см. Статус Atlassian как 28 февраля 2012 г.:
Спринт как отдельное настраиваемое поле теперь доступен в GreenHopper 5.9, однако он используется только Scrum Rapid Board (который можно включить в качестве лабораторной функции на экранах администратора GreenHopper).
Использование этого поля в Rapid Board освобождает поле fixVersion для обычного использования.
Упомянутый Rapid Board и реструктуризация в целом более подробно описаны в "Будущем GreenHopper":
Rapid Board - это новое начало для GreenHopper. Мы создаем его, чтобы воспользоваться преимуществами новейших веб-технологий и предоставить вам, заказчику, отличный опыт для планирования, отслеживания и составления отчетов о ходе ваших гибких проектов и команд.
Rapid Board и связанная с ним функциональность в настоящее время действительно улучшаются очень быстро, то есть команда GreenHopper выполняет итерации быстро и внедряет значительные улучшения в ежемесячные и даже еженедельные точечные выпуски.
Я полностью продан этому подходу, который в основном строит плату на основе универсальной функциональности JQL (см. Расширенный поиск), предоставляя практически полную свободу для сборки идеальной платы для ваших нужд.
Вдобавок ко всему, это решило для нас несоответствие между версией и сопротивлением спринта, поскольку спринты теперь не связаны между собой, и версии можно снова использовать по своему усмотрению, что в свою очередь позволяет получить полезную версию, основанную на дате выпуска, для клиента, столкнувшегося с JIRA Roadmap.
Переход к этому новому подходу, конечно же, требует особых усилий, что в конечном итоге потребует некоторого планирования и времени, также есть некоторые существенные недостатки, касающиеся ранее доступных функциональных возможностей; например, неразрешенная на данный момент история. Как пользователь, я хотел бы настроить карты, отображаемые на быстрой доске (GHS-3922), для нас очень важно, потому что мы использовали инновационный подход Филиппа Крухтена к раскраске отставания (см. Какой цвет ваше отставание?) с большим успехом, и это пока невозможно для Rapid Board.
Наконец, GreenHopper 5.9 требует JIRA 5.0, которая может быть или не быть демонстратором прямо сейчас.
Чтобы продолжить обсуждение этой темы, я хотел отметить расширение для JIRA - Easy Agile Roadmaps. Перетащите эпос в календарь, затем перетащите, чтобы изменить размер эпоса. Вы также можете добавить версии и статические маркеры в дорожную карту, чтобы выделить этапы.
Если вы ищете разную гранулярность по времени (спринты против выпусков / версий) и / или по уровню детализации (изменения набора функций по сравнению с задачами разработки), тогда хорошим подходом будет разделить их на 2 разных проекта и использовать связывание проблем по мере необходимости.
Затем в проекте высокого уровня вы получите хороший обзор для всех заинтересованных сторон и вашего долгосрочного планирования дорожной карты.
Недостатком является необходимость синхронизации двух проектов, в основном, вручную.