Почему использовать Jira для ведения проектов неэффективно

Конспект статьи издания TechCrunch.

Изначально Jira предназначалась для отслеживания ошибок, но теперь она также используется для планирования agile-проектов. В результате программа непреднамеренно стала «антипаттерном» (распространённым, но неэффективным подходом к решению часто встречающихся проблем — определение из Wikipedia).

По мнению Джона Эванса, автора статьи на TechCrunch, при разработке программного обеспечения важно помнить не только о деталях, но и об общей концепции. В Jira проект разбивается на задачи, работа над которыми ведётся обособленно. Программа акцентирует внимание на деталях, игнорируя картину в целом. Более того, Jira не поддерживает создание общей инфраструктуры проекта.

Самый большой недостаток Jira Эванс видит в том, что программа требует завершить одни задачи, для того чтобы начать работу над другими. Цикл жизни задачи напоминает принцип работы каскадной модели: спецификация, разработка, улучшение, тестирование, релиз. Но гибкая методология разработки, которая лежит в основе Jira, создана, чтобы отойти от каскада. На деле получается, что один большой каскад заменяется тысячами поменьше.

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

При работе с этой программой проектировщики города должны были бы придерживаться двух правил:

  • районы — главные единицы города;
  • районы строятся по очереди: прежде чем начать новый район, нужно закончить предыдущий, включая работу над деталями (например, озеленение дорог).

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

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

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

Эванс также упоминает, что разработчики часто недовольны тем, как менеджеры разделяют проект на отдельные задачи. Тем не менее, это не вина Jira: проблема возникает из-за самой структуры программы.

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

Он предлагает решение: главную цель проекта нужно описать словами в документе — например, на 10 страниц, а на шести страницах объяснить архитектуру программного обеспечения.

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

0
34 комментария
Написать комментарий...
Alexander Bragin

Jira+Confluence и всё, статья не актуальна. Видимо автор не вкурсе что для решения части проблем Джиры предусмотрены варианты интеграций с over100500 сервисов.

Ответить
Развернуть ветку
Daler Aliyorov

А подскажите, пжл, беспокоит ли вас их тормознутость? И, если да, есть ли у вас какие-нибудь секреты, как заставить Джиру и Конфлюенс работать быстрее?

У меня в среднем страница Джиры загружается и рендерится полностью аж за 14 секунд. Речь идет про облачную версию.

Ответить
Развернуть ветку
Alexander Bragin

У вас какие-то локальные проблемы. Возможно чистится кэш в браущере каждый раз?

Ответить
Развернуть ветку
33_rublya

Ну вот я тоже наблюдаю тормоза при открытии карточек или панели уведомлений.

Ответить
Развернуть ветку
Daler Aliyorov

Не-а. Любопытно, что при каждой загрузке скачивается в среднем около 100–200 KB.

Ответить
Развернуть ветку
Sergey

Переходить на сервер. Облако в плане скорости и доступности в России - это печаль и боль. Сервер гораздо шустрее .

Ответить
Развернуть ветку
Daler Aliyorov

Спасибо за совет, Сергей.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Anton Ilabanau

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

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Вася Бездомный

Менеджер нужен, прежде всего, для управления людьми, то есть, сейчас это скорее гуманитарная должность типа командного психолога, устраняющего препятствия в работе команды (скрам-мастер - как пример) и для работы с высшим руководством компании (чтобы команде не мешали, а наоброт). Таски забивать, тут конечно роботу раздолье.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Вася Бездомный

Так и программистов скорее всего в будущем будет значительно меньше. Это будет должности уровня архитектора с сильным уклоном в инженерные навыки. "Формы шлёпать" буду роботы.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Sergey

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

Ответить
Развернуть ветку
Alexey Sikorskii

Пустая статья. Очевидно что jira используется не для ведения проектов, а для организации процессов и ведения разработки.

PS Все эти теоретики по управлению проектами начинают утомлять

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Никита Теплов

В последний версиях Jira, Atlassian действительно пытается "задвинуть" клиентам, свое "экспертное" видение процессов разработки и проджект-менеджмента, но это не отменяет того, что инструмент так и остался гибчайшим конструктором для абсолютно любых процессов. Это экосистема, которая при наличии специалиста, адаптируется к любым реалиям и процессам.

Ответить
Развернуть ветку
Dmitry Filippov

Открываем Agile Manifesto, читаем первый пункт:
Люди и взаимодействие важнее процессов и инструментов.

Ответить
Развернуть ветку
Вася Бездомный

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

Ответить
Развернуть ветку
Grigory Antonov

Если Джон не умеет работать в джире, это не проблема джиры

Ответить
Развернуть ветку
Сергей Полянин

Jira прекрасна. Автор просто не умеет ее готовить или не понимает, что следует делать в ней, а что около нее.
Ещё позабавило «написать цель проекта на 10 страницах». Цель, Карл!

Ответить
Развернуть ветку
Вася Бездомный

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

Ответить
Развернуть ветку
Сергей Полянин

В статье автор не говорит про устав, он предлагает «решение: главную цель проекта нужно описать словами - например, на 10 страниц»

Ответить
Развернуть ветку
Владимир Лупанов

-> настраиваем в проекте Jira пайплайн этапов задач (формирование, оценка, исполнение)
-> сажаем команду на недельные итерации
-> раздаем каждому исполнителю в проекте по дэшборду-канбану, где можно посмотреть свои задачи, их статус для всех пользователей (исполнение, оценка и т.д.), а также взять в работу и отдать в "Готово"
-> покупаем плагин за 15$ и дописываем необходимые автоматизации к пайплайну (время работы, автоматическое назначение исполнителя в зависимости от этапа)
-> настраиваем общий дэшборд для слежения за спринтом
-> в понедельник ретроспектива и напихивание всем задач на 4 дня в ToDo, остаток тратится на текучку и оценки
-> говорят, что Jira не для Agile

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Владимир Лупанов

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

Проблема в том, что имхо, под нейросетки нужно формировать и нанимать рабочую группу из миддла и джуна (1-6 месяцев), адаптировать их (2 месяца), потом пересаживать деятельность этих двух отделов из людей на иишку (3-6 месяцев) и только потом по фану вводить иишку во внутренних комуникациях компании для автосбора и трекинга задач.

А чтобы все это последовательно и поступательно реализовать, нужна Jira. Не Trello, где карточку может кто угодно швырнуть куда угодно, не чаты, не вечные тз-шки в гугл доках.

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

Ответить
Развернуть ветку
Ivan Bulatov

Для макро-компонентов продукта есть эпики.
Для описание функциональности — user stories.
И саб-таски, чтобы разделить работу над user story между сотрудниками.

Кроме того, ни скрам борд, ни канбан борд не требуют завершить работу над одними issues, чтобы начать работу над другими.

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

Ответить
Развернуть ветку
Grigory Antonov

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
33_rublya
программа требует завершить одни задачи, для того чтобы начать работу над другими

Это неправда.

Ответить
Развернуть ветку
Станислав Романов

Тоже как-то писал про недостатки JIRA... уродливая программа, возможно, с моей гуманитарной точки зрения ))

Ответить
Развернуть ветку
Daler Aliyorov

[промахнулся]

Ответить
Развернуть ветку
Alexey Vasilyev

Итого, Jira хороша для процессного управления когда задачу нужно провести по стадиям, но не нужно достигать конкретных целей ограниченных во времени.

Поэтому для управления проектами лучше использовать BIPULSE ( http://bipulse.ru) который может работать поверх джиры, обеспечивает уровень Проектного управления и показывает все нужные данные для этого. Тогда будут и волки сыты (менеджеры смогут управлять проектами) и овцы целы (инженеры будут продолжать использовать джиру для учета дефектов и задач)

Ответить
Развернуть ветку
Никита Видинеев

Jira отличный инструмент для ведения задач.

Для планирования больших частей проекта следует использовать диаграммы Гантта - Merlin Project / Microsoft Project.

Ответить
Развернуть ветку
Anastasia Sarana

Если вы считаете, что Jira не самый удобный тул для проджект менеджмента и баг трекинга, то интеграция Jira и Confluence решает многие проблемы, подробнее можно почитать здесь: https://polontech.com/ru/blog/integraciya-jira-i-confluence-zachem-vam-eto-nuzhno/

Ответить
Развернуть ветку
WhiteMan

Хорошая статья для женского журнала :)

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
31 комментарий
Раскрывать всегда