Почему использовать Jira для ведения проектов неэффективно
Конспект статьи издания TechCrunch.
Изначально Jira предназначалась для отслеживания ошибок, но теперь она также используется для планирования agile-проектов. В результате программа непреднамеренно стала «антипаттерном» (распространённым, но неэффективным подходом к решению часто встречающихся проблем — определение из Wikipedia).
По мнению Джона Эванса, автора статьи на TechCrunch, при разработке программного обеспечения важно помнить не только о деталях, но и об общей концепции. В Jira проект разбивается на задачи, работа над которыми ведётся обособленно. Программа акцентирует внимание на деталях, игнорируя картину в целом. Более того, Jira не поддерживает создание общей инфраструктуры проекта.
Самый большой недостаток Jira Эванс видит в том, что программа требует завершить одни задачи, для того чтобы начать работу над другими. Цикл жизни задачи напоминает принцип работы каскадной модели: спецификация, разработка, улучшение, тестирование, релиз. Но гибкая методология разработки, которая лежит в основе Jira, создана, чтобы отойти от каскада. На деле получается, что один большой каскад заменяется тысячами поменьше.
Для лучшей иллюстрации неэффективности Jira Эванс проводит аналогию. Он просит читателей представить программу для планирования городов, которая позволяла бы с лёгкостью проектировать карту города — жилые кварталы, парки, торговые центры, дороги и так далее. Но эта программа не позволяла бы с той же лёгкостью проектировать гидротехнические сооружения, канализацию, метрополитен, сеть электроснабжения и тому подобное.
При работе с этой программой проектировщики города должны были бы придерживаться двух правил:
- районы — главные единицы города;
- районы строятся по очереди: прежде чем начать новый район, нужно закончить предыдущий, включая работу над деталями (например, озеленение дорог).
Помимо этого, инженеры-проектировщики и строители также должны будут оценивать ход строительства, отчитываясь, сколько районов и кварталов закончено и на какой стадии находится каждый из них. Подобная модель городского планирования была бы неэффективной.
Пользователь Jira вынужден заканчивать районы и кварталы один за другим, закрывать как можно больше поставленных задач и передавать их коллегам, даже если бы было легче работать над ними одновременно, а не разделять их между членами команды. При таком методе работы теряется главная идея проекта, основная цель.
Об идее проекта часто думают только в самом начале, когда менеджер разделяет его на отдельные части и добавляет задачи. Гибкая методология разработки должна подстраиваться под проект, который периодически меняется, и позволять членам команды участвовать в этих изменениях. Jira, наоборот, мешает.
Эванс также упоминает, что разработчики часто недовольны тем, как менеджеры разделяют проект на отдельные задачи. Тем не менее, это не вина Jira: проблема возникает из-за самой структуры программы.
Jira — полезный инструмент для разделения проекта на части, над которыми работают последовательно. Но, по мнению Эванса, создавая программное обеспечение, разработчики должны думать не только о текущих задачах, но и о конечном результате, главной цели проекта.
Он предлагает решение: главную цель проекта нужно описать словами в документе — например, на 10 страниц, а на шести страницах объяснить архитектуру программного обеспечения.
Другими словами, Jira не должна становиться основным инструментом для планирования. Её можно использовать для отслеживания ошибок или этапов итеративного процесса. «Позвольте Jira планировать микрозадачи. Для больших планов лучше подойдут старые добрые слова на бумаге».
Jira+Confluence и всё, статья не актуальна. Видимо автор не вкурсе что для решения части проблем Джиры предусмотрены варианты интеграций с over100500 сервисов.
А подскажите, пжл, беспокоит ли вас их тормознутость? И, если да, есть ли у вас какие-нибудь секреты, как заставить Джиру и Конфлюенс работать быстрее?
У меня в среднем страница Джиры загружается и рендерится полностью аж за 14 секунд. Речь идет про облачную версию.
У вас какие-то локальные проблемы. Возможно чистится кэш в браущере каждый раз?
Ну вот я тоже наблюдаю тормоза при открытии карточек или панели уведомлений.
Не-а. Любопытно, что при каждой загрузке скачивается в среднем около 100–200 KB.
Переходить на сервер. Облако в плане скорости и доступности в России - это печаль и боль. Сервер гораздо шустрее .
Спасибо за совет, Сергей.
Комментарий удален модератором
да без нейронных сетей никуда. а то щас задолбешься с калькулятором проект планировать. а компутер за микросекунду все сделает, да.
Комментарий удален модератором
Менеджер нужен, прежде всего, для управления людьми, то есть, сейчас это скорее гуманитарная должность типа командного психолога, устраняющего препятствия в работе команды (скрам-мастер - как пример) и для работы с высшим руководством компании (чтобы команде не мешали, а наоброт). Таски забивать, тут конечно роботу раздолье.
Комментарий удален модератором
Так и программистов скорее всего в будущем будет значительно меньше. Это будет должности уровня архитектора с сильным уклоном в инженерные навыки. "Формы шлёпать" буду роботы.
Комментарий удален модератором
Комментарий недоступен
Комментарий удален модератором
Комментарий удален модератором
Управление проектом это не только задачки распределить. Это в первую очередь работа с командой. Ну и раз уж нейросети упомянули, надо было блокчейн добавить, куда ж без него :)
Пустая статья. Очевидно что jira используется не для ведения проектов, а для организации процессов и ведения разработки.
PS Все эти теоретики по управлению проектами начинают утомлять
Комментарий недоступен
В последний версиях Jira, Atlassian действительно пытается "задвинуть" клиентам, свое "экспертное" видение процессов разработки и проджект-менеджмента, но это не отменяет того, что инструмент так и остался гибчайшим конструктором для абсолютно любых процессов. Это экосистема, которая при наличии специалиста, адаптируется к любым реалиям и процессам.
Открываем Agile Manifesto, читаем первый пункт:
Люди и взаимодействие важнее процессов и инструментов.
Не понял, что еще автор хотел от баг-треккера? Ну если находятся ребята, которые скальпелем колбаску нарезают или микроскопом гвозди забивают, то это проблема не инструмента, а этих самых ребят.
Если Джон не умеет работать в джире, это не проблема джиры
Jira прекрасна. Автор просто не умеет ее готовить или не понимает, что следует делать в ней, а что около нее.
Ещё позабавило «написать цель проекта на 10 страницах». Цель, Карл!
А шотакова? Цель проекта описывается в уставе проекта - основополагающем проектном документе. Проект не может быть без цели.
В статье автор не говорит про устав, он предлагает «решение: главную цель проекта нужно описать словами - например, на 10 страниц»
-> настраиваем в проекте Jira пайплайн этапов задач (формирование, оценка, исполнение)
-> сажаем команду на недельные итерации
-> раздаем каждому исполнителю в проекте по дэшборду-канбану, где можно посмотреть свои задачи, их статус для всех пользователей (исполнение, оценка и т.д.), а также взять в работу и отдать в "Готово"
-> покупаем плагин за 15$ и дописываем необходимые автоматизации к пайплайну (время работы, автоматическое назначение исполнителя в зависимости от этапа)
-> настраиваем общий дэшборд для слежения за спринтом
-> в понедельник ретроспектива и напихивание всем задач на 4 дня в ToDo, остаток тратится на текучку и оценки
-> говорят, что Jira не для Agile
Комментарий удален модератором
С точки зрения IT мы - достаточно устаревшая компания, и у нас руками двух отделов из 40 человек через веб-интерфейсы делается при обработке заказов то, что могла бы делать одна простенькая нейросетка (а вот что - не скажу).
Проблема в том, что имхо, под нейросетки нужно формировать и нанимать рабочую группу из миддла и джуна (1-6 месяцев), адаптировать их (2 месяца), потом пересаживать деятельность этих двух отделов из людей на иишку (3-6 месяцев) и только потом по фану вводить иишку во внутренних комуникациях компании для автосбора и трекинга задач.
А чтобы все это последовательно и поступательно реализовать, нужна Jira. Не Trello, где карточку может кто угодно швырнуть куда угодно, не чаты, не вечные тз-шки в гугл доках.
Давать людям задачи неделю, через неделю смотреть, че получилось и куда дальше, все в единой структуре оценки и логирования.
Для макро-компонентов продукта есть эпики.
Для описание функциональности — user stories.
И саб-таски, чтобы разделить работу над user story между сотрудниками.
Кроме того, ни скрам борд, ни канбан борд не требуют завершить работу над одними issues, чтобы начать работу над другими.
Такое ощущение, что автор плохо знаком не только с JIRA, но и с методологиями.
Просто автор способен освоить только трелло, он не знает о гибкой кастомизации джиры под специфические процессы внутри компании, чего нет у многих альтернатив
Комментарий недоступен
Комментарий недоступен
Это неправда.
Тоже как-то писал про недостатки JIRA... уродливая программа, возможно, с моей гуманитарной точки зрения ))
[промахнулся]
Итого, Jira хороша для процессного управления когда задачу нужно провести по стадиям, но не нужно достигать конкретных целей ограниченных во времени.
Поэтому для управления проектами лучше использовать BIPULSE ( http://bipulse.ru) который может работать поверх джиры, обеспечивает уровень Проектного управления и показывает все нужные данные для этого. Тогда будут и волки сыты (менеджеры смогут управлять проектами) и овцы целы (инженеры будут продолжать использовать джиру для учета дефектов и задач)
Jira отличный инструмент для ведения задач.
Для планирования больших частей проекта следует использовать диаграммы Гантта - Merlin Project / Microsoft Project.
Если вы считаете, что Jira не самый удобный тул для проджект менеджмента и баг трекинга, то интеграция Jira и Confluence решает многие проблемы, подробнее можно почитать здесь: https://polontech.com/ru/blog/integraciya-jira-i-confluence-zachem-vam-eto-nuzhno/
Хорошая статья для женского журнала :)
Комментарий удален модератором