какие роли существуют в задачах jira

Система управления проектами и задачами JIRA компании Atlassian и ее применение

О продукте JIRA

Представляя продукт JIRA, нужно сказать, что жизни любой компании бывает момент, когда количество дел, которое вынуждены контролировать сотрудники и особенно руководство становится таким что превосходят возможности человеческой памяти.

При решении многосложных задач бывает момент, когда сотрудники и управляющие не могут видеть проект в целом, теряется из памяти необходимость сделать те или иные работы.

JIRA это программа, претендующая на звание стандарта де-факто в этой области, и ее применение очень широко.

Для поддержки гибких методик разработки (Agile software development, Scrum и Kanban вы можете установить add-on JIRA Agile (ранее называвшийся Greenhopper).

Смотрите страницу на сайте Atlassian обо всех продуктах компании.

Области применения JIRA

JIRA это продукт, предназначенный для организации процесса контроля запросов и задач, имеющий часть функциональности обычно присущей большим и дорогим системам управления проектами.

Ключевыми понятиями в JIRA являются проекты и задачи. Задачи создаются в проектах, для выполнение задач назначаются исполнители. Задачи могут быть разного типа и иметь подзадачи, задачи могут быть связанными с другими задачами. Статус задач меняется в процессе их выполнения.

JIRA приносит большой эффект любой организации, деятельность которой можно интерпретировать как выполнение каких-либо проектов и задач, имеющих тематические и временные рамки.

Главное преимущество этого продукта в его ни с чем не сравнимой способности настройки под ваши нужды.

Например, в финансовой сфере, вы можете организовать процесс оформления кредита, от заявки, к вводу необходимых данных, к принятию решения и так далее.

Проекты и задачи

Ключевыми понятиями в JIRA являются проекты и задачи. Проекты служат для группирования задач. Задачи создаются в проектах, для выполнения задач назначаются исполнители. Задачи могут быть разного типа и иметь подзадачи, задачи могут быть связанными с другими задачами. Статус задач меняется в процессе их выполнения.

Проекты

Также, JIRA формирует отчеты по каждому проекту.

Задачи

Задачи создаются в проектах. Задачи имеют типы, например: Задание, Ошибка, Новая идея. Можно создавать и свои типы задач. При описании каждого типа задачи имеется возможность управления набором полей.

Фильтры

JIRA позволяет отыскивать задания по всем критериям и по пользовательским полям, создавать фильтры, которые можно сохранить и использовать вновь, а также сделать общедоступными и организовать автоматическую рассылку результатов работы фильтров членам рабочей группы.

Управление доступом, разделение ролей

Для организации работы с пользователями JIRA имеет группы пользователей и роли.

JIRA имеет систему контроля доступа пользователей к проектам, задачам и функциям, основанную на членстве пользователей в группах и ролях.

Так, для каждого проекта, есть возможность управления доступом каждой группы пользователей к каждому действию. Также, есть возможность сформировать набор допусков в «роль».

Типичное простейшее разделение ролей в JIRA включает в себя роли:

Но возможности JIRA этим не ограничиваются, возможно создание специальных ролей, например таких, которым возможно только чтение задач одного типа но невозможно другого.

Движение задач

Задачи JIRA в каждый момент времени имеют определенный статус. Возможные действия с задачами, имеющими тот или иной статус, определяется встроенной системой управления движением задач. Здесь приведена схема простейшего описания движения задачи.

В JIRA имеется возможность создания столь сложной схемы движения задачи, какая нужна. Схема движения задачи может быть своя для каждого отдела, проекта, типа задачи.

Схема движения редактируется встроенным редактором. Редактируя движение задач, создавая новые статусы задач (события) и определяя возможные действия, можно организовать любую работу.

Движение задачи можно сделать зависимым от условий, применять логику И/ИЛИ, выполнять определенны действия на каждом этапе движения задачи.

Нотификации

Задачи JIRA в каждый момент времени имеют определенный статус. Пользователи информируются по e-mail в случае любых действий с заданиями, для этого служит настраиваемая система нотификации пользователей. Совместно с системой управления движением задачи и настраиваемыми рассылаемыми фильтрами это позволяет очень эффективно информировать всех заинтересованных лиц о ходе выполнения задачи.

Отчеты и диаграммы

Для аналитических целей JIRA создает карту проекта (project roadmap), позволяет просматривать загрузку каждого пользователя и делает многое другое для эффективного управления проектами. Также имеется целый ряд необходимых стандартных отчетов.

Кроме стандартных отчетов, JIRA позволяет написать свои отчеты.

Приборная панель

JIRA позволяет управлять видом специальной стартовой страницы, называемой приборной панелью. На этой странице отображается ход выполнения проектов и имеются ссылки для быстрого доступа ко всем часто используемым функциям, отчетам и задачам:

Безопасность

JIRA может работать через защищенное соединение с применением SSL.

Расширенные возможности JIRA, JIRA API

JIRA позволяет создавать задачи через e-mail и таким образом автоматизировать работу.

Имеется возможность просмотра хранилища файлов CVS (Система Конкурентных Версий).

JIRA имеет опубликованный программный интерфейс, обеспечивающий программный доступ к основным функциям системы (SOAP API), расширения позволяющие дополнять систему собственными сервисами для решения специфичных задач предприятия.

Пользователи JIRA

JIRA используют для контроля ошибок и проектов в более чем 20 000 организациях в более 138 странах по всему миру. В Fortune 1000, общественных организациях, в научных и технологических сферах:

Например, здесь список некоторых из пользователей JIRA в сфере государственного управления:

Отзывы пользователи JIRA

Новости

Источник

JIRA: границы проекта

Ранее в статье «JIRA как средство от бессонницы и нервных срывов» был предложен вариант применения JIRA для управления проектом по разработке программного обеспечения в интересах крупного государственного заказчика. Однако неосторожное обращение со средствами автоматизации управления на «цифровой кухне» может не только испортить продукт приготовления, но и привести к многочисленным травмам. В серии статей «Правила своевременного приготовления вкусного программного обеспечения» предполагается подробно исследовать правила организации работ на программном проекте с использованием катализатора под названием JIRA. Приветствуется любая критика.

Секреты Полишенеля

Интеллект — это способность избегать выполнения работы, но так, чтобы она при этом была сделана.
Линус Тордвальдс

После публикации статьи «JIRA как средство от бессонницы и нервных срывов» несколько руководителей заинтересовались нашим опытом использования JIRA и решили внедрить подобную схему автоматизации управления на своих проектах. Поэтому в результате написания этого эссе предполагалось одновременно «изловить несколько зайцев»:

— последовательно рассматривая каждый тип задач JIRA как подпроцесс проекта, в ходе изложения:

Сразу хотелось бы отметить: часть описанных техник хорошо зарекомендовали себя на одной из «цифровых кухонь» ЛАНИТ для управления проектом по разработке и сопровождению заказного программного обеспечения в интересах крупного государственного заказчика. Однако совсем не факт, что эти рекомендации окажутся одинаково полезны и на вашем проекте. С другой стороны, мы вступаем на terra incognita. Часть высказанных соображений только планируется к внедрению. Поэтому если вы видите в предложенном подходе слабые места или есть конструктивные предложения по оптимизации – добро пожаловать к обсуждению в комментариях.

Предполагается, что после проведенной унификации в интересах разных руководителей описанная технология управления будет успешно применяться на программных проектах разной направленности и разного масштаба. В свою очередь, использование единого понятийного пространства при регистрации задач JIRA создает предпосылки для автоматизированной оценки текущего состояния дел в рамках портфеля проектов. Кроме того, предполагается, что единый подход к учету результатов работ в JIRA упростит мобильность сотрудников между несколькими проектными группами, что в свою очередь также будет способствовать повышению успешности проектов.

Границы проекта

Любая сложная задача имеет простое, легкое для понимания, неправильное решение.
Артур Блох

Поскольку предложенный алгоритм применения JIRA стал «расползаться» на другие проекты, потребовалось переосмыслить вопрос: «А чем собственно определяются границы программного проекта в JIRA?»

По мнению адептов незамутненного PMBoK, ответ на этот вопрос элементарен: «Конечно, границы проекта определяются уставом (паспортом) проекта». С этой точки зрения, для каждого договора с заказчиком в JIRA должен быть сформирован отдельный проект. При этом зачастую разработка одного программного комплекса может предусматривать несколько направлений деятельности, в рамках которых, как правило, заключается несколько контрактов:

Однако, как показала практика, в реальной разработке длительно сопровождаемого программного продукта тяжело разделить работы по развитию и по сопровождению. Еще не закончилась опытная эксплуатация (контракт на развитие не закрыт), а заказчик уже вовсю формирует требования по расширенному сопровождению к компонентам системы, которые еще не приняты в промышленную эксплуатацию. Заказчика можно понять, поскольку мир меняется быстрее, чем это было запланировано в утвержденных контрактах. При этом продолжается выявление новых дефектов программного обеспечения. И пользователю, обнаружившему дефект, совершенно не важно, в рамках какого договора эта ошибка должна быть исправлена. С его точки зрения — ее просто не должно было быть. Для того, чтобы отнести выявленную ошибку к тому или иному договору, нужно время на ее анализ, и если проекты JIRA разделены на основе договоров, возникает дилемма: «А в каком проекте JIRA надо этот дефект регистрировать?». Кроме того, необходимо организовать перенос задачи из одного проекта в другой, если была допущена ошибка классификации требования. Если же все выявляемые дефекты программного обеспечения возложить на отдельный проект группы сопровождения, повышаются риски возникновения проблем при решении вопросов оплаты работ по этапу договора на развитие или рассмотрения рекламаций по несоблюдению соглашения об уровне предоставления услуг (SLA).

С другой стороны, ревнивые руководители подразделений предлагают в рамках проекта сформировать отдельные проекты для группы сопровождения, аналитического отдела, департамента разработки и тестирования. Каждый хочет быть полноправным хозяином в своей епархии и не отвечать за «косяки» соседей. Тем более, что удивительная гибкость JIRA позволяет создавать связи между задачами разных проектов.

На мой взгляд, вышеописанные подходы регистрации проектов в JIRA похожи на попытки сварить один суп в нескольких разных кастрюлях, находящихся в разных кухнях. Основной целью проекта является своевременное создание программного продукта заданного качества. С точки зрения заказчика, качество продукта определяется набором функциональных возможностей этого продукта, используя которые заказчик может гарантированно (т.е. надежно) решать свои проблемы. И конечному функциональному заказчику не важно, в рамках каких договорных отношений была создана требуемая функциональность. Так же, как не важно для летчика знание перечня субподрядчиков, привлеченных для создания его самолета.

С учетом этого определение границ проекта JIRA должна обеспечить гармонию между двумя следующими соображениями.

Независимо от вида договорных отношений с заказчиком входной точкой процесса создания программного продукта является любое требование на его модификацию. Завершающим мероприятием — получение подтверждения заказчика, что данное требование реализовано (или признано несостоятельным). Это правило является основным для оценки полноты планирования и завершенности задач в проекте JIRA.

Источник: Сергей Архипенков. Оценка проектов: шарлатанство или шаманство

Стоит подумать о формировании отдельных проектов JIRA для регистрации результатов работ, регулярно выполняемых в рамках нескольких программных продуктов (например, учета времени сотрудников, потраченного на изучение новых технологий или работ, связанных с резервным копированием).

Одним из ограничений на проект JIRA может быть максимальное количество сотрудников проектной группы. Личный опыт подсказывает следующий вывод: максимальный состав группы разработки на одном проекте JIRA подчиняется правилу Миллера (в лучших традициях Agile). Под группой разработки здесь понимаются программисты и аналитики, которые формируют постановки задач для них. И, конечно, руководитель проекта. (Как вы могли подумать! Это святое!) При этом, если бюджет проекта позволяет, оставшиеся 80% сотрудников проектной группы, состоящие из приветливых девушек группы сопровождения, ворчливых тестировщиков, нудных технических писателей и веселого сисадмина, безболезненно и гармонично могут быть включены в проект JIRA.

Как разложить задачи по полочкам

В моём чердаке только необходимые мне инструменты. Их много, но они в идеальном порядке и всегда под рукой.
Шерлок Холмс

На любом проекте навигация сотрудников в потоке решаемых задач является одной из важных составляющих успеха. Однако с ростом объема проекта разобраться в этом потоке становится все сложнее, что может стать, само по себе, одной из проблем управления большим проектом. Поэтому определение единой системы координат, по которым одинаково просто могли бы ориентироваться все ключевые участники, является неотъемлемой частью автоматизации управления проектом.

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

Кроме того, в качестве дополнительных координат в рамках проекта были приняты основные объекты базы данных и автоматизируемые бизнес-процессы. Для навигации в рамках этого пространства координат были сформированы соответствующие классификаторы, сопровождение которых обеспечивалось руководителем и аналитиками проекта. Каждый элемент классификатора состоял из кода и его определения.

В ходе моих проектов для каждого классификатора постепенно были выявлены свои особенности, которые стоит учесть в случае, если вы решите применять у себя подобный подход.

Любителям комфорта в этой связи, возможно, может здорово помочь плагин Subcomponents for JIRA.

Необходимо отметить, что применение правильно составленных классификаторов компонентов программного обеспечения неявно стандартизирует коллективное сознание и язык общения проектной группы, в результате чего повышается общий уровень взаимопонимания. С другой стороны, этот подход является одним из методов ненасильственного принуждения аналитиков к большей детализации задач, что, в свою очередь, повышает точность оценки сроков реализации требований на проекте.

Принятые правила классификации задач не только сокращают время, затрачиваемое на поиск, но и обеспечивают возможность автоматизации:

Связывая задачи, не свяжите себе руки

JIRA «из коробки» предлагает пользователю несколько различных типов связей между задачами, и бесконтрольное использование этих связей может привести к печальным последствиям. Чтобы не запутать себя и окружающих, мы согласовали следующие основные правила связывания задач JIRA.

Workflow на все случаи жизни

Причина многих бед заключается в том, что мы ставим в план столько задач, сколько нам надо выполнить, а не столько, сколько мы можем выполнить.
Максим Дорофеев

Согласно предложенному подходу для всех типов задач, регистрируемых JIRA, присущи одинаковые черты. Прежде всего, для всех типов задач JIRA характерен одинаковый рабочий процесс (workflow). При этом в рамках каждой задачи статус выполнения работы определялся прежде всего с точки зрения исполнителя этой задачи.

В ходе унификации задач для нескольких проектов ранее приведенный рабочий процесс был модернизирован. Главным изменением явилось введение дополнительного статуса «оценка» предназначенного для преодоления проблемы описанной в эпиграфе к разделу. С одной стороны, задачи в данном статусе уже зарегистрированы в JIRA и не пройдут мимо внимания руководителя проекта. С другой стороны, эти задачи еще не пугают отвлекают ответственных исполнителей.

Также, статус «план» был переименован в «назначено», поскольку такое название оказалось более толерантным по отношению к задачам типа «требование» (для случая когда для требования формируется проектное решение, а задачи по реализации еще не запланированы).

В ходе комплексного анализа нескольких проектов были определены атрибуты, которые присущи для всех типов задач.

* особенности атрибутов предполагается обсудить в ходе формирования спецификации для каждого из перечисленных типов задач

Изменение общих для всех задач атрибутов при переходах из состояния в состояние описывается следующей таблицей, где:

— возможно изменение атрибута;

— требуется обязательный ввод данных;

— значение поля очищается.

Переходы «в работу» и «отложить» в таблице не описаны. Данные переходы доступны только исполнителю, изменение атрибутов задач при этих переходах не предполагается. Также не описан переход «эксгумировать». Как видно из названия, использование данного перехода крайне нежелательно. Данный переход используется администратором проекта только в случае заведомо ошибочного перевода задачи в статус «закрыто» (при данном переходе запрашивается только регистрация причины этого перехода).

Продолжение следует

В последнее время получила широкое распространение концепция управления BPM (business process management), системно рассматривающая деятельность компании через призму процессов. Идеология BPM положена в основу множества современных «библий» по управлению, таких как:

Декларации о применении процессного подхода в управлении совсем не означают использование принципов BPM на деле. Опыт моих программных проектов говорит, что, как правило, проектная команда так занята автоматизацией BPM в интересах заказчика, что не имеет времени для использования этих принципов в интересах оптимизации собственной деятельности.

Изначально описываемый здесь вариант применения JIRA имел основной целью снижение головной боли сотрудников проектной команды от управления программным проектом. Однако, постепенно модифицируя проект JIRA в ходе решения конкретных прикладных задач управления проектом, появилось осознание, что сформированная модель данных проекта достаточно полно отражает сквозные процессы создания программного обеспечения. Это в свою очередь создает все предпосылки для роста эффективности проектных групп на основе применения механизмов BPM. При этом представляется, что возможности JIRA вполне позволяют обеспечить последовательное созревание процесса разработки программного обеспечения без использования специализированных BPMS. Все дальнейшие предложения по использованию JIRA для автоматизации управления программными проектами будут сделаны с учетом этого ключевого соображения.

Один из первых шагов по лестнице CMMI состоит в выявлении, документировании и унификации процессов организации. Поэтому в рамках цикла статей «JIRA: правила своевременного приготовления вкусного ПО» предполагается последовательно сформировать спецификации по всем типам решаемых задач и попытаться сформировать критериальный аппарат их комплексной оценки с точки зрения процессного подхода. Следующая статья будет посвящена особенностям регистрации задач типа «требование» и бизнес-процессам по их реализации.

P.S. Эта статья входит в цикл статей под названием «Правила своевременного приготовления вкусного программного обеспечения» который я использую как неформальный регламент команды на заказных программных проектах в интересах государственных организаций. В этот цикл входят следующие статьи:
— «JIRA как средство от бессонницы и нервных срывов» — основная идея по организации работ на проекте с использованием JIRA;
— «JIRA: границы проекта» — основные положения по унификации проекта и общие требования ко всем типам задач JIRA;
— «JIRA: управление требованиями» — ключевые особенности регистрации, уточнения и контроля реализации требований заказчика в рамках предложенной модели;
— «Проектные решения: игра по твоим правилам» — основные аспекты управления аналитической работой и формирования постановок задач для разработчиков;
— «Матрица компетенций аналитика для самурая в запасе» — критерии оценки уровня зрелости аналитиков на заказных программных проектах;

В рамках этого цикла настоящее время готовится к публикации:

— «Отчетность для неправильного руководителя» — отчетность по результатам работ сотрудников программного проекта.
— «Где прячутся неприятности на проекте» — критерии (метрики) оперативной оценки текущего состояния программного проекта.
— «Невыносимая легкость внедрения в эксплуатацию» — простые решения сложных проблем при внедрении в эксплуатацию заказного программного обеспечения.

Основной лейтмотив этой серии статей — обеспечить эволюционное совершенствование качества программных проектов на основе повышения эффективности управления. Другими словами — сформировать прикладные способы роста по уровням модели CMMI.
Если вы придумали как эффективней использовать JIRA на своем программном проекте — делитесь своими идеями. Только в описании этих идей избегайте словосочетания «как-нибудь» и «как-то». Приглашаю к обсуждению всех. Жду замечаний/предложений/сомнений/пожеланий в комментариях.

Источник