система jira что это
Краткий обзор Jira
Jira — это набор agile-решений для управления работой, который обеспечивает совместную работу между всеми командами, начиная с разработки идеи продукта и заканчивая его поставкой клиенту, а также позволяет вам вместе добиваться наилучших результатов. Jira предлагает ряд продуктов и вариантов развертывания, специально разработанных для команд разработчиков ПО, ИТ-команд, бизнес-команд, операционных команд и т. д. Информация, приведенная ниже, поможет сделать правильный выбор.
О семействе продуктов Jira
С помощью Jira команды могут планировать, назначать и отслеживать работу, а также управлять ею и создавать отчеты. Jira позволяет объединяться для любой работы, от agile-разработки ПО и поддержки клиентов до организации стартапов и крупных предприятий.
Команды разработчиков ПО работают лучше с помощью Jira Software — лучшего инструмента для agile-команд. Предоставляйте обслуживание высочайшего уровня ИТ-командам, командам разработчиков, а также операционным и другим командам с помощью Jira Service Management. Бизнес-команды могут открыть возможности методики Agile и повысить эффективность совместной работы с помощью Jira Work Management. Кроме того, существует Jira Align — платформа для корпоративного agile-планирования и координации работы при любом масштабе.
Шаблоны и решения, разработанные для каждой команды, а также Jira в качестве общего инструмента обеспечивают легкость и прозрачность работы в вашей организации.
Обзор продуктов Jira
Для всех участников agile-команды и не только: планируйте, отслеживайте и выпускайте ПО мирового уровня.
Теперь клиентам проще обращаться за помощью, а сотрудникам поддержки — оказывать ее.
Управляйте любым бизнес-проектом, включая рекламные кампании, набор персонала, согласование и утверждение юридических документов.
Платформа для корпоративного agile-планирования — связующее звено между стратегиями на уровне продуктов, программ и портфелей и техническим воплощением при любом масштабе.
Пользователи
Примеры использования
Размещение
Лицензирование
Основные интеграции для Jira Software
Пользователи
Примеры использования
Размещение
Лицензирование
Пользователи
Примеры использования
Размещение
Лицензирование
Основные интеграции для Jira Work Management
Пользователи
Примеры использования
Размещение
Облако, выделенное облако
Лицензирование
Пользователи Jira Align Standard имеют доступ ко всем функциональным возможностям программных и (или) командных модулей для совместного планирования, управления, реализации, анализа, создания отчетов и наглядного представления данных.
Пользователи Jira Align Enterprise имеют доступ ко всем функциональным возможностям версии Standard, а также модулям решений, портфелей и корпоративным модулям.
Основные интеграции для Jira Align
Варианты размещения Jira Software
Решение Jira Software предполагает два варианта размещения: в облаке и на собственном хостинге. Не уверены, какой вариант лучше выбрать? Ознакомьтесь с обзором ниже.
Cloud
При покупке версии Cloud мы выполняем для вас размещение и настройку сайта Jira Software в облаке. Этот вариант подходит командам, которые хотят приступить к работе как можно быстрее или не хотят тратить время и силы на техническое обеспечение самостоятельного хостинга. Подробнее
Data Center
При выборе версии Jira Software Data Center можно разместить Jira Software на собственном оборудовании или у поставщиков IaaS-инфраструктуры, например AWS или Azure. Этот вариант, как правило, подходит корпоративным командам, которым нужен постоянный доступ к Jira Software и высокая производительность при любом масштабе. Подробнее
Основные понятия
Неполадки
«Задача» Jira обозначает отдельную рабочую задачу любого типа или размера, которая отслеживается от создания до завершения. К примеру, задачей может быть функциональная возможность, которую разрабатывает команда разработчиков, или задача, стоящая перед командой маркетологов, или контракт, который необходимо составить команде юристов.
Подсказка: для обозначения задач используются также термины «запросы», «заявки» или «задания». Мы рекомендуем все-таки называть их «задачами», чтобы избежать путаницы в команде при работе с семейством продуктов Jira.
Проекты
Проект, если подходить просто, — это совокупность задач, объединенных общей целью или контекстом. Задачи, сгруппированные в проекты, можно настраивать различными способами. Можно ограничить видимость задачи, можно привязать задачу к существующим рабочим процессам.
Проекты Jira Software — это адаптируемые рабочие пространства, позволяющие группировать похожие задачи по командам, бизнес-подразделениямм, продукта или направлениям деятельности. Проекты не обязательно прикреплять к одной дате поставки. Например, сгруппировав задачи по команде, вы можете получить проект по маркетингу, проект по разработке и проект юридического характера, в каждом из которых будет отслеживаться работа соответствующих команд. Каждая задача будет отмечена ключами задачи (у каждого проекта свои ключи) и номером задачи, например MKT-13, DEV-4, LEG-1.
Доски
Доска в Jira Software является элементом проекта и служит для отображения задач. Это гибкий инструмент, позволяющий следить за ходом работы, управлять им и создавать отчеты. Другими словами, на доске визуально представлен рабочий процесс команды в рамках проекта.
Процессы
Рабочий процесс представляет собой поэтапный путь, который проходит задача от создания до завершения. Классический рабочий процесс может выглядеть примерно так:
Здесь Open (Открыто), Done (Завершено) и все промежуточные метки обозначают статус, который задача может принимать, а стрелки обозначают возможные переходы из одного статуса в другой. Рабочие процессы могут быть простыми или сложными, содержать условия, триггеры, валидаторы и пост-функции. Такие сложные конфигурации будут рассмотрены в этом руководстве далее. На данном этапе администраторам, впервые работающим с Jira Software, рекомендуется не усложнять рабочие процессы, если сложный рабочий процесс не является изначальным требованием бизнеса.
Гибкая методология Agile
Термин agile не относится напрямую к Jira Software. Это рабочая методика, сложившаяся в сфере разработки ПО и впоследствии перенесенная во многие другие отрасли. Мы не будем специально останавливаться на определении (для этого есть другие специализированные ресурсы по agile). Скажем лишь, что agile опирается на итеративный подход к работе, обратную связь с клиентами и непрерывную инкрементальную поставку результатов работы. Идеальная agile-команда способна действовать быстро и приспосабливаться к меняющимся требованиям без существенного снижения скорости работы.
Мы затронули здесь тему agile неспроста. Основные наборы возможностей Jira Software были разработаны специально для работы по методикам agile, в том числе scrum и kanban. Поэтому, встретив такие понятия, как «доски», «оценка» или «карточки», задумайтесь, подходят ли для вашего порядка работы принципы agile.
Помните, что agile — это философия и культура работы, поэтому само по себе использование Jira Software не означает, что ваша команда теперь придерживается этих принципов. Это инструмент, который поможет вашей команде приобщиться к agile.
С помощью Jira Software команды, следующие принципам Agile, могут работать еще эффективнее. Для получения дополнительной информации ознакомьтесь с рекомендациями по использованию методик Agile для Jira. Перейти к руководству.
Jira: что это за программа и как в ней работать
Разбираем, как работает один из таких сервисов – Jira.
Что такое Jira
Jira – это программа для командной работы над проектами, разработка компании Atlassian. В каждом проекте можно изменять функционал под основные задачи и настраивать доступ участников. Jira Mobile – мобильная версия, в которой удобно обмениваться новыми данными и проверять, на какой стадии разработки находится продукт.
Для чего используют Jira
В Jira ведут проекты от идеи до полной разработки. Какие задачи помогает решать Jira:
Преимущества и недостатки сервиса
Что привлекает пользователей:
Как устроена Jira
Это сложный и мультиопциональный сервис. Разберем каждый компонент, чтобы понять, как устроена Jira.
Интерфейс
Задачи
В приложении задачи называются Issues. В них прописывается проблема, которая требует решения, или ошибка, которую нужно исправить. Issues – это составные части проекта и спринта.
Типы задач
Готовые варианты: новая функция, подзадача, баг или эпик. В настройках проекта можно задавать собственный тип задач при необходимости. Категории можно фильтровать по важности и быстро находить нужные задачи.
Дорожная карта (расписание)
Чтобы ее создать, откройте справа вкладку Roadmap. Внутри дорожной карты нажмите Create Epic и объедините несколько задач в эпики. Затем команда устанавливает зависимости – связи между эпиками. Разработчики адаптируются под зависимости и планируют альтернативные пути. Картой можно поделиться, добавить в презентацию или распечатать.
Релизы
Новые версии проекта разработчики отправляют пользователям в приложение. В Jira есть контроль новых версий и список всех релизов. Его можно открыть, нажав на значок корабля.
Код и деплой
Приложение интегрируется с системы управления версиями программного кода: Bitbucket, Github и Gitlab. Лидеры команд могут отслеживать изменения в коде.
Pages
Эта функция напоминает Google Docs, но с меньшим функционалом. Это текстовый редактор с основными возможностями форматирования текста. В нем предусмотрены шаблоны, которые можно применять по умолчанию и редактировать под себя. Например, формы для тестирования и составления расписания.
Дашборды
Дашборд – это рабочий стол в Jira. Он формируется автоматически, корректировки вносятся вручную.
Их там много, выберите актуальные для вашего проекта. Достаточно 5–7. Например: «Лента активности» (Activity Stream), «Назначено мне» (Assigned To Me), « Задачи в процессе» (In Progress), «Статистика задач» (Issue Statistics), «Дорожная карта» (Roadmap).
Плагины
Atlassian продвигает дополнительные плагины сторонних программ, которые можно подключить к Jira. Например, Hip-Chat – плагин, который отправляет оповещения и помогает команде оставаться на связи, или Gliffy Diagrams – инструмент для создания диаграмм.
Виджеты Calltouch
Как создать задачу в Jira
Атрибуты задач
В новую задачу можно добавить дополнительные атрибуты:
Настройка отчетов
Burnup report
Этот отчет отражает объем выполненной работы и сравнивает его с запланированной. Чтобы определить отклонение от плана, проанализируйте график:
Sprint burndown chart
В графике видно работу членов команды и общую производительность по срокам. Также он помогает рассчитать примерное число подготовки проекта.
Velocity report
Этот график показывает скорость команды. Здесь руководители могут увидеть каких сотрудников стоит добавить, чтобы увеличить темп работы и сколько времени оставить для следующего проекта.
Cumulative flow diagram
Лидеры команды могут посмотреть изменения статуса каждой задачи на протяжении всего проекта. Также отчет покажет, какие задачи оставались невыполненными дольше всего. Здесь можно увидеть проблемные места всего проекта и корректировать процесс.
Отслеживайте общие показатели вашего бизнеса со Сквозной аналитикой Calltouch. Она поможет узнать, какой рекламный канал работает лучше. Вставьте скрипт в код вашего сайта, подключите CRM и получайте понятные и полезные отчеты. Настройка сервиса займет всего 20 минут. Две недели аналитики – бесплатно.
Сквозная аналитика
Алгоритм работы с Jira
С чего начать и как работать:
Как повысить производительность
Есть лайфхаки, которые упрощают работу в Jira. Используйте их, чтобы создать идеальный рабочий процесс для своей команды. Самый простой трюк – используйте горячие клавиши. Рассмотрим, как еще можно оптимизировать разработку проекта:
Стоимость Jira
Бесплатный тариф ограничивает число участников до 10 и память до 2 Гб.
Вы можете рассчитать стоимость на каждого пользователя.
Аналоги Jira
Если считаете Jira слишком сложным или вам наоборот не хватает функций, попробуйте аналоги:
JIRA как средство от бессонницы и нервных срывов
Как наладить эффективный процесс управления проектом в условиях, когда «правильно» и «как лучше» сделать нельзя, но делать все равно надо? В статье дан обзор применения JIRA для управления проектом по разработке программного обеспечения в интересах крупного государственного заказчика. Я буду рад, если описанные подходы помогут лично вам повысить эффективность своей команды и снизить напряженность на проекте. Приветствуется любая критика.
Сын ошибок трудных
Судя по большому количеству типовых статей в Интернете о том, как нужно правильно применять системы управления проектами при разработке программного обеспечения, дело это нехитрое и благодарное. Однако реальное применение автоматизированных систем управления в проектах, в которых довелось поучаствовать, было не таким «радужным», как можно было бы ожидать. Можно выделить несколько типовых случаев, с которыми пришлось столкнуться на практике.
Лучшие варианты сводились к использованию проектной командой одной из многочисленных систем отслеживания ошибок (bug tracking system). Структура задач и бизнес-процессов проекта обычно разворачивалась «из коробки». Данные системы использовались в основном группами программистов и тестировщиков. Такая организация разработки хорошо себя оправдывала на небольших проектах с частными заказчиками или если в задачи исполнителей входило только гарантийное сопровождение программного продукта (исправление выявленных ошибок). Однако с ростом новых требований такой подход начинал буксовать. Это проявлялось в росте временных затрат на сопоставление требований заказчиков и сведений, сохраненных в багтрекере (и ручном составлении интегральных отчетов), а также в разделении команды на два лагеря («хороших» программистов и «плохих» аналитиков).
Другие ситуации сводились к «гениальным» озарениям руководства, когда, используя административные рычаги, в деятельность проектных групп «внедрялись» лучшие методологии разработки программного обеспечения. Правда, эти руководители считали, что их действия ограничивались только процессом нахождения этой «серебряной пули». Они не заморачивались такими понятиями, как «спринт», «диаграмма сгорания задач» или «диаграмма совокупного потока». А даже если и заморачивались, отчетные документы, которые требовалось формировать о состоянии проекта (опять же вручную), были слабо связаны с этой самой лучшей методологией. Попытки приобщить заказчиков к этим методикам приводили к тому, что условия проекта не менялись, а к старым отчетам дополнительно требовалось формировать новые дополнительные отчеты (по новой методике). Особенно ярко такие противоречия проявлялись на проектах по госконтрактам, условия организации которых напрямую конфликтовали с условиями успешности применения Agile, RUP или PMBOK.
Апофеозом автоматизации управления стал проект по доработке информационной системы федерального уровня в интересах одного крупного государственного заказчика. В рамках этого проекта сам заказчик использовал HP Service Manager и JIRA. HP Service Manager использовался для сбора и анализа ошибок программного обеспечения. C помощью JIRA заказчик планировал деятельность своих сотрудников, связанную с исправлением этих ошибок и дальнейшим развитием системы. Перечень состояний задач в этих системах предусматривал все многообразие возможных вариантов их обработки. Подробнейшие регламенты сопровождения этих задач, сформированные проектным офисом заказчика (т.е. людьми, не отвечающими за сопровождение и разработку), были размещены на платформе Confluence. Сотрудники исполнителя были допущены к обеим системам, и на них были возложены обязанности по сопровождению инцидентов и требований (с временными нормативами по обработке задач и прогрессивной шкалой штрафов). Кроме того, на площадке исполнителя был развернут свой экземпляр JIRA, с помощью которого планировалась деятельность проектной группы. Синхронизация деятельности всех трех систем осуществлялась вручную (для этого приходилось вести «простыню» в Excel, в которой отмечались взаимосвязи задач и их текущее состояние). Кроме того, отчеты, которые формировала JIRA, руководство не устраивали, и поэтому сотрудники проектной группы должны были предоставлять почасовые отчеты о своей деятельности, также создаваемые ими вручную в Excel. Не редкостью была ситуация, когда руководитель группы разработки или руководитель групп сопровождения «зависали» на работе до поздней ночи, формируя сводные отчеты о состоянии проекта по результатам деятельности проектной команды. Данный проект был успешно завершен точно в перенесенные сроки и запомнился, кроме рекордно низкой производительности, повышенным количеством нервных срывов, стремительным профессиональным выгоранием и, судя по премиям «выживших» сотрудников, неожиданно невысокой маржинальностью. После таких проектов долго не дает покоя мысль: «Если мы создаем инструменты, которые значительно облегчают жизнь заказчиков, то почему, за счет подобных инструментов, мы так изощренно ухудшаем свою жизнь?»
Особенности национальной разработки
Обобщая опыт, можно сделать вывод, что наибольшие проблемы с автоматизацией управления разработкой программного обеспечения происходили на проектах по госзаказу.
При этом неоднократные попытки решить эти проблемы в соответствии с лучшими практиками разработки программного обеспечения, привели к выводу: это не проблемы, а неизбежные условия выполнения проекта для госзаказчика. Анализ нескольких проектов позволил выделить следующие обобщенные характерные черты таких условий:
Кроме внешних условий, как выяснилось, общими характерными чертами обладают и коллективы сотрудников, вовлеченных в проект по созданию программного обеспечения.
Победа надежды
Второй брак – это победа надежды над жизненным опытом.
Сэмюэл Джонсон
Два года назад я был приглашен в качестве ведущего аналитика на проект, выполняемый компанией ЛАНИТ по госзаказу. Проектная группа была сформирована ранее, проект заключался в существенной доработке автоматизированной системы, существующей более десятка лет. В целом, условия проекта соответствовали описанным выше. На тот момент коллектив разработчиков не применял в своей работе ни одну из существующих систем управления проектами (хотя практически все сотрудники участвовали в проектах, где такие системы использовались и имели довольно скептическое мнение о необходимости автоматизации управления). Однако сложившаяся исходная ситуация предоставила возможность выпестовать автоматизацию управления проектом «с чистого листа».
В качестве платформы для автоматизации была выбрана JIRA. Этому выбору поспособствовала совокупность следующих факторов:
Автоматизация управления проектом изначально преследовала следующие цели:
Автоматизация управления проектом не должна раздражать сотрудников проектной команды. Учитывая предыдущий негативный опыт автоматизации управления проектами, одним из ключевых факторов внедрения стало создание таких условий, чтобы каждый сотрудник проектной группы воспринимал JIRA не как лишний груз в лодке проекта, а как коллективную навигационную систему, которая своевременно оповестит команду о приближающейся опасности и поможет достичь цели проекта по кратчайшему и безопасному пути. При этом использование этой навигационной системы должно облегчить жизнь всех членов команды, а не только менеджмента проекта. Для этого изначально порядок работы с JIRA планировался с учетом минимизации количества регистрируемых данных со стороны программистов, тестировщиков и технических писателей. С другой стороны, преследовалась цель создать комфортное рабочее окружение в JIRA для всех сотрудников проекта, которое помогало бы им обеспечить эффективное планирование своего рабочего дня.
Гарантии преемственности. Одной из целей автоматизации управления проектом является обеспечение преемственности, чтобы любой квалифицированный сотрудник мог «подхватить» обязанности выбывшего члена команды без «испытательного срока» и с минимальной головной болью, чтобы «отряд не заметил потери бойца». В этой связи вспомнился случай, который мне рассказал один из заказчиков. Однажды он остался за начальника, который, уехав в отпуск, сообщил ему пароль от своего компьютера с репликой: «Ну, там все понятно, разберёшься в случае чего…». Этот сотрудник потратил несколько бессонных ночей на осознание содержания нескольких папок с названиями «xxxxx1», «xxxxx11» и «xxxxx111» (названия папок изменены, в интересах соблюдения правил приличия). Предотвращение таких ситуаций требует регистрации в JIRA результатов работы всех сотрудников проектной команды, включая руководителя проекта.
Минимализм. Цель автоматизации управления проектом состояла не в том, чтобы посчитать с точностью до минуты, сколько тот или иной сотрудник потратил рабочего времени на решение поставленных перед ним задач, а в том, чтобы обеспечить решение задач с заданным качеством в требуемые сроки. Поэтому при развертывании проекта в JIRA был принят принцип минимизации данных, регистрируемых в системе. Т.е. набор параметров, регистрируемых в системе управления, должен был быть минимально необходимым для принятия обоснованных решений («Совершенство достигнуто не тогда, когда нечего добавить, а когда нечего убрать»). При этом подразумевалось, что принятая модель автоматизации управления проектом должна работать в условиях высокой неопределенности и непоследовательности (например, можно знать дату документа, но не знать его номер и наоборот). При типизации регистрируемых сведений использовалось, где только возможно, правило Миллера, говорящее о том, что оптимальное количество типов (состояний) должно лежать в пределах «семь плюс-минус два» (что значительно упрощает понимание работы системы сотрудниками). Так, например, при проектировании жизненного цикла задач (workflow) изначально предполагалось, что количество состояний должно соответствовать данному правилу.
Системность. Автоматизация управления проектом должна способствовать согласованности и слаженности действий всех сотрудников проектной команды (предотвращение ситуации «лебедь, рак и щука»).
В одном из проектов, в котором мне довелось поучаствовать, команда аналитиков в течении месяца разрабатывала модель автоматизируемой деятельности в нотации IDEF0. Как казалось, само использование методологии, созданной ВВС США (!), гарантировало успешность такого подхода. Однако, когда многостраничный аналитический отчет изучил начальник отдела программирования, его первым вопросом был: «Так, что собственно надо сделать?». Сформированная модель оказалась непригодной для использования, как описание постановки задач для программистов. Представители заказчика несколько раз восхитились, бегло просматривая многочисленные схемы, однако также не нашли применения этой модели для оптимизации своей деятельности. В конце концов эти схемы украсили описание технологических процессов, придав этому документу невиданную доселе толщину и солидность, однако на этом положительный эффект проведенного анализа был исчерпан. Результаты месяца работы нескольких аналитиков фактически оказались невостребованными в рамках проекта.
Учитывая этот опыт, при автоматизации управления проектом, предполагалось создать единый конвейер задач, который бы обеспечил согласованное преобразование требований заказчика в конечный программный продукт по кратчайшему пути и с минимальными издержками. При этом, на основе мониторинга имеющихся параметров этого конвейера, предполагалось выявить, измерить и развить эмерджентные свойства проектной группы, по которым можно было судить о состоянии проекта на всех его этапах.
Канбан-доска наизнанку
По моему убеждению, успех автоматизации управления в решающей степени зависит от того, насколько точно смоделирован объект управления в автоматизированной системе. Поскольку предполагалось автоматизировать управление процессом создания программного обеспечения, был проведен анализ этого процесса. На мой взгляд, процесс создания отдельных программных модулей всегда представляет классический каскадный жизненный цикл waterfall. Сначала появляется перечень требований к создаваемому продукту. Требования могут приходить из разных источников и имеют разную степень детализации. Часть требований взаимосвязаны между собой, другая часть относительно независима. По отдельным требованиям можно сразу сформировать задачу на разработку, другие — требуют уточнения и конкретизации. Т.е. всегда существуют работы, связанные со сбором, сортировкой и уточнением требований заказчика (при этом формулировки отдельных требований могут носить неоднозначный характер до окончания проекта). После того, как требования максимально конкретизированы, как правило, по группам взаимосвязанных требований формируются так называемые описания постановки задач, которые детализируют особенности реализации этих требований и являются исходным материалом для начала работы программистов. После окончания программирования созданные модули тестируются автономно, интегрируются в систему, тестируются повторно. По выполненным доработкам ПО вносятся соответствующие изменения в проектную и эксплуатационную документацию, после чего проводится ряд мероприятий, направленных на признание выполненной доработки чаяниям (требованиям) заказчика и последующее внедрение разработанного функционала в промышленную эксплуатацию.
Главным отличием реальной жизни от красивой схемы waterfall является ее хаотичность (все происходит не поэтапно и непоследовательно). В реальности, переход от одной фазы разработки к другой совсем необязательно происходит только после полного и успешного завершения предыдущей фазы. В реальном waterfall есть свои обратные течения противоречий, заводи и мели безразличия, топи словоблудия, стремнины и водовороты неоднозначности, пороги и скользкие камни безудержной фантазии, и, нередко, фонтаны и даже гейзеры новых требований. Переделать эту стихию в рамках проекта не представляется возможным, как невозможно для команды корабля переделать реку, по которой надо обеспечить доставку грузов заказчика.
Для прозрачности распределения ответственности при автоматизации управления проектом был реализован принцип «1 задача – 1 исполнитель». Т.е. процесс выполнения задачи заведомо не предполагал ее передачу другим исполнителям. Этот принцип позволил применить одинаковый бизнес-процесс ко всем типам задач, поскольку статус выполнения работы определялся прежде всего, с точки зрения исполнителя этой задачи. Стандартный для JIRA рабочий процесс (workflow) был немного изменен. Главное изменение заключалось в замене статуса «переоткрыт» на статус «в ожидании», т.е. состояния, когда работы по задаче приостановлены по какой-либо причине. Для регистрации переоткрытых задач стало применяться пользовательское поле «Счетчик переоткрытий». При этом, были детализированы виды причин перевода задач в ожидании решения:
В результате проведенного анализа была реализована следующая модель регистрации сведений о проекте в JIRA. Стандартный подход деления задач, который представляла JIRA, не был использован в проекте. Было создано шесть типов задач, которые по своей сути соответствовали основным этапам разработки программного обеспечения:
Найденные в JIRA способы отражения задач не предоставляли удобного просмотра состояния проекта в целом (учитывая многообразие плагинов, возможно нам просто не хватило времени, чтобы найти нужный). Поэтому для того, чтобы упростить работу с предложенной моделью регистрации задач, был создан собственный дашборд (в конце концов, сапожник должен уметь сшить сапоги и для себя). Созданный дашборд позволял отобразить состояние задач на проекте с позиции реализации каждого требования отдельно.
Созданный дашборд, на первый взгляд, слабо отличался от классической Канбан-доски, однако в нашем случае столбцы означали не статус выполнения задач, а их тип. В этом дашборде для каждого требования формировалась отдельная строка, в которой были отражены все связанные с этим требованием задачи, сгруппированные по видам деятельности (в классической последовательности waterfall). Если задача была создана в интересах выполнения нескольких требований, то карточка этой задачи повторялась в каждой из строк связанных требований. Статус выполнения задач отражался на данном дашборде цветом, который создавал «третье измерение». Степень готовности требования определялась при этом готовностью всех связанных с этим требованием задач. Получилась как бы Канбан-доска вывернутая наизнанку. С другой стороны, с позиции положений PMBOK, сформированный дашборд представлял собой усовершенствованный вариант классической матрицы отслеживания требований (Requirements Traceability Matrix).
Для отображения статуса выполнения задач была принята следующая цветовая схема:
Кроме цветов, по мере развития проекта, карточки задач на дашборде обрастали дополнительными метками, которые позволяли с первого взгляда оценить состояние выполнения работ по проекту.
— обычный;
— важный;
— критический;
— блокирующий.
Метки о рамках требования:
— развитие (требования в рамках проектов, направленных на существенную доработку существующих систем);
— расширенное сопровождение (требования по оперативной доработке отдельных модулей системы по текущим изменениям бизнес-процессов заказчика);
— гарантийное сопровождение (выявлены ошибки программного обеспечения);
— внепроектная деятельность (требования руководителя проекта, связанные с предпроектной деятельностью, рефакторингом, пресейлом, освоением новых технологий, обучением сотрудников и т.п.).
Метки причины ожидания:
— запрос дополнительных сведений у заказчика;
— согласование с заказчиком;
— ожидание решения связанных задач/подзадач;
— требуется уточнение постановки.
— в задаче была доработана база данных;
— количество связанных с задачей требований (чем больше связанных требований, тем более важно выполнение задачи);
— количество нерешенных подзадач;
— задача переоткрыта.
Фактически, этот дашборд стал основным инструментом для ежедневного получения ответа на вопрос управления проектом: «А что у нас сегодня самое важное?», что позволило в свою очередь своевременно реагировать на возникновение проблем. С позиций предложенной модели, для предотвращения проблем на проекте, необходимо ежедневно обеспечивать снижение количества красного, оранжевого и желтого цвета на предложенном дашборде. С другой стороны, поводом для беспокойства также являлось отсутствие связанных задач для требования (т.е. ситуация, когда требование запланировано, а работы по его реализации — нет).
Использование фильтров для созданного дашборда позволило в комплексе отражать состояние дел по выбранному перечню требований. С его помощью удавалось оперативно координировать действия всей проектной группы, сосредотачивая усилия на наиболее проблемных участках, при этом не утрачивая целостной картины проекта.
Waterfall нельзя Agile
В интересах регистрации результатов работ по всем типам задач были развернуты два репозитория (для документации проекта и для кода программного обеспечения). Добавление (изменение) материалов в этих репозиториях автоматически отражалось в связанных задачах JIRA и являлось основным видом отчетности исполнителей.
Организация работ с использованием предложенного подхода регистрации задач в JIRA, сводилась к следующей схеме.
В рамках предложенного подхода хорошо зарекомендовало себя планирование работ с использованием метода «набегающей волны» (Rolling Wave Planning). При этом, отчасти благодаря вышеописанному дашборду, удавалось избегать разрозненности и несогласованности планируемых работ. На начальных этапах регистрации выборка по требованиям напоминала красный зонтик, когда для большинства требований не определены сроки готовности и ответственные исполнители, а работы запланированы только по их малой части. Однако постепенно дашборд требований превращался в сине-зеленый ковер. Появляющийся на этом ковре красные и оранжевые пятна заставляли проводить ежедневную корректировку намеченных задач, что способствовало снижению проектных рисков.
Предложенная модель организации данных показала хорошую масштабируемость. Изначально в своей работе JIRA использовали только три сотрудника из проектной группы (один аналитик и два программиста), при этом регистрировались требования по отдельным подсистемам. Однако к окончанию проекта 100% требований на развитие и на расширенное сопровождение регистрировалось и отслеживалось в JIRA с участием всех сотрудников проектной группы.
Несмотря на то, что замысел автоматизации управления проектом базировался на каскадной модели разработки (waterfall), оказалось, что в рамках предложенного подхода, при желании, могут безболезненно применяться элементы Agile. А кто, вообще, сказал, что водопад не гибкий? Например, для применения Scrum, в рамках предложенной модели, достаточно обеспечить регулярность проведения мероприятий (задач) по внедрению программного обеспечения, и тогда, соответственно, все работы, связанные с этим мероприятием, будут «вынуждены» подчиниться правилам спринтов, заданных таким образом.
Кроме этого, предложенный метод регистрации задач не ограничивает руководителя проекта в применении Канбан-подхода и использования всего многообразия Agile-дашбордов, которые предлагает JIRA «из коробки».
Продолжение следует
Что в итоге? Разработанное программное обеспечение принято в промышленную эксплуатацию. В ходе проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний заказчик зафиксировал множество замечаний к реализованному программному продукту. Однако впоследствии на основании материалов уточнения требований, которые хранились в JIRA, 25% замечаний заказчик был вынужден признать как новые требования, выходящие за рамки проекта (планируемая трудоемкость выполнения этих требований была соизмерима с реализованным техническим заданием). Проблемы, связанные с выполнением контракта по госзаказу, не исчезли, однако контроль исполнения требований с использованием JIRA позволил выявлять риски срыва на стадии зарождения и оперативно на них реагировать. Это, в свою очередь, обеспечивало положительную динамику проекта на всех его этапах, несмотря на особенности национальной разработки программного обеспечения. Было замечено, что если требования заказчика зарегистрированы в JIRA и по ним сформированы задачи на анализ, разработку и тестирование, то в отношении таких требований происходило гораздо меньше разногласий и споров.
На текущем этапе (этапе сопровождения) все требования находят отражение в JIRA. Все сотрудники проектной группы так или иначе используют JIRA в своей работе. Затраты программистов на регистрацию результатов своей работы в JIRA отнимают менее 1% их рабочего времени. Для аналитиков, напротив, JIRA стала одним из основных рабочих инструментов. Поиск полного набора сведений по любому из требований заказчика составляет менее минуты. Отчетные документы по результатам выполненных работ формируются автоматически на основании данных, содержащихся в JIRA. Также на основе этих данных формируется сопроводительная документация к релизам (перечень изменений и программа испытаний релиза).
Двухлетний опыт применения JIRA по новым правилам подтвердил старые истины:
P.S. Эта статья является первой из цикла статей под названием «Правила своевременного приготовления вкусного программного обеспечения» который я использую как неформальный регламент команды на заказных программных проектах в интересах государственных организаций. В этот цикл входят следующие статьи:
— «JIRA как средство от бессонницы и нервных срывов» — основная идея по организации работ на проекте с использованием JIRA;
— «JIRA: границы проекта» — основные положения по унификации проекта и общие требования ко всем типам задач JIRA;
— «JIRA: управление требованиями» — ключевые особенности регистрации, уточнения и контроля реализации требований заказчика в рамках предложенной модели;
— «Проектные решения: игра по твоим правилам» — основные аспекты управления аналитической работой и формирования постановок задач для разработчиков;
— «Матрица компетенций аналитика для самурая в запасе» — критерии оценки уровня зрелости аналитиков на заказных программных проектах;
В рамках этого цикла настоящее время готовится к публикации:
— «Отчетность для неправильного руководителя» — отчетность по результатам работ сотрудников программного проекта.
— «Где прячутся неприятности на проекте» — критерии (метрики) оперативной оценки текущего состояния программного проекта.
— «Невыносимая легкость внедрения в эксплуатацию» — простые решения сложных проблем при внедрении в эксплуатацию заказного программного обеспечения.
Основной лейтмотив этой серии статей — обеспечить эволюционное совершенствование качества программных проектов на основе повышения эффективности управления. Другими словами — сформировать прикладные способы роста по уровням модели CMMI.
Если вы придумали как эффективней использовать JIRA на своем программном проекте — делитесь своими идеями. Только в описании этих идей избегайте словосочетания «как-нибудь» и «как-то». Приглашаю к обсуждению всех. Жду замечаний/предложений/сомнений/пожеланий в комментариях.