Добавить свимлайн на доску jira
Обновлено: 14.05.2024
Как настроить Канбан в Jira для разработки своих продуктов, на примере Meetville
18 сентября 2017 года мы запустили Hygger.io — систему управления проектами для IT-компаний, которая состоит из 4х типов досок: Kanban, Sprint, Backlog и Roadmap. Заходите, регистрируйтесь, изучайте!
В этой заметке я рассказываю к какому финальному процессу разработки в Jira мы пришли в Meetville. Также кратко описываю путь, который мы проделали до дня сегодняшнего. Читатель получит готовый регламент с описанием процесса и правилами разработки. Бери и внедряй, нам не жалко.
Начало
Начиналось все с банального спи с ка issues и фильтрации с помощью JQL (2010 год). Для расстановки приоритетов мы использовали поле priority, которое позволяет разбить приоритеты задач на 5 групп (trivial, minor, major, critical, blocker). Также использовали Agile плагин Jira Agile (раньше он назывался Green Hopper). Задачи внутри группы делались в произвольном порядке. Например, было 10 задач с приоритетом major и программист брал любую задачу, которая имеет приоритет major, но после того, как все задачи с более высшими приоритетами были готовы. На тот момент мы работали в спринтах, поэтому порядок в целом был не важен. Важен был конечный результат, то есть принятые тестировщиком и залитые на продакшн фичи.
Минусы
Но у этого процесса было много минусов. Вот лишь самые основные:
- тестеры проверяли фичу не тогда когда программист ее закончил, а спустя длительное время. Программист успевал забыть эту фичу и тратил много времени на то, чтобы снова погрузиться в задачу. Сейчас, в канбане, тестер проверяет фичу практически сразу после того, как ее сделал программист;
- фичи заливались на production только в конце спринта, примерно раз в месяц/полтора — сейчас мы их заливаем практически сразу после приемки тестировщиком;
- код фичи попадал в мастер с большим опозданием — в итоге приходилось часто разруливать конфликты. Сейчас код попадает в мастер сразу после приемки тестером, то есть достаточно быстро;
- непонятно чем занят программист в настоящий момент — приходилось заниматься постоянным опросом вида “что делаешь?” и раздачей директив вида “после этой задачи делай вот эту”;
- непонятно, в целом, насколько команда была загружена задачами — кто при задаче, а кто филонит;
- программисты не знали чем заняты коллеги;
- программист мог делать сразу несколько задач параллельно, что повышало издержки на переключение контекста;
- приходилось тратить много времени на оценку фич перед стартом спринта, сейчас потребности в оценке нет — когда сделаем фичу, тогда и сделаем;
- срочные задачи по исправлению багов или по доработке фич на продакшне ломали все сроки спринта — сроки постоянно плавали, что приводило к негативу со стороны “внутренних” заказчиков продукта.
Канбан — спасение
В один прекрасный момент я решил попробовать методологию Канбан, которую как раз добавили в плагин Jira Agile (ранее — Green Hopper). И, практически сразу, пропускная способность команды разработки выросла на порядок. Мы стали выпускать намного больше полезностей в единицу времени. Все были довольны: пользователи продукта стали получать в первую очередь более полезные фичи причем намного быстрее. “Внутренние” заказчики перестали давать кнута за срыв сроков и своими глазами увидели как выросла скорость поставки софта.
Плюсы
Вот плюсы, которые мы получили от внедрения Канбана:
+ мы сразу увидели узкие места — в колонке Testing скапливалась большая очередь задач — наш тестировщик не справлялся с проверкой задач. В итоге программисты успевали хорошенько подзабыть задачи, которые им переоткрывал тестировщик спустя неделю или две. Раз забыли, значит надо смотреть код и вспоминать о чем там шла речь. Решение — взяли второго тестировщика. Бинго.
+ менеджер продукта стал точечно управлять порядком выпуска фич. В этом мире бушующем все ж таки порядок имеет значение. Задача по определению приоритетов — одна из самых важных задач для менеджера в Канбане. Требования, как и реальность, постоянно меняются. Какие-то задачи, полежав в очереди, теряют свою значимость и уходят вниз, туда, где их никто никогда не увидит. Какие-то задачи наоборот из грязи в князи — поднимаются наверх. Се ля ви.
+ мы стали делать только то, что реально добавляло ценности продукту. Мы смогли упрятать подальше от программистов тонны бесполезных багов и доработок. С глаз долой из сердца вон. Тестировщики — молодцы, находят баги, но баг Багу рознь. Отличить баг от Бага — задача для человека, который может и учитывает как интересы пользователей продукта, так и интересы бизнеса. Это работа менеджера продукта.
+ программисты перестали тратить свою энергию на выбор следующей задачи — “взять в работу вот этот баг, или вот эту задачу?”. Этот выбор осложнялся тем, что у обоих задач был одинаковый приоритет. Если тебе вернули задачи, то есть переоткрыли в терминах Jira, будь добр взяться за нее сразу после текущей задачи, а не через 2 недели. Теперь эту энергию программист может тратить на бизнес-логику и программирование. И на чтение новостей на reddit.
+ вся картина — на ладони, можно зайти на доску и увидеть кто чем занят, что уже готово к отправке на продакшн. Большие вещи видятся на расстоянии.
+ мы стали более гибкими — мы стали менять требования “на лету”, причем без какого-либо сопротивления со стороны программистов. Раньше программист не хотел делать “левые” задачи, боясь “завалить” сроки по спринту. С Канбаном программист работает как процессор — тактами, один такт — одна задача. Главное — не трогать его внутри такта. Кстати, чем чаще такты, тем гибче команда разработки. Идеальный такт для нашей команды — 8 часов.
Регламент на процесс
Теперь я покажу вам нашу структуру и правила, которые мы соблюдаем в своей команде. По сути это готовый регламент на разработку. Бери и внедряй в своем продукте.
Вот главная и единственная иллюстрация — наша структура в Jira.
Вертикальный приоритет задач
Задачи разбиты на три уровня:
1) Уровень Blockers — выполняются в первую очередь.
2) Tasks and Bugs — выполняются при отсутствии задач в группе Blockers.
3) Someday — выполняются при отсутствии задач в группах Blockers и Tasks and Bugs. То есть — никогда :)
Правила:
- Приоритет и порядок выполнения всем задачам задает менеджер продукта.
- Выполняя задачи на уровнях Tasks and Bugs или Someday, при появлении задачи на уровне Blockers, в комментариях к Block-задаче, разработчик указывает время, через которое он сможет приступить к выполнению. Менеджер отвечает на данный комментарий согласием или не согласием. Если ответ положительный, то разработчик приступает к Block-задаче не позднее оговоренного времени, если же ответ отрицательный, разработчик приступает к Block-задаче немедленно, остановив текущую задачу на другом уровне. Если комментарий от менеджера не получен, то разработчик действует, как если бы получил положительный ответ. Также данный вопрос можно решить в устной форме с менеджером проекта.
- Пока не будут выполнены все задачи на более высоком уровне приоритета, разработчик не имеет права приступать к задачам находящимся на более низком уровне приоритета.
- Задачи внутри уровня выполняются по порядку — сверху вниз.
- Разработчик не имеет права по своему усмотрению менять приоритет задач.
Горизонтальное движение задач
Команда выполняет задачи и проходит все колонки слева направо.
To Do
- В колонке To Do представлены задачи для разработчика, имеющие статус Jira open.
- Разработчик обязан взять одну верхнюю задачу, при отсутствии задачи в Reopened и присвоить ей статус In progress. То есть перенести задачу в колонку In progress.
- За наполнением задач и их порядком в To Do и их приоритетом следит и отвечает менеджер продукта.
- Если задачу вешает один разработчик другому разработчику, то суть задачи, исполнитель и ее статус должны быть согласованы с менеджером продукта.
In Progress
- В колонке In Progress находятся задачи, имеющие статус Jira in progress.
- Если у разработчика в колонке In Progress нет задачи, то это считается простоем.
- У разработчика в In Progress должна быть только одна задача.
- Максимальное число задач в In Progress равно числу разработчиков, если же число задач превысило максимум, колонка выделяется красным цветом, что сигнализирует о нарушении процесса.
- Разработчик должен проверить, не открыл ли он сразу несколько задач, если лишние задачи есть, разработчик обязан оставить только одну задачу.
- Если разработчик выполнил задачу, он обязан выложить ее для тестирование на закрепленный за ним dev-сервер и присвоить задаче статус Resolved, то есть перенести ее в колонку Testing.
In Testing
- Задачи на этом этапе имеют Jira статус Resolved и проходят тестирование на dev-сервере.
- Тестировщики работаю с задачами из данной колонки до 14.00, если отдельно не оговорен порядок тестирования с менеджером продукта, затем тестировщики обязаны переключиться на колонку Deployed.
- Если задача успешно прошла тестирование, ей присваивают Jira статус Closed, то есть переносят в колонку Ready 4 deployment.
- Если задача не прошла тестирование, ей присваивают статус Reopened, то есть переносят в колонку Reopened.
- Если в данной колонке находиться задача, которую вешал одни разработчик другому, то проверить данную задачу согласно пунктам выше должен разработчик, который создал задачу.
- Если в данной колонке находится под-задача, относящаяся к большой, общей задаче, то менеджер продукта обязан спрятать эту подзадачу с доски (мы прячем так — ставим версию Fake version в поле Fix Version, а эта версия была давно зарелижена, поэтому таск исчезает с доски), а в будущем тестировщики будет проверять эту задачу в рамках общей/корневой задачи.
Reopened
- В данной колонке представлены задачи с Jira статусом Reopened и требующие исправления.
- Разработчик не имеет права брать новую задачу из To Do, пока у него есть задачи в Reopened.
Ready 4 Deployment
- В данной колонке представлены задачи имеющие Jira статус Close и требующие заливки на продакшн или же задачи, которые будут включены в финальный билд и залиты в AppStore/Google Play.
Deployed
- В данной колонке представлены задачи, имеющие Jira статус Deployed и залитые на продакшн или же включенные в билд мобильного приложения, который уже отправили на ревью в магазин.
- менеджер продукта обязан включить задачи, относящиеся к мобильным приложениям, в road map .☆ Apps Versions для последующего контроля версий, а далее убрать их с доски, поставив Fake version.
- Также менеджер продукта обязан актуализировать состояние задач на доске Production в Trello, то есть перенести выполненные задачи из колонки Developing в Live. В этот момент все заинтересованные лица получают уведомление о выпуске новой фичи.
- Задачи, не связанные с мобильными приложениями, обязаны быть приняты отделом тестирования на продакшне.
- Если тестировщики приняли задачу, то ей устанавливается Jira статус Accepted.
- Тестировщики работают с данной колонкой после 14.00, если отдельно не оговорен порядок тестирования с менеджером продукта.
- Технические задачи, которые создают разработчики, обязаны быть приняты авторами и им должен быть присвоен статус Accepted.
Accepted — В данной колонке представлены задачи, имеющие Jira статус Accepted, данный статус тестировщики выставляют после проверки данной задачи на продакшне.
- Менеджер продукта переодически очищает, то есть прячет (ставит Fake version) задачи из данной колонки.
Configuring swimlanes
A swimlane is a horizontal categorization of issues in the Active sprints of a Scrum board, or on a Kanban board. You could use swimlanes to help you distinguish tasks from different workstreams, users, application areas, etc.
Before you begin
You must be a Jira administrator or a board administrator for the board to configure its swimlanes.
On this page:
Choosing a different type of swimlane
You can choose to set up your swimlanes in a variety of ways, as shown in the following table.
One JQL query per swimlane (see below for examples). By default, two swimlanes will be created:
- Expedite — this swimlane is based on the following JQL query: priority = Blocker
- Everything Else — this swimlane is always at the bottom of the screen, and cannot be deleted. It acts as a "catch-all" for issues that do not match the JQL of any of the swimlanes above it, hence it has no JQL specified.
You may want to create additional swimlanes that map to other values of your Jira 'Priority' field, or use a different field to categorize your swimlanes.
One epic per swimlane, with issues that don't belong any to epics appearing below the swimlanes.
If you want to change the order of the swimlanes on your board, navigate to the Backlog of the board and drag and drop the epics as desired.
No horizontal categorization of issues in the Active sprints of a Scrum board, or on a Kanban board.
To choose a different type of swimlane:
Go to the desired board, then click Board > Configure.In the Base Swimlanes on drop-down, select either Queries, Stories, Assignees, or No Swimlanes, as described above.
Screenshot: the 'Board Configuration' screen — 'Swimlanes' tab
Modifying your Query-based swimlanes
If your swimlanes are based on JQL queries (rather than on stories or assignees), you can create, delete, or change them:
Click the Swimlanes tab.
If your swimlanes are based on Queries, you can edit your swimlanes, as described below and the screenshot above.
Add a new swimlane
In the blue area, type the Name , JQL , and optional Description , then click the Add button. Your new swimlane is added in the top swimlane position.
Change the name of a swimlane
Click in the Name area of the swimlane, modify the existing name, and click the Update button.
Change the JQL of a swimlane
Click in the JQL area of the swimlane, modify the existing JQL, and click the Update button.
See the examples below for some suggestions. For information on JQL syntax, see JQL (Jira Admin documentation).
Note, the JQL 'ORDER BY' clause is not used by the swimlane, as it defaults to order by rank.
Delete a swimlane
Click the Delete button at the right of the swimlane.
Move a swimlane
Hover over the vertical 'grid' icon, then drag and drop the swimlane up or down to its new position.
Some example JQL queries for your swimlanes:
Show all issues that belong to a particular component, e.g. 'User Interface':
Show all issues that are due in the next 24 hours:
Show all issues that have a particular priority, e.g.:
Next steps
Need help? If you can't find the answer you need in our documentation, we have other resources available to help you. See Getting help.
Configuring swimlanes
A swimlane is a horizontal categorization of issues in the Active sprints of a Scrum board, or on a Kanban board. You could use swimlanes to help you distinguish tasks from different workstreams, users, application areas, etc.
Before you begin
You must be a Jira administrator or a board administrator for the board to configure its swimlanes.
On this page:
Choosing a different type of swimlane
You can choose to set up your swimlanes in a variety of ways, as shown in the following table.
One JQL query per swimlane (see below for examples). By default, two swimlanes will be created:
- Expedite — this swimlane is based on the following JQL query: priority = Blocker
- Everything Else — this swimlane is always at the bottom of the screen, and cannot be deleted. It acts as a "catch-all" for issues that do not match the JQL of any of the swimlanes above it, hence it has no JQL specified.
You may want to create additional swimlanes that map to other values of your Jira 'Priority' field, or use a different field to categorize your swimlanes.
One epic per swimlane, with issues that don't belong any to epics appearing below the swimlanes.
If you want to change the order of the swimlanes on your board, navigate to the Backlog of the board and drag and drop the epics as desired.
No horizontal categorization of issues in the Active sprints of a Scrum board, or on a Kanban board.
To choose a different type of swimlane:
Go to the desired board, then click Board > Configure.In the Base Swimlanes on drop-down, select either Queries, Stories, Assignees, or No Swimlanes, as described above.
Screenshot: the 'Board Configuration' screen — 'Swimlanes' tab
Modifying your Query-based swimlanes
If your swimlanes are based on JQL queries (rather than on stories or assignees), you can create, delete, or change them:
Click the Swimlanes tab.
If your swimlanes are based on Queries, you can edit your swimlanes, as described below and the screenshot above.
Add a new swimlane
In the blue area, type the Name , JQL , and optional Description , then click the Add button. Your new swimlane is added in the top swimlane position.
Change the name of a swimlane
Click in the Name area of the swimlane, modify the existing name, and click the Update button.
Change the JQL of a swimlane
Click in the JQL area of the swimlane, modify the existing JQL, and click the Update button.
See the examples below for some suggestions. For information on JQL syntax, see JQL (Jira Admin documentation).
Note, the JQL 'ORDER BY' clause is not used by the swimlane, as it defaults to order by rank.
Delete a swimlane
Click the Delete button at the right of the swimlane.
Move a swimlane
Hover over the vertical 'grid' icon, then drag and drop the swimlane up or down to its new position.
Some example JQL queries for your swimlanes:
Show all issues that belong to a particular component, e.g. 'User Interface':
Show all issues that are due in the next 24 hours:
Show all issues that have a particular priority, e.g.:
Next steps
Need help? If you can't find the answer you need in our documentation, we have other resources available to help you. See Getting help.
5 шагов к Agile с инструментами JIRA
Екатерина Базылева, менеджер a1qa, сертифицированный Scrum-мастер и SAFe Agilist, рассказывает об инструментах JIRA, которые позволяют планировать Agile-проекты, управлять ими и отслеживать эффективность работы команды.
Как инструменты JIRA помогают выполнить работу по гибким методологиям?
Под «работой» подразумевается любая рабочая задача: написание тестовой документации, составление плана по тестированию, проведение регрессионного теста или подготовка обучающего мероприятия в центре компетенции.
В первую очередь эта статья будет полезна тем, кто:
- Постоянно «жонглирует» большим количеством задач на одном или нескольких проектах.
- Хочет предложить заказчику или команде реализовать Scrum или Kanban на базе JIRA, но ещё не имеет полного представления о том, как это сделать.
- Уже работает с JIRA Agile Plugin или имеет о нём общее представление, но хочет расширить свои знания.
Начнём. У каждого менеджера проекта есть to-do list из рабочих задач и, возможно, даже не один. У кого-то список состоит из множества мелких задач одного проекта, у кого-то включает несколько проектов.
Нередко выполнение задач зависает, при этом к ним постоянно добавляются новые. Мы периодически перебираем этот список и верим, что вот завтра, хотя нет, лучше в понедельник начнём разбирать его. Знакомо?
Продуктивно решать все возникающие задачи – это один из постулатов работы по гибким методологиям. Однако не стоит ждать, когда к вам придёт проект, который должен быть выполнен по Agile. Возьмите свой текущий проект и сами реализуйте его с соблюдением Agile-принципов.
Для этого достаточно выполнить 5 шагов.
Создайте борд (Jira-Agile-Getting Started), на котором вы будете отслеживать ход выполнения задач и управлять ими в бэклоге. Борд можно сделать как для задач конкретного проекта, так и для выборки, в которую будут входить несколько проектов.
Вот так выглядит Agile Board по умолчанию:
Теперь настроим его под себя.
Настраиваем колонки (Columns). Они будут отражать жизненный цикл задач. При этом можно настроить произвольное количество колонок и дать им свои названия.
На борд можно добавить дорожки (Swimlanes), которые помогут структурировать задачи. Среди доступных вариантов можно выбрать дорожки по группе задач (Epics), по исполнителю (Assignee) или по задачам (Stories). Последний вариант особенно удобен, если активно используются подзадачи. Также дорожки можно настроить по собственным фильтрам (или вовсе обойтись без них).
Для того чтобы скрыть или, наоборот, показать специфические задачи, можно добавить быстрые фильтры (Quick Filters) и, например, отфильтровать только задачи на обновление тестовой документации или задачи конкретного QA-инженера. Фильтры задаются через JQL-запросы.
В конце нужно определиться, в каких единицах будут оцениваться задачи. Самые распространённые варианты – это стори-поинты (Story Points) и часы, но могут быть и другие единицы, предлагаемые JIRA.
После того как Agile Board создан в режиме «Планирование» или в бэклоге (это зависит от версии JIRA), нам становится доступен удобный интерфейс для превращения хаотичного списка задач в упорядоченный бэклог.
- В каждом из проектов создаём группы задач (Epics), которые будут отражать основные направления деятельности. Например, усовершенствование процессов, обновление тестовой документации, регрессионные тесты.
- Можно также обозначить и релизы, т. е. сроки, к которым надо что-то завершить.
- Сами задачи из to-do list станут пользовательскими историями (user stories), связанными с направлением работы и при необходимости привязанными к релизу.
Теперь все задачи находятся в одном месте, их легко оценивать и располагать по приоритету, передвигая вверх и вниз.
Итак, мы создали и настроили Agile Board в JIRA и составили бэклог с задачами. Что же дальше?
Когда список задач большой, лучшее, что можно сделать, – выбрать несколько самых приоритетных и выполнить их. Давайте запланируем первый спринт.
- Определяем продолжительность спринта. Решите, будет ли это неделя, две недели, месяц или другой период времени.
- Считаем емкость (Capacity) команды на спринт.
Capacity – объем работы, который команда может сделать в течение спринта. Эта цифра учитывает доступность людей, а также тот факт, что люди будут работать над задачами спринта не всё своё время. Часть времени будет уходить на коммуникацию внутри команды и другие активности.
Например:
Размер команды – 2 специалиста, занятых полный рабочий день.
Продолжительность спринта – 2 недели.
Общее количество рабочих часов – 160. При этом мы знаем, что одному из инженеров нужно пройти тренинг по веб-сервисам (16 часов) и на коммуникацию по задачам у команды уходит 20% рабочего времени.
Итого, capacity на спринтовые задачи получится (160-16)*0,8=115,2 ч.
- Исходя из емкости команды, набираем задачи в бэклог.
- Задаем даты спринта в соответствии с выбранной продолжительностью и стартуем.
Настало время выполнить набранные задачи, т. е. завершить спринт.
На шаге 1 мы создавали и настраивали Agile Board. Теперь он поможет нам проследить, на каком этапе находится каждая из задач, кто и какую задачу выполняет.
Можно сразу назначить каждой задаче исполнителя. Если ваша команда достаточно самоорганизованная, то ребята могут сами брать себе задачу из списка свободных. Как только пользователь передвигает задачу в In Progress, он автоматически становится ее исполнителем.
Если вы регулярно логируете время и обновляете Remaining Time, то сможете использовать график сгорания, или график хода выполнения работ (Burndown Chart). Он покажет ваш прогресс по отношению к цели спринта и поможет оценить шансы на его успешное завершение.
Серая линия на графике показывает идеальный ход выполнения проекта.
Красная линия – объём незакрытых задач, зелёная – потраченное время. Если красная линия справа снизу встречается с серой в одной и той же точке – это лучший вариант развития событий.
На примере выше у команды явно есть проблемы: объем выполненной работы заметно меньше запланированного. Если они не ускорятся в последние дни спринта, то не успеют завершить все запланированные задачи в срок.
Эта же команда идет с опережением, и ей стоит подыскать себе дополнительные задачи, если положительный тренд сохранится.
Поэтому после нажатия на кнопку End Sprint стоит потратить немного времени, чтобы посмотреть, как всё прошло, т. е. провести ретроспективу.
И не расстраивайтесь, если первый спринт у вас будет «комом».
Ретроспектива: на что обратить внимание?
- Отчет по спринту покажет: какие задачи вы смогли завершить, а какие нет; добавили ли вы дополнительные задачи в спринт или, наоборот, что-то из него исключили, потому что поняли, что не справитесь.
- Анализируем график хода выполнения работ. Если в рамках спринта не удалось закрыть все запланированные задачи, разбираемся, что и в какой момент времени пошло не так.
- Если в качестве группы задач (Epics) вы использовали крупные задачи, например «Провести регрессию всего приложения на уровне МАТ», то отчёт покажет, сколько работы вам ещё осталось. Похожую картинку можно получить и в контексте релиза, если все ваши задачи привязаны к какой-то версии.
- И наконец, можно оценить велосити (Velocity) и посмотреть, сколько работы вы планировали, а сколько в итоге получилось выполнить. Эта информация будет более полезна в случае, если вы оцениваете пользовательские истории в стори поинтах.
Velocity – это скорость работы команды, тот объём, который команда может завершить за спринт. Завершить – это значит закрыть задачу и переместить ее в колонку Done.
Вот мы и выполнили последний шаг нашего Agile-проекта.
Как видите, 5 шагов к Agile действительно просты. Давайте ещё раз их перечислим:
- Создать и сконфигурировать Agile Board.
- Упорядочить задачи в бэклоге.
- Запланировать спринт.
- Выполнить спринт.
- Провести ретроспективу.
На первый взгляд JIRA кажется сложной, но полученная польза однозначно стоит потраченных усилий и времени.
В следующей статье рассмотрим несколько интересных профессиональных «фишек» работы в JIRA.
Простая Kanban-доска для Jira
Здесь я расскажу, как сделать канбан-доску для проекта в Jira, пользуясь только QML и JavaScript. С небольшими доработками вместо Jira вы можете использовать любой другой трекер, имеющий REST API.
Содержание
Предыстория
Некоторое время назад, теперь уже практически в другой жизни, в мою бытность руководителем проекта, я понял, что теряю представление о занятости участников нашего проекта. Кто-то занимается Большим и Важным делом, кто-то исправляет срочные баги, а может быть кто-то, извините, балду пинает, а я об этом не в курсе и задачи ему не ставлю. И мне захотелось иметь наглядную картинку текущих дел.
Если у вашей организации уже диагностировали kanban в хронической стадии и вы тяготеете ко всему натуральному и осязаемому, то, скорее всего, ваша доска выглядит вроде этой, и у нее тоже есть разделение по этапам процесса:
В моем случае такой вариант не прокатил бы по нескольким причинам.
Во-первых, вся команда, за исключением пары человек, находилась в другом городе, а устраивать видеомитинги мне не казалось рациональным.
Во-вторых, у меня есть стойкое отвращение ко всякому ручному труду и вручную нацеплять бумажки на доску (а больше было некому, см. предыдущий пункт), отслеживать движение задач в трекере и соответственно передвигать бумажки на доске мне претило. Можно было нарисовать карточки в компьютере, в Excel или в Trello, но следить за задачами и передвигать карточки опять пришлось бы самостоятельно.
В-третьих, и самое главное, глядя на эту доску, можно видеть общее состояние дел, находить узкие места на участках конвейера по производству ПО, но в ней совершенно не видно людей и их загрузки.
Поэтому мне нужна была доска:
а) электронная
б) связанная с трекером, т.е. отражающую текущую ситуацию
в) и чтобы столбец на доске соответствовал конкретному человеку
Короче говоря, эту задачу я на тот момент решил, сделал представление на web-страничке. Но о ней ничего вам не расскажу — и трекер тот (PVCS Tracker) не слишком распространен, API у него на dll, да и код странички сейчас не найти.
А сейчас я решил повторить упражнение, взяв в качестве инструментария QML. Выбор объясняется просто — мне он чуть более знаком, чем веб-технологии, и я знаю, как встроить получившийся модуль в свой инструмент, написанный на Python и PyQt.
Альтернативы для умных и богатых
Да, я знаю, что для Jira существует энное количество плагинов, в которых есть Kanban-доска — поиск в marketplace по слову «kanban» находит 33 варианта.
Но использовать плагин означает, что нужно выбить у руководства его покупку по цене соответствующей числу всех пользователей на Jira, договориться с админами, что они поставят его на сервере и будут поддерживать, и… невозможность его кастомизации под мои нужды, т.к. плагин будет общим для всех. А мне хотелось иметь инструмент, который можно использовать независимо от того, установлено что-то на сервере или нет, и менять, ни на кого не оглядываясь.
Необходимые оговорки
Чтобы не утяжелять статью, здесь не будет сказано о том, как сделать:
— авторизацию в Jira
— операции над карточками в QML с передачей вызова в JIRA — редактирование, смена статусов и исполнителей путем drag&drop и т.п.
— работа с фильтрами Jira
Если что-то из этого вам действительно интересно — отпишите об этом в комментариях. Не буду обещать, что немедленно сделаю и распишу в деталях, но, как сказал nmivan, «поставлю в план».
Терминология еще не устоялась, так issue в одних компаниях называют запросом, в других задачей, еще бывают тикеты и заявки. Для сущности filter, которым в Jira отбирают issues, тоже есть куча названий — фильтр, запрос, выборка, список.
Я буду использовать терминологию, принятую в локализованной Jira: issue буду называть запросом, а filter — списком.
Начало работы с Jira REST API
Типичный адрес запроса в веб-интерфейсе Jira выглядит так:
Берем протокол и имя хоста, то есть с начала адреса до browse , дописываем к нему rest/api/2/ — и у нас получается базовая часть адреса REST API
Полное описание Jira REST API на сайте Atlassian. Там много всяких функций, которых с каждой версией становится все больше, но реально требуется знать лишь небольшое количество методов:
Пример ПримерПока хватит на первое время.
Поскольку мы ничего менять и редактировать пока не собираемся, то работать будем анонимно, с запросами на сервере Jira в Atlassian, в проекте «JIRA Server (including JIRA Core)», то есть, фигурально выражаясь, в Самом Главном Проекте Jira. Тем более, что там тоже есть наши люди:
Сохраните его под другим именем. C полученным файлом удобнее работать, находить в нем нужные поля и смотреть, в какой структуре находится нужное значение. Оригинальный файл нам пригодится в качестве тестового источника, чтобы лишний раз не ходить на сервер Atlassian.
Имеет смысл также получить список всех полей через запрос rest/api/2/field , чтобы определять, под каким идентификатором числится нужное вам поле.
Создаем проект в Qt Creator
Для создания проекта в Qt Creator воспользуемся стандартным шаблоном «Qt Quick Control Application».
Получится проект, состоящий из main.cpp и main.qml в файле ресурсов qml.qrc.
Их мы трогать пока не будем, займемся более насущными проблемами.
Рисуем дизайн карточки с запросом
Создаем новый файл IssueCard.qml, визард по умолчанию закинет его в файл ресурсов.
Дизайн карточки, которой будет отображаться запрос, я сначала по быстрому накидал в режиме дизайнера Qt Creator, затем доработал QML вручную.
Кстати, дизайнер QML относительно неплох, особенно по сравнению с первой версией. Наглядно показывается и легко меняется binding положения элементов, автоматом подтягивает компоненты из других qml-файлов в проекте. Почти не падал — всего два раза валил QtCreator, когда я пытался задать градиент (ничего страшного не случилось — автосохранение работает), и еще не смог пережевать DelegateModel — наверное, среду стоило обновить. У дизайнера QML, как и у дизайнера Qt Widgets, есть функция предпросмотра:
В результате получился QML карточки с запросом, файл IssueCard.qml
Для заполнения карточки по запросу добавим новое свойство (property) issue. Свойство даст нам возможность передавать в карточку запрос со всем его содержимым извне за одно присвоение.
И в сигнале на его изменение напишем код, разбирающий значения и распихивающий их по нужным визуальным компонентам.
Как видите, здесь я часто использую функцию JS.getValue, я ее написал для упрощения выборки значения из сложной структуры JSON (если оно там есть), хотя сама функция довольно проста:
Функция лежит в файле methods.js, подключенном в начале IssueCard.qml
Описываем колонку карточек
Теперь нужно карточки организовать в прокручиваемую по вертикали колонку. Прокрутка очень удобна, когда карточек много. Для прокрутки нужен ListView. Среди примеров, идущих в комплекте с Qt есть пример «QML Dynamic View Ordering Tutorial 3 — Moving Dragged Items», в нём dynamicview.qml — это практически то, что нам нужно, копируем его в проект под именем KanbanColumn.qml.
Только нужно сделать пару доработок
1) Добавить к колонке заголовок и сделать у объекта верхнего уровня свойство, чтобы присваивать название колонки извне.
2) Так как карточка запроса у нас теперь отдельный цельный объект, то заменяем вывод, сделанный в примере через Column и несколько Text, на наш IssueCard
С колонкой дизайнер нам не поможет, потому что он не переваривает DelegateModel. С другой стороны, нам не особо он и нужен, всё можно сделать вручную.
Окно для доски
Теперь нужно собрать колонку в общее окно. Создаем файл KanbanWindow.qml, в нем дизайнером размещаем нужные поля.
В простейшем виде получается так:
В ListView надо указать, в свойстве delegate , что элементы модели будут показываться в виде колонок KanbanColumn, в каждую из которых надо передать список запросов, назовем его issueList . Также создадим пустую модель и тоже дадим ей имя model .
Выше я еще создал свойство mainModel — оно нам послужит для временного хранения данных.
И не забыть вставить KanbanWindow в окно приложения:
Пишем код для вызова REST API
Самое время сделать код, который будет получать список запросов из Jira и заполнять модели в QML.
Функция запрашивает с сервера (или из локального файла) список запросов, парсит json из ответа, группирует запросы по исполнителям и заполняет модель в QML.
Подключаем функцию к кнопке
И проверяем работу:
В принципе, доска готова. Далее можно заниматься ее улучшениями и развитием.
LocalStorage для сохранения и восстановления параметров
Чтобы не вводить каждый раз URL к серверу Jira, стоит сохранять введенную строку и восстанавливать ее при запуске. И да, QML умеет в LocalStorage.
Напишем функции чтения и сохранения параметров.
Добавим вызов сохранения параметров…
… и их восстановление при создании KanbanWindow
Добавляем варианты группировки
Сделав группировку по исполнителям, логично сделать возможность выбора и других вариантов группировки — по статусу, по приоритету и так далее. Так появилась панелька параметров группировки KanbanParams.qml.
Как видите, здесь ComboBox содержит модель с возможными вариантами группировки, и в каждом элементе прописан путь в JSON к значению, которое будет использоваться для определения группы. Таким образом количество вариантов группировок по желанию можно расширить.
На верхнем уровне определены свойства, два из которых — алиасы к внутренним значениям. Алиасы нужны, чтобы можно было присвоить нужное значение, начитанное из LocalStorage. Что же касается свойства groupValuePath:
то оно просто возвращает путь к значению для текущего варианта группировки.
Вставляем KanbanParams в KanbanWindow и у нас получается такое окошко:
Я не буду подробно расписывать, как обрабатываются параметры, потому что мне надоело писать эту статью, смотрите в коде.
Что дальше?
Получившейся доской уже можно пользоваться для просмотра текущей ситуации с запросами, но можно ее улучшить:
Общие спринты в Atlassian Jira Software
В этой статье я хотел бы поговорить об Общих Спринтах (Shared Sprints) в Atlassian Jira Software.
Если почитать официальную документацию, например, вот тут, то там не будет такого понятия как общий спринт.
Впервые я встретил термин общий спринт вот тут. В этой статье хорошо рассказано, что такое общие спринты и как с ними жить.
Общие спринты — это важное понятие в Atlassian Jira Software, потому что знакомство с общими спринтами происходит, как правило, неожиданно, и кажется, что что-то пошло не так. Но это не так, и, если знать, как общие спринты работают, то можно их использовать для своих нужд.
В этой статье я покажу на примерах как выглядят общие спринты, и как их отличить от обычных спринтов. А также расскажу про их особенности.
Все примеры в этой статье я пробовал в Jira Software Cloud и в Jira Software Server 7.12.3.
Что такое общий спринт?
Общий спринт — это спринт, который виден на более, чем одной доске.
Например, есть вот такие скриншоты досок:
SCRUM Board:
SCRUM2 Board:
Можно увидеть, что на досках SCRUM и SCRUM2 есть спринт с названием SCRUM Sprint 3. Этот спринт виден на двух досках. Значит ли что мы видим общий спринт? Нет. В Jira Software может быть два разных спринта с одинаковым наименованием.
Как увидеть ид спринта?
Для того, чтобы понять общий ли спринт перед нами или обычный, мы должны посмотреть ид этих двух спринтов.
Посмотреть ид спринтов можно вот так:
Если навести мышку на кнопку, выделенную на рисунке выше красным, то мы увидим url, который будет оканчиваться на sprintId=<число>. Это число и есть ид спринта. В нашем случае ид у двух спринтов разные, что означает, что перед нами не общий спринт, а два обычных спринта.
Общий спринт
Теперь давайте посмотрим вот на этот скриншот:
На скриншоте мы видим доску SCRUM, на которой есть два спринта с одинаковым наименованием. И спринт, выделенный красным содержит такой же тикет, как и спринт на доске SCRUM2. Если мы проверим ид этого спринта на доске SCRUM и SCRUM2, то ид совпадут, а значит, что перед нами общий спринт.
Почему у нас один и тот же спринт на двух досках?
Тикеты, которые видны на доске, выбираются фильтрами, которые определены для досок. Фильтры можно посмотреть, если перейти в меню Board Settings -> General. Вот так выглядят фильтры для досок:
SCRUM board:
project = SCRUM OR priority is not EMPTY ORDER BY Rank ASC
SCRUM2 board:
project = SCRUM2 ORDER BY Rank ASC
Мы видим, что фильтр для SCRUM выбирает не только тикеты из проекта SCRUM, но и все тикеты в нашем инстансе Jira, у которых заполнен приоритет, а значит он выбирает и тикеты из проекта SCRUM2. Поэтому тикеты из проекта SCRUM2 видны и на доске SCRUM, и на доске SCRUM2. И поэтому если мы заполним поле Sprint в одном из тикетов, этот спринт появится на двух досках.
Спринт создается из доски и содержит ссылку на доску, из которой он создан. Для этого можно выполнить, например, rest/agile/1.0/sprint/sprintId и увидеть доску, из который спринт был создан. В нашем случае мы получим вот такой результат:
originBoardId = 3, а это доска SCRUM2. Это означает, что спринт изначально был создан на доске SCRUM2, а на доске SCRUM он появился потому, что тикет из спринта есть как на доске SCRUM2, так и на доске SCRUM.
Как себя ведут общие спринты?
Если внести какие-то изменения в общий спринт на любой из досок, на которой спринт виден, то изменения будут видны на всех досках.
Например, если мы переименуем спринт на доске SCRUM, то он переименуется и на доске SCRUM2. Если мы закроем спринт на доске SCRUM, то он и закроется на доске SCRUM.
Именно это поведение обычно встречают пользователи. Они работают со спринтом и вдруг спринт закрывается. Никто из команды его не закрывал. В результате оказывается, что спринт был закрыт из другой доски, у которой фильтр выбирает тикеты из этого проекта.
Как можно использовать общие спринты?
Допустим у нас есть несколько команд, и у каждой команды есть свой проект. Каждая команда создает доску и работает на этой доске. Мы хотим увидеть спринты всех команд. Как мы это можем сделать?
Читайте также: