Рейтинг: 5.0/5.0 (1923 проголосовавших)Категория: Инструкции
Я продолжаю рассказ об JIRA. Управление процессом разработки ПО, ведение журнала пожеланий, задач, обнаруженных багов – все это сфера применения JIRA. В прошлый раз я показал, как установить JIRA у себя на компьютере, рассказал о политике безопасности. Теперь самое время создать проект, разобраться в его составляющих, попробовать пройтись по шагам Жизненного Цикла.
Для создания проекта вам нужно войти в JIRA от имени администратора, затем перейти на закладку “ADMINISTRATION”, затем по ссылке “Add Project”. В появившемся окне вам нужно указать основные характеристики проекта: Name (Название проекта), здесь можно указать произвольный текст на русском языке. Затем идет Key(Код проекта) - это несколько букв на английском, например, для проекта калькулятор, его код может быть равен CALC. Если у вас есть уже подготовленная документация по проекту (его описание, Т.З.), то в графе URL вы указываете адрес сайта, где эта документация опубликована. Следующий шаг – указание Project Lead – ведущего разработчика проекта (в качестве project lead не может выступать пользователь не входящий в состав группы jira-developers или jira-administrators). Затем идет Default Assignee – по-умолчанию это тот же человек что и Project Lead. Т.к. проект в основе своей состоит из некоторого количества задач, то Default Assignee – это тот человек, который будет отвечать за выполнение каждой из поставленных задач (естественно, что в последующем он сможет делегировать свои обязанности кому-нибудь другому). Следующий параметр, который нужно указать при создании проекта – это Description (описание проекта). Затем идет Notification Scheme - это правила, по которым при изменении проекта (добавление новой задачи, завершение работы над ней) будут посылаться извещения пользователям JIRA. Также нужно указать схему прав доступа (Permission Scheme), она определяет, какой пользователь и что может делать в JIRA с этим проектом (подробнее о политике безопасности и схемах я писал в прошлой статье). Последняя характеристика проекта - Issue Security Scheme (схема безопасности для каждой из задач). Это специфическая функция только для версии JIRA Enterprise. Идея в том, что пользователи/группы/роли проекта делятся на уровни безопасности, затем при добавлении в JIRA новой задачи ей будет назначен некоторый уровень защиты. По-сути, Issue Security Scheme – неплохой способ защитить информацию, если организация разместила JIRA не в локальной сети, а в internet, так чтобы пользователи некоторого продукта могли добавлять свои пожелания, сообщать об выявленных ошибках. Важно, что одновременно эту установку JIRA используют и в самой организации, а значит что не все задачи проекта (те которые создают разработчики внутри самой организации) должны быть доступны для обычных пользователей internet. Пример того, как выглядит карточка проекта, показан на рис. 1.
На этой карточке находится несколько полезных ссылок для “донастройки” проекта. Прежде всего, Project Category – создаваемые проекты можно группировать по категориям. Создать категорию можно на закладке “ADMINISTRATION”, раздел “Project categories”. В дальнейшем, если перейти на закладку “BROWSE PROJECTS”, то увидите список проектов, сгруппированный по назначенным им категориям. Следующая опция в карточке проекта - CVS Modules, она служит для интеграции JIRA с системой управления версиями файлов (изначально в JIRA встроен модуль CVS, однако есть плагины для интеграции с SVN, Perforce). Следующая опция проекта – Workflow Scheme, ее назначение – настроить этапы, через которые может проходить решаемая задача (подробнее об Workflow Scheme чуть позже). Каждая задача, из которых состоит проект, имеет набор характеристик, например, название, категория (ошибка, или новая функциональность) …, таких характеристик (в терминологии JIRA полей) много. Но не все ситуации можно заранее предусмотреть и возможно для некоторого проекта вам потребуется, чтобы к каждому из заданий было добавлено еще одно поле характеристики (например, признак того, что задание должно быть выполнено только в полночь пятницы 13 числа). Так вот подобная фунциональность обеспечивается с помощью Field Configuration Scheme. Помните только, что поведение JIRA зависят от того какая у вас версия: Standard, Professional, Enterprise (в младших версиях количество доступных функций меньше).
Создав проект, мы должны наполнить его содержимым, но до создания задач необходимо разбить проект на компоненты и указать версии. Компоненты это части проекта, например, проект графического редактора будет условно состоять из модуля загрузки/сохранения, модуля печати, модуля рисования. Чтобы создать компонент вы на закладке “ADMINISTRATION” переходите по ссылке “Projects”, затем в таблице с перечнем проектов, вы выбираете проект, для которого хотите отредактировать его карточку и внизу карточки находится перечень компонент. Для добавления компонента используйте ссылку “Add a new component”,
затем вы указываете название компонента, примечание к нему, а также выбираете кто из разработчиков будет за него отвечать (Lead). Создав несколько компонент? вы может выполнить донастройку проекта, и для каждого из компонентов указать лицо, которое будет играть роль Default Assignees (лицо ответственно за выполнение задачи добавленной в проект или его компоненту), для этого используйте ссылку “Select assignees for components”.
Проект не статическое образование, он развивается во времени, поэтому было введено понятие версий (редактировать версии нужно здесь же, в карточке проекта). При добавлении версии указывается, собственно, ее номер (возможно указать не только цифры, но и более сложные комбинации, например, 1.1.2, или кодовое название Chicago). Кроме номера версии, нужно указать планируемую дату завершения работ над версией (Release Date) и некоторый текст примечания к версии. Если вы будете добавлять вторую и последующие версии, то добавится еще одно поле Schedule, в нем нужно указать номер версии предшествующей добавляемой. Создав версии ими можно управлять, например, менять статус, с Release на Unrelease (версия вышла или в стадии разработки), выполнять слияние версий (в ходе этого выполняется перенос всех запланированных для этой версии задач в другую версию). В случае удаления версии, вас спросят, что делать с задачами назначенными для нее: следует ли эти задачи аннулировать или перенести в другую версию проекта?
Завершив создание проекта самое время перейти к наполнению его задачами. Для этого не обязательно быть администратором проекта: создавать задачи может и пользователь, включенный только в группу jira-users, однако для того, чтобы редактировать задачи, перемещать их … нужно входить в группу jira-developers. Итак: после регистрации, вы заходите на закладку “CREATE NEW ISSUE”, затем выбираете в падающем списке проект для которого хотите добавить задание, и тип задания. Среди предопределенных типов работы Bug, New Feature, Task, Improvement. Этот перечень не фиксированный, и его можно изменить, если в режиме администрирования перейти по ссылке “Issue Types”. Возвращаясь к созданию задачи, давайте выберем тип добавляемой задачи как “Task”, затем мы попадаем на форму где нужно указать для задачи все ее свойства. Прежде всего, Summary (название задачи), Priority (степень важности задачи). Она может варьироваться в диапазонах Trivial, Minor, Major, Critical, Blocker, соответственно, от минимальной важности до наивысшей и даже критической, такой, что до решения задачи дальнейшая работа над проектом нецелесообразна. Список приоритетов не является фиксированной величиной и его можно изменять (правда мне это ни разу не потребовалось, но все же). Итак, для редактирования перечня приоритетов в режиме администратора зайдите на страницу “Priorities”. Возвращаясь к созданию задачи, теперь нужно указать перечень компонентов проекта, к которым привязана добавляемая задача (можно выбрать несколько компонентов). Графа “Affects Versions” служит для выбора тех версий проекта, к которым будет привязана создаваемая задача. А поле “Fix Versions” указывает то, для каких версий данная функциональность уже реализована. К каждой задаче привязан срок ее завершения (поле Due date в карточке задачи). Для детального описания задачи используется поле “Description” (в тексте можно использовать ссылки вида http://site.ru, они автоматически будут преобразованы в теги “a”). Поле Environment должно содержать информацию об окружении (операционная система и ее версия, тип браузера) для которого актуальная задача. Наконец, мы можем указать кто (какой разработчик) будет ответственным за выполнение задачи и планируемые затраты на выполнение работы.
Завершив создание задачи, мы можем ее редактировать (см. рис. 3, панель слева).
JIRA – замечательный инструмент: она ведет учет всех правок выполненных над задачей. К примеру, если я хочу добавить к списку операционных систем еще одну, то нажав на ссылку “Edit”, ввожу новое значение в графу “Environment” и должен указать текст примечания к выполненной мною правке. Затем, вернувшись назад, в режим просмотра задачи я вижу под карточкой задачи перечисление всех правок, которые я выполнил (старое значение свойства и новое значение свойства), также вижу примечания к выполненным правкам. К задаче можно приложить файлы: ссылка “Attach file” служит для того, чтобы загрузить с вашего компьютера файл на сервер, а ссылка “Attach Screenshot” пригодится, если вы хотите приложить к задаче пример скриншота (например, вы тестер, нашли ошибку сделали скриншот, но не сохраняете файл с картинкой на диск а хотите чтобы на сервера сразу же отправилось содержимое буфера обмена). Задачу можно перемещать (ссылка Move) в другой проект. Также за задачу можно голосовать. Например, компания adobe создала общедоступную JIRA инсталляцию в internet, так чтобы пользователи продуктов adobe могли участвовать в их разработке. Но очевидно, что если некто, Вася добавил пожелание “чтобы в photoshop была большая красная кнопка”, то не факт что эта функция нужна всем. А если разрешить голосование за задачу, то можно определить степень заинтересованности в этой функции у других пользователей. Функция Watching служит для подписки, так чтобы пользователю отправлялись сообщения об изменениях в состоянии задачи. Возможно, что решение некоторой задачи достаточно сложно и поэтому имеет смысл ее разбить на отдельные шаги (подзадания). Вообще-то, такая функциональность в JIRA по-умолчанию отключена, но это можно исправить в режиме администрирования, меню “Sub-tasks”, затем ссылка “Enable sub-tasks”. Теперь можно вернуться назад в режим добавления задачи, добавим новую задачу, например, рисование геометрических фигур, и теперь мы хотим ее детализировать, выделить подзадачи: рисование линий, прямоугольников, кругов. Для этого я перехожу в режим редактирования задачи “рисование фигур” и вижу что в расположенной слева панели инструментов добавились кнопки “Create Sub-task” и “Convert to Sub-task”. Т.е. мы можем добавить к текущей задаче под-задачу или превратить текущую задачу как составную часть чего-то другого. Как будет выглядеть карточка задачи с подзадачами показано на рис. 4.
Теперь пора разобраться с понятием Workflow. После создания задачи (отчета об обнаруженной ошибке) мы начинаем работу над ее реализацией (исправлением). Если задача не тривиальна, то на это требуется время, требуется участие других специалистов (например, тестеров) и не факт, что мы с первого раза решим поставленную задачу. Поэтому было введено понятие Workflow, т.е. это набор этапов, через которые проходит задача. Также Workflow - это набор правил перехода между этими состояниями. Это еще и набор действий, которые выполняются в ходе перехода, условий которые могут быть наложены на состояние и переход. В различных версиях JIRA (Standard, Professional, Enterprise) работа с Workflow выполняется по-разному, например, в старших версиях можно создавать собственный Workflow, и даже можно сделать так, чтобы задача одновременно проходила по нескольким Workflow одновременно. Сначала я приведу диаграмму (я взял ее в справке JIRA), где показаны состояния и переходы, реализованные в Workflow по-умолчанию (см. рис. 5).
Сразу после создания задачи ей назначается статус OPENED (открыта и подлежит решению). Затем некто Вася, приходит утром на работу, смотрит то, какие ему были назначены задания, выбирает одно из них и погружается в работу. Для того чтобы злобный босс не кричал на Васю, чем же он занимается, Вася ставит задаче статус IN_PROGRESS (задача в разработке). Вечером Вася завершает работу и поставив для задачи статус RESOLVED (задача был решена) с чувством выполненного долга уходит домой. Однако, следующим утром когда Вася обнаруживает что за ночь тестеры проверили Васину работу и нашли массу недоделок, поэтому они перевели задачу из состояния RESOLVED в состояние REOPENED (открыта повторно). Так что Васе приходится исправлять свои ошибки и снова рапортовать RESOLVED. Только после того как задача была проверена и все ошибки исправлены, ей меняется статус на CLOSED (задач завершена). Если вы вернетесь в карточку задачи, то обратите внимание на набор ссылок помещенных в группу “Available Workflow Actions”, там будут перечислены те действия, которые можно выполнить над текущим состоянием задания. Каждый раз, когда вы меняете это состояние вы должны ввести текст примечания. Механизм создания собственных Workflows очень важен, если модель разработки (взаимодействия между участниками) отличается от приведенной выше, например, если вы хотите применить JIRA не для управления проектом по разработке ПО, а для других видов проектов. Например, вы разрабатываете архитектурные проекты, и у вас есть шаги: “нарисовать дизайн”, “начертить схему”, “утвердить проект в санэпидемстанции”, “утвердить у пожарников”, …, “заплатить бакшиш”. Каждый из этих шагов может следовать только после другого шага (нельзя утвердить проект до того как будет создан чертеж). Попробуем создать собственную схему Workflow, для этого в режиме администратора переходим по ссылке “Workflows”, там мы увидим описанную выше схему по-умолчанию (ее нельзя редактировать). Внизу страницы вы видите форму добавления новой схемы. Указав название (на латинице) и примечание к схеме, мы переходим на этап наполнения ее содержимым. Прежде всего, необходимо спланировать шаги (состояния обработки запроса). Каждый шаг имеет название и привязанный к нему статус (например, RESOLVED). Перечень статусов не является жестко фиксированным и его можно изменять (режим администрирования, ссылка Statuses). После того как вы создали нужные статусы и привязанные к ним состояния, необходимо создать переходы (Transitions). При создании перехода кроме указания начальной и конечной точки можно (хотя и не обязательно) указать еще и Экраны (например, для перехода от состояния “Дать бакшиш” к состоянию “Утвердить” нужно ввести примечание, что денег не хватило). Экран представляет собой html-форму с некоторым полями (да вы можете создавать собственные формы), которую нужно заполнить для успешного завершения перехода (Transition). Фактически JIRA представляет собой гибкий конструктор позволяющий создать систему управления проектами, выполняемыми работами и подстроить ее под вашу бизнес-модель. Если вам не будет хватить каких-то функций, то можно воспользоваться плагинами или создать собственное расширение возможностей JIRA.
Чтобы вступить в группу, Вам необходимо войти .
ИнформацияОписание: Atlassian JIRA — коммерческая система отслеживания ошибок, предназначена для организации общения с пользователями, хотя в некоторых случаях систему можно использовать для управления проектами. Показать полностью… Разработана компанией Atlassian Software Systems. Платная. Имеет веб-интерфейс. Название системы (JIRA) было получено путём модификации названия конкурирующего продукта — Bugzilla.[1] JIRA создавалась в качестве замены Bugzilla и во многом повторяет архитектуру Bugzilla. Система позволяет работать с несколькими проектами. Для каждого из проектов создаёт и ведёт схемы безопасности и схемы оповещения.
Установка JIRA
Русификация JIRA
Настройка
а также общие вопросы Место: Москва, Россия
Ищу специалиста по Jira!!! Нужно внедрить проект по поддержке пользователей Jira Service Desk на нашем сервере. Вся работа оплачивается в полном объеме. По всем вопросам обращайтесь ко мне в личку, либо на почту alexey.movchan@navicadata.ru
Мы в Mail.Ru пользуемся JIRA и Confluence более 5 лет. Информации на русском практически нет, для обмена опытом мы периодически проводим встречи и митапы.
Было бы здорово объединиться в полноценное сообщество профессионалов, чтобы всегда можно было попросить совета - для этого мы создали группы в соцсетях.
Сами мы в свою очередь также готовы делиться опытом!
Присоединяйтесь к нам! Это бесплатно. )
Группа мертвая. Кому нужна консультация по jira пишите в личку. Если смогу отвечу.
Мда. Группа мертвая :(
Перевода нет. Придется смотреть альтернативу.
Система учета задач и багов Atlassian Jira позволяет создавать в проекте задачи, назначенные конкретному разработчику. А также планировать их по версиям проекта, редактировать, добавлять комментарии, осуществлять полнотекстовый поиск.
С одной стороны – база задач с веб-доступом. С другой – эта система напоминает форум, где каждая задача – как тема с возможностью комментирования. Задачи привязаны к проектам. У задачи есть статус (открыта, в работе, выполнена и т.п.). Кроме того, у задачи есть исполнители, сроки, прикрепляемые файлы.
Естественно, есть возможность поиска и получения отчетов о ходе работ по проекту.
Весьма полезна в групповой распределенной разработке сложных систем. Все разработчики и менеджеры видят текущие и долгосрочные задачи, собранные в одном месте. Тестеры и клиенты могут добавлять обнаруженные баги и запросы на новые фичи, прикреплять свои патчи с решением проблем.
ДоступУчетные данные – ваши стандартные на доступ к Confluence.
Информация ALM Works JIRA ClientВесьма достойный тул, но коммерческий. Лекарство при желании найти достаточно просто.
Mylyn или JIRA в EclipseПри работе в Eclipse настоятельно рекомендуется пользовать Mylyn.
Что же в нем хорошего?
1. Этот плагин добавляет поддержку задаче-ориентированного интерфейса. Все артефакты разрабатываемого проекта (файлы, классы и т.п.) можно привязать к конкретной задаче, что снижает информационную перегрузку разработчика.
2. Кроме того, вы можете создавать, редактировать, планировать задачи за доли секунды не выходя из IDE.
3. Вы можете получать уведомления о новых задачах, пославленных вам или любому другому разработчику. Для этого нужно всего лишь настроить параметры в запросах на выборку нужных вам задач.
Прочитать на русском:
Это лучше один раз увидеть, чем сто раз прочитать! Поэтому дальше два идеологических видео про Mylyn (English):
Обычно Mylyn уже установлен в большинстве дистрибутивов Eclipse и к нему нужно только доустановить поддержку Jira:
Другие клиентыКроме web-интерфейса и интеграции в IDE (Mylyn + Jira Connector) существует ряд отдельных клиентов
Web-ориенированная, полностью настраиваемая issue-tracking система для управления проектами. Может использоваться для поддержки клиентов. Высокий уровень безопасности. Наличие API и множества плагинов. Отличная email-интеграция. Есть русский интерфейс. Возможен хостинг на стороне провайдера.
Альтернативы JIRA Обзоры и новости о JIRA
2014. Jira интегрировали с системой контроля версий Git
Компания Atlassian выпустила новую версию своего issue-трекера Jira 6.2. Новая версия JIRA переосмысливает подход к интеграции инструментов для разработчиков, особенно с системой контроля версий Git. Теперь в каждой заявке присутствует секция Development, которая является стартовой точкой для разработчиков и менеджеров продукта. Информация, представленная в секции, позволяет понять, что на данный момент уже сделано по текущей задаче, а что еще предстоит сделать. Прямо из JIRA вы теперь можете увидеть список веток, коммитов или пул-реквестов, связанных с этой заявкой в системе управления Git репозиториями Stash, или быстро увидеть историю билдов и deployments, которые собраны в системе непрерывной интеграции Bamboo. Кроме того, прямо из JIRA вы можете сделать ветку и начать разработку новой функциональности.
2013. JIRA 6 - новый интерфейс системы управления проектами
Компания Atlassian представила новую версию своей системы управления проектами JIRA 6 и фактически единственным обновлением стал новый интерфейс. Разработчики говорят, что новый интерфейс более простой, быстрый и позволяет уделять больше внимания основной цели - разработке ПО, а не поиску и разбору ошибок. Усовершенствовали они и мобильный интерфейс (в частности, комментарии), но нативные мобильные приложения для iOS и Android так и не появились. Зато появились шаблоны для создания новых проектов и процессов. JIRA как и раньше доступна в качестве SaaS сервиса или как инсталлируемая система. Стоимость начинается от $10/месяц за 10 пользователей.
2013. JIRA Mini - новый мобильный клиент для Atlassian JIRA
Хотя Atlassian предоставляет мобильный веб-интерфейс для баг-трекера JIRA, многим пользователям не хватает нативной версии. Молодая петербургская компания Strintec выпустила приложение JIRA Mini. JIRA Mini позволяет подключаться к баг-трекеру JIRA с мобильного телефона или планшета. Удобный и минималистичный интерфейс позволяет просматривать и изменять заявки с мобильного устройства. С помощью приложения можно создавать и редактировать заявки, добавлять к ним файлы и оставлять комментарии. JIRA Mini работает на Android 2.2+ и доступна в Google Play. Версия для iPhone готовится к публикации в AppStore.
2012. Jira 5 - баг трекер становится социальным
Компания Atlassian представила новую версию своей системы управления проектами Jira 5 и обозвала ее социальной. Мы ожидали увидеть какую-то встроенную социальную сеть, где пользователи могли бы добавлять баги, голосовать за фичи, обсуждать новые версии ПО. Но ничего этого не появилось. Возможно и к лучшему, т.к. баги - это вещь интимная и ее нельзя выносить на общее обсуждение. А социальные фичи в Jira 5 - это возможность расшарить багу/задачу для сотрудников или групп, и поддержка @Имен. Если вы @кого-то упомянули в комментарии - ему придет оповещение и он подключится к работе над задачей. Кроме того, в новой версии появилась возможность привязывать баги к любому URLу сайта или веб-приложения и добавлено много интеграций (в т.ч. Salesforce, Zendesk, Confluence, Get Satisfaction). И вас конечно, интересует, почему в видео так много Angry Birds? ***
2011. JIRA и Confluence доступны в виде SaaS сервиса
Компания Atlassian запустила SaaS сервис Atlassian OnDemand, в который вошли ее популярные (и в России, и в мире) инструменты для управления проектами разработки ПО: JIRA (issue-трекер), Confluence (wiki), GreenHopper (Agile управление проектами), Bonfire (баг-репортер), FishEye (менеджер кода), Crucible (рецензор кода) и Bamboo (интеграция). Все продукты в SaaS версии по функциональности не уступают инсталлируемым аналогам. Есть лишь минимальные ограничения по интеграции и использованию собственных плагинов. Инструменты можно подключать или отключать по мере необходимости. Ценообразование сервиса - уже традиционное для Atlassian - "все по $10 за 10 юзеров". Напомним, что компания уже давно продает эти свои продукты (в инсталлируемом варианте) по цене $10 за лицензию на 10 пользователей. Т.е. вы можете либо купить продукт за 10$, либо взять его в аренду за 10$/месяц. ***
2011. Jira Mobile Connect поможет тестировать мобильные приложения
Специально для команд, разрабатывающих мобильные приложения, компания Atlassian создала бесплатное дополнение к системе управления проектами Jira - Jira Mobile Connect. Этот инструмент позволяет создавать наиболее полные баг-репорты или запросы и автоматически сабмитить их в Jira. Библиотеку Jira Mobile Connect можно встроить непосредственно в мобильное приложение на период тестирования. При этом у тестировщиков и бета-пользователей появится возможность не просто отсылать баг-репорты разработчикам, но и снабжать их скриншотами с аннотациями, голосовыми комментариями. Можно даже мгновенно инициировать чат с разработчиками на мобильном девайсе. Пока Jira Mobile Connect работает только на iOS, но Atlassian уже готовит версию под Android.
2010. Atlassian купила SaaS систему контроля версий
Компания Atlassian, исвестная своим issue-трекером Jira и wiki-системой Atlassian, приобрела сервис Bitbucket, который представляет собой онлайн систему контроля версий (DVCS = Distributed Version Control System). Сервис позволяет организовать совместную работу над софтверными проектами в георафически распределенных командах и в компаниях, использующих удаленных разработчиков. Благодаря сервису, каждый разработчик имеет на своем компьютере локальную копию исходного кода разрабатываемого продукта, которая синхронизируется с копией на сервере. При этом система позволяет контролировать версии файлов и устранять конфликты, которые могут возникнуть при одновременном редактировании файла двумя разработчиками. Bitbucket - это довольно популярный сервис, на котором, в частности, хостятся такие проекты, как Opera, Adium, MailChimp. Atlassian обещает, что бесплатная версия сервиса для 5 участников останется бесплатной навсегда.
2010. Вышел GreenHopper 5
Компания Atlassian выпустила новую версию инструмента для управления Agile проектами GreeenHopper 5. Напомним, GreeenHopper представляет собой плагин для веб-ориентированного issue-трекера Jira. Первое, что изменилось в GreenHopper - это интерфейс. Пользователи часто жаловались, что интерфейс GreenHopper отстал от Jira на десяток лет. Теперь интерфейс project-менеджера приведен в соотвествие с интерфейсом материнской системы. Много улучшений были сделаны для повышения ценности GreenHopper во время совещаний. В частности появились наглядные итоговые графики по версиям. Теперь можно легко перетаскивать карточки задач (в т.ч. между страницами) изменяя их порядок и приоритетность, добавлять сроки и заметки к задачам. Кроме того, добавлены различные удобства для команд, работающих по методологиям Scrum и Kanban.
2007. Почему переходят на JIRA?
Как только появляется необходимость в helpdesk системе для поддержи разработки ПО (или баг-трекере), в первую очередь обращают внимание на бесплатные open-source системы. Самые известные представители этого класса: Bugzilla, Mantis, Trac и Redmine - они обладают всей необходимой функциональностью, и делают это достаточно хорошо. Однако пользователи постоянно переходят с бесплатных баг-трекеров, на JIRA, коммерческий продукт, к тому же не из дешевых. В чем причина такой миграции? ***
Казалось бы. при чем тут тестирование?
А с другой стороны, почему бы и нет? Тестировщик вполне может быть админом JIRA или любого другого инструмента для ведения ошибок. Ведь это место (скопление багов) - наша стихия. Конечно же, мы хотим уметь настраивать ее под себя.
Чем мы с Вами и займемся. Показывать администрирование я буду на примере облачной JIRA, поэтому, если у Вас она обычная - может быть немного другой вид. Но это ничего, принцип не меняется.
Итак, поехали! Для начала нам нужен проект. Где его создавать? В админке. Переходим туда. Справа в верхнем углу экрана, справа от строки поиска и слева от нашей аватарки есть такая шестереночка - нажимаем на нее и выбираем вход в админку.
Открывается примерно такой вид.
То есть общее число проектов, возможность перейти на один из них и далее длинный список всяких вкусностей, которые мы можем менять и настраивать. Но этот список нас пока не интересует, нам нужна кнопка "Add Project" - "Добавить новый проект".
Вводим название нового проекта, а нам система предлагает возможное сокращение. Вторая строка, Key - это то краткое название, которое будет преследовать Вас на протяжении всего проекта.
Дело в том, что, когда мы заводим баги / таски / истории / улучшения / итд - у нас генерируется номер задачи по принципу Key-
Нас может не устраивать предложенное системой сокращение, давайте поменяем его на TEST.
Сохраняем проект и попадаем на страничку его администрирования и настроек.
Что нам здесь может пригодиться? Ну, во-первых, версии.
Добавляем версии.
Какие версии. Ну, разумеется, версия "1.0", наш первый релиз. А остальное. Остальное в backlog! Следующее, что нам нужно - компоненты. А вот и они, смотрите, рядом с версиями, для Вашего удобства 
Компоненты - это то, по чему можно будет сортировать список задач. Например, перед созданием новой ошибки признаком хорошего тона является проверка того, а не создана ли она была до Вас Вашим коллегой? Хорошо, если у Вас всего 10 открытых задачек. Просмотрели все. А если их 100. Уже посложнее задачка.
Но если Вы знаете компонент, всегда можно сделать сортировку по нему - а сколько по данному компоненту было поставлено баг? Кем? Какого приоритета? Сколько открытых? И прочее.
Добавим какие-нибудь стандартные компоненты.
Так! Теперь нам надо создать задачу! Как это сделать? А вот она - кнопочка сверху - "Create Issue". Несмотря на то, что мы находимся в режиме администратора, мы легко можем переключиться на простой пользовательский режим, что мы и делаем.
При создании задачи вначале необходимо определиться, какой у нее тип.
Ну, багов в нашем тестовом проекте пока нет, создадим простую задачу.
Заполняем ее поля.
Summary - Название. Краткое описание задачи. Обязательное.
Priority - Приоритет. Обычно Major, если более высокий, есть дефолтные значения "Критичный таск" и "Блокер", а также более низкие - "Минорная задача" или даже "Тривиальная".
Component/s - Выпадающий список из только что добавленных компонентов. Выбрать можно как один, так и несколько (например, "формочка 1" + "отчеты" или "логи" или что-то еще. ). Поле по дефолту обязательное, если мы добавили компоненты в проект. Иначе пустое.
Affects Version/s - Выпадающий список из только что добавленных версий. Выбрать можно как один, так и несколько (например, "релиз 1.0" + "поддержка". Необязательное.
Reporter - Автор задачи. По умолчанию тот, под кем мы залогинены.
Environment - Окружение, на котором найдена ошибка. Можно оставлять пустым, принимая за основное какое-то одно окружение, например, тестовый стенд. Тогда поле заполняется, только если бага была найдена на другом окружении, например, интеграционном.
Description - Описание ошибки / задачи.
Пока хватит. Заполнили поля и создали задачу - снизу кнопочка "Create" и-и-и-и. Упс, ошибочка вышла.
Возвращаемся в админку. Под разделом "Компоненты" есть раздел "Роли". Видим там, что "Ольга Киселева" является Project Lead проекта, а Default Assignee (у которого, судя по ошибке, нет прав) - как раз Project Lead.
Ладно, смотрим еще ниже, под ролями у нас есть раздел с правами доступа. Смотрим, что за дефолтная схема у нас подключена.
Choose your language, english, espaol, deutsch, franais, русский, user manual for gliffy online. Переведена на многие языки, включая русский, английский, японский, немецкий, французский, испанский.
Русском руководство пользователяруководство по ремонту икарус you can руководство по эксплуатации погрузчик львов also add hyperlinks to text not available, in the gliffy plugin, for ководство пользователя 3 jira 4. Jira руководство пользователя.
Обобщенная структура гостам инструкции русском.
Руководство пользователя jira. Canon на русском. как настроить каналы триколор тв на ресивере gs u510 iphone руководство пользователя для ios 7руководство пользователя на русском языке.
Сегодняшний день atlassian jira руководство пользователя jira на русском является одним из самых.
Для igo primo на русском языке. Пользователя, zoom r24 мануал, на русском. При открывании пользователя.
Jira множество компаний, среди руководство пользователя jira на русском которых, nokia, navteq. thales, образец письма извинения за срыв поставки electronic arts, quantumсенруководство, пользователя jira.
Руководства по freebsd руководство пользователя jira на русском на русском. 36 в 35 продвижение 25 подключения 24 французского 20 русскомфевна. Установка плагина на jira.
Представленное руководство описывает действие разных участников“ школы.
После моих предыдущих статей о том, как не надо управлять командами и разработкой. а также нескольких увольнений адских менеджеров, мне стали поступать просьбы написать о том, как именно надо управлять разработкой. Как надо — у всех свои рецепты, но как я это делаю расскажу ниже. Как и в сексе, в способе планирования у всех вкусы разные (наверное). Я предпочитаю итеративный Agile Scrum, длительность итерации классическая, двухнедельная. Из инструментов долгое время пользовался trac’ом (очень хорошо доработанным и настроенным), затем был вынужден работать с такими зомби, как Редмайн или Ассембла. Наконец нашлось время, силы и энергия перейти на Jira и это было прекрасно. Поэтому я расскажу о связке скрам + джира в нашей небольшой команде. Расскажу кратко, времени на написание главы из книги нет; тут будет чисто некоторая практика, которую я нашел оптимальной для себя и для управления командой в 10-20 человек.
Agile Scrum в команде РетроспективаСобственно, тут ничего нового нет и не придумано. Раз в две недели у нас есть день на то, чтобы сделать ретроспективу, на которой мы все по очереди рассказываем о том, что сделано, какие возникли проблемы по ходу разработки и что порадовало, о достижениях прошедшей итерации. Тут же попутно выписываются проблемы и задачи на планирование, но внимание на них не заостряется, они будут обсуждаться позже. Мы пока что не устраиваем больших демонстраций с артом и прочим (заказчик обычно не присутствует, так что смысла особого на текущем этапе нет). Для чего нужна ретроспектива: чтобы все были в курсе о том, что сделано в проекте по факту, не по задачам, закрытым в Джире, могли задать вопросы, уточнить те или иные моменты. Вербально можно передать гораздо больше и оперативнее, чем при помощи трекера. Таким образом, все видят прогресс (если он есть). Если же возникнут проблемы, сложности, то они тоже будут выявлены и о них будет знать вся команда, иметь в виду и может быть коллективно будет предложено наилучшее решение. После ретроспективы, которая занимает от часа до двух, перерыв 10-15 минут. Затем начинается планирование.
ПланированиеОсновной инструмент на планировании — бэклог, составленный ранее. Если кто-то не знает, то в бэклог включаются все основные задачи верхнего уровня. В идеале, он составляется сперва заказчиком, когда он описывает что хочет видеть в проекте. Далее он детализируется продюсером или другим ответственным человеком, или командой на планировании. У нас он достаточно детализированный, на текущий момент в нем 95 задач, большая часть из которых высокоуровневые фичи. Высокоуровневые фичи — это те, которые потребуется еще раскрывать, делить на подзадачи (которых может быть сотни), каждую из них описывать и так далее. То есть эти 95 задач могут превратиться и в 950, и в 9500. Например, на текущий момент со времени написания статьи, количество фич у нас выросло примерно до тысячи. Фичи добавляются в бэклог и по мере разработки или обсуждений (так же, как и баги).
На планировании берется фича и оценивается: кто лучше ее сделает; кто в ней задействован и сколько времени займет ее реализация. Мы оцениваем время не в story points, а пока что в идеальных часах с последующим переходом на поинты (попугаи), но по некоторым внутренним причинам сейчас для нас лучше часы. Если время на выполнение задачи превышает 16 часов (два дня), то задача разбивается на подзадачи. Это позволяет лучше понять, что нужно сделать в рамках этой задачи, на что потребуется время и более точно оценить задачу, не заложив на нее лишнего времени и не пролетев мимо сроков.
На одного человека мы набираем от 70 до 80 идеальных часов — времени, которое ему понадобится, если он верно оценил задачу и его никто не будет отвлекать. Количество часов зависит от предыдущих итераций, от того, как каждый закончил свою итерацию. Например, если человек закрыл свои задачи раньше срока, значит он недооценил свои силы; если он что-то не успел. значит он переоценивает свои силы (или недооценивает сложность задач). Главное, не использовать скорость (velocity) как показатель продуктивности: это порочный путь, который из инструмента повышения точности при планировании превращается в кнут и хоронит саму суть и смысл аджайла. Тут можно дискутировать, что люди будут стараться не закрывать свои задачи вовремя, по мере исполнения. Да, такое может быть; но у нас работают взрослые, ответственные сотрудники, которым нет нужды так делать. На ретроспективах и планировании тоже очень легко выявить завышения, сроков. С занижением сроков сложнее, тут нужно понимать человека, что ему предстоит сделать, иметь в виду его результаты по прошлым итерациям и человеческий фактор.
Agile pokerАджайл покер — это замечательный инструмент для уточнения сроков и выявления недопонимания. Кроме того, это достаточно весело. Суть аджайл покера в том, что у всех есть карточки с часами: 1, 2, 4, 8, 16, а также. и «перерыв». Когда оценивается задача, все кто может ее оценить, кладут карточки на стол цифрой вниз и затем вскрываются. Если время овпало, то задача оценивается в это время. Если нет, и тем более если разница большая, то начинается выяснение, почему такие разные оценки. По предыдущему проекту знаю, что это очень хорошо работает и я всем рекомендовал бы использовать это игровой элемент. Иногда вскрываются дополнительные задачи, которые вообще были бы упущены и не включены в итерацию. в этой команде мы не используем покер из-за очень узкой специализации каждого сотрудника, а также из-за того, что у всех очень разные фронты работы: есть некоторая рассинхронизация в задачах. В идеальном мире вся команда берет одну фичу и совместно ее делает. Например, все делают фичу »стрельба»: сервер синхронизацию пуль и передачу пакетов, логика — попадания и поражения, клиент — отображение на клиенте, интерфейс — изменение состояний и баров, художники — огонь выстрела и эффекты попадания. У нас не так: сейчас мы добиваем хвосты (печальное наследие изгнанного исчадия ада) и только приближаемся к синхронной работе. Поэтому покер при таких разноплановых задачах, какие приходится решать нашей команде, не подходит. Кстати покер понравился команде, никогда раньше так не работавшей, когда ради эксперимента мы так провели итерацию.
Стендап митинги, ежедневные митингиОчень быстрая блиц-летучка, на которой каждый говорит что сделал вчера, что будет делать сегодня и какие (если есть) возникают проблемы. Программисты не любят эти митинги так как им кажется, что это какая-то форма отчета, будто их призывают к доске в школе. Объяснить, что митинги нужны для повышения мотивации, синхронизации работы и выявления проблем достаточно сложно, но со временем понимание этого приходит и, если митинг пропущен, то некоторые сами спрашивают — почему пропустили и будем ли сегодня скрамить. Для команд, которые только начинают работать по аджайлу, я (личное мнение, которое идет вразрез с канонами аджайла) рекомендую делать митинги не чаще раз в 2-3 дня, или даже 3-4 дня и постепенно проводить их все чаще и чаще, без насилия над командой. Основная задача скрам мастера/ПМа сделать так, чтобы команда начала воспринимать дейли митинги как инструмент, а не как кнут. С менталитетом русских разработчиков это, пожалуй, самое сложное в аджайле.
Atlassian JiraДжира хороша всем, а особенно тем, что она умеет работать в режиме аджайла. У нее есть форма отображения бэклога, она работает с карточками, строит burndown диаграмму, настраивается как угодно и на команду в 10 человек стоит всего $10 ежемесячно. Еще один плюс — OnDemand версия не требует покупки хостинга, домена и установок, в эти $10 ежемесячно все уже включено. Достаточно только зарегистрироваться и создать проект, остальное все сделается само за 5 минут.
БэклогВ бэклоге Джиры есть такое понятие, как эпик (epic), то есть ключевая фича проекта. В эпики можно включать обычные фичи, баги, стори, задачи и вообще все прочее. Однако сейчас мне удобнее использовать эпики как рубрики разработки: например, архитектура сервера, игровая логика или арт. Почему — потому, что ключевые фичи, над которыми работала бы вся команда одновременно, или все уже реализованы, или до них еще как до Китая. Вероятно, когда определенный этап будет достигнут, появятся эпики командные, которые будут объединять задачи из разных компонентов. Например, это может быть »полет в космосе», и туда будут входить и задачи по серверу, клиенту, арту, логике, геймдизайну, звукам и чему-то еще. Но лучше один раз увидеть чем сто раз перечитать, поэтому наш бэклог выглядит вот так (делась скриншотом, никаких секретов не раскрою):
Что тут видно: слева — эпики (категории задач), по центру — задачи в бэклоге (уже достаточно мелкие и детализированные), справа — детальная информация по задачам и возможность их редактировать. В скриншот не попали задачи из текущего спринта, но это и не сильно важно — там то же самое, только вместо Backlog написано Sprint X и завершенные задачи зачеркнуты.
Вместо карточек, прилепленных к доске, используется борд Джиры. Он настраивается как угодно. Мы используем вид по умолчанию — три колонки: к выполнению, в работе и завершена. Задачи перетаскиваются туда-сюда; завершить можно по-разному: сделана, невозможно сделать, отменена и на тестирование. Можно добавить любые другие статусы или колонки. Выглядит текущий спринт так (картинка тоже естественно кликабельна):
Ну и по ходу пьесы можно смотреть прогресс разработки на burndown чарте (наверное, его можно перевести как »график производительности», но суть его в том, что задачи именно сжигаются в процессе разработки). Серая линия — идеальная разработка, если каждую секунду разработчики отмечают прогресс, но так конечно не бывает. Красная линия — выполнение задач, где каждая точка является успешно завершенной задачей. Идеальный спринт выглядит похоже на скриншот, когда красная линия справа снизу встречается с серой в одной и той же точке. На скриншоте ниже видно, что спринт завершился на несколько часов позже положенного (на самом деле спринт завершили немного раньше времени, но в Джире было выставлено не московское время — если будете работать в Джире, не забудьте поставить сразу же правильный часовой пояс):
Как я уже писал выше, этот чарт строится ежеминутно и любой член команды может мониторить актуальный прогресс в любой момент. На спринте есть лишний пик 23-го октября — это задачи, которые по ошибке не были упущены из спринта в момент его запуска и затем добавлены. Таким образом, добавлять незаметно задачи просто не получится. Все будут это видеть, а спринт все равно волей неволей придется завершать, или будет очень некрасивая картинка: серая линия давно дошла до финиша, а красная идет где-то сильно правее сама по себе. Так что если вы работаете с адским менеджером, подсуньте ему Джиру в режиме аджайла и ему придется завершать спринты (если он не захочет бунта команды). Или если вы владелец бизнеса, то то же самое, но в принудительном порядке, благо мониторить разработку так можно без каких-то особых знаний и программерских навыков. Конечно, это не панацея, но инструмент очень неплохой. В Джире есть множество других инструментов для наглядного отображения прогресса — по скорости, по эпикам, по объемам и так далее, но это уже для тех, кто немного освоился с Джирой и аджайлом.
В заключение скажу, что сперва Джира кажется страшной, сложной и очень навороченной. Но вникнуть в нее дело одного дня, разобраться с настройками примерно столько же. Иногда, когда будут возникать специфические задачи (например, сделать два разных проекта и ограничить доступы разным командам) придется почитать документацию, но тоже все делается за полчаса. Польза, которую приносит Джира, по-моему однозначно стоят этих скромных усилий и совсем небольшого времени.
Попробовать демо-режим Джиры можно тут. в их демонстрационном разделе, где много разных проектов, разных типов на любой вкус и цвет.
Надеюсь, что эта очень сильно оптимизированная по количеству слов заметка будет вам полезна.
Поделиться ссылкой:
