в Jira есть достаточно мощная аналитика

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

Плюс шаблоны запросов, настраиваемые SLA, custom workflow и т.д. и т.п.

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

Насчет Trello - какой именно аналог ты имеешь в виду? Там главное - легкость и наглядность интерфейса, в котором заполнение карточки сравнимо по сложности с наклеиванием стикера на монитор. Redmine или Jira в этом плане слишком тяжелые.

TeamCity не пользовалась, поэтому думаю что он не нужен. Просто дженкинс уж больно уродлив по дефолту. И менеджеров опять же пугает.

Интеграция с Stash и Confluence, уже упомянутая аналитика, плугины (тот же structure).

Trell'ы и прочие Basecamp'ы с TeamCit'ями

чтобы создавать видимость работы красиво

Jir'ы

для жирного ынтырпрайза незаменима

чего нельзя добавить

this

В jira, почти всё, что ты [за]хочешь добавить есть из коробки и лезет тебе в глаз, что бы ты хотел потом добавить это во всяких редмайнах.

Но главная плюшка - в jira есть уже настроенные и годные workflow's которые просто говорят как тебе работать, ты можешь конечно их поменять и кастомизировать, но часто, проще слегка поменять привычки и работать с конфигом из коробки.

Тимсити - хорошая песочница для диких людей которые CI в глаза не видели до этого. Очень много чего можно натыкать в ui.

Про trello - сам не понимаю чего с ним так носятся :)

Так что, зря ты обобщаешь.

Trello переоценен.

Jira очень удобна для множества команд и множества одновременных проектов разбросанных по этим командам.

Остальным не пользовался.

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

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

Зачем тогда платить за все эти багтрекеры и серверы CI, если бесплатные не хуже?

Ну за бесплатные тебе тоже придется платить.

Мощная аналитика

в Jira есть достаточно мощная аналитика

Например?

Плугином сыт не будешь

Интеграция с Stash и Confluence

Интеграция любых достаточно популярных ужей и ежей дело 10 минут, Redmine, Jenkins, Git, Gitlab, на любой вкус.

уже упомянутая аналитика

Не могу представить как эта аналитика может быть реально полезна, если всякие метрики немного объективны только в рамках одной команды, потому что в каждой команде свои story point'ы, баги, важность и прочее, это всё очень субъективно. Если одна команда за неделю закрыла 10 тикетов, а другая 100, то это означает примерно ничего.

Красота важна

чтобы создавать видимость работы красиво

Это важное качество, хоть и субъективное.

для жирного ынтырпрайза незаменима

Что делает Jir'а чего не может делать Redmine?

Нет в коробке

В jira, почти всё, что ты [за]хочешь добавить есть из коробки и лезет тебе в глаз, что бы ты хотел потом добавить это во всяких редмайнах.

В одной конторе где использовалась Jir'а был отдельный человек отвечавший только за Jir'у. Так что не всё так радужно, искоробочно и автоматически-хорошо. Подозреваю, хотя могу ошибаться, что отдельный человек на Redmin'е тоже мог бы сделать очень-очень много.

Сложна

Jira очень удобна для множества команд и множества одновременных проектов разбросанных по этим командам.

Чем удобна? Почему любой популярный аналог неудобен?

Не могу представить как эта аналитика может быть реально полезна, если всякие метрики немного объективны только в рамках одной команды, потому что в каждой команде свои story point'ы, баги, важность и прочее, это всё очень субъективно.

Во-первых, time tracking. Который позволяет выяснить, почему задача третью неделю футболится по отделам.

Во-вторых, time tracking. Который позволяет выяснить, сколько времени мы потратили по отношению к тому, сколько мы напланировали. Это полезно, потому что если мы промахнулись в три раза, то хорошо бы выяснить почему и больше так не делать.

В-третьих, график сходимости. Который при правильных оценках (см. пункт 2) дает нам представление о том, что мы нихрена не успеваем и пора что-то делать.

Если одна команда за неделю закрыла 10 тикетов, а другая 100, то это означает примерно ничего.

Ага, и чо?

Платить за бесплатное

Ну за бесплатные тебе тоже придется платить.

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

Тащем-та например

Во-первых, time tracking. Который позволяет выяснить, почему задача третью неделю футболится по отделам.

Каким образом? Робот не даст ответа на этот вопрос. Тут менеджер должен сам влезть в history тикета (или какой-то журнал событий) и посмотреть изменения статусов, переписку, комментарии. Это есть в любом вменяемом task tracker'е.

Во-вторых, time tracking. Который позволяет выяснить, сколько времени мы потратили по отношению к тому, сколько мы напланировали. Это полезно, потому что если мы промахнулись в три раза, то хорошо бы выяснить почему и больше так не делать.

Опять же, то что промахнулись в 3 раза скажет любой вменяемый task tracker. А почему промахнулись автоматом не скажет никакой.

В-третьих, график сходимости. Который при правильных оценках (см. пункт 2) дает нам представление о том, что мы нихрена не успеваем и пора что-то делать.

Эта штука тоже есть везде, тут Jir'а не уникальна.

PS: но спасибо за участие в дискуссии

Я и не говорил, что все это делается автоматом. Просто в JIRA с этим удобнее работать (ну, на мой вкуc). Ну проще говоря, в JIRA я могу построить отчетик по тикетам, который ушли в In Progress и болтаются там уже неделю. И потом рыться по ним в поисках проблем.

Деньги решают

Насчёт org-подобного файла в git'е вы, пожалуй, перегибаете. Вменяемая команда таким обходится не станет.

Но я хочу упомянуть ещё одно соображение: оплачивая Jir'у люди покупают иллюзию уверенности, что всё делают правильно. Нам всем присуще искажение «больше платишь — больше получаешь.» Часто это так, помидоры за 300 рублей скорее всего лучше помидоров за 200. Но далеко не всегда, и маркетологи этим пользуются.

Дело вкуса

Я и не говорил, что все это делается автоматом. Просто в JIRA с этим удобнее работать (ну, на мой вкуc).

Вкус, вот ключевое слово. Я ни в коем случае не хочу сказать, что Jir'а плоха, а кто-то лучше, скорее наоборот — очень даже хороша. Но вам она может казаться лучше любого аналогичного инструмента просто в силу привычки, что в общем-то тоже не особо плохо.

Что делает Jir'а чего не может делать Redmine?

Да в принципе, и Redmine неплох, но Жыра на жабе и учитывая распространенность оной в ынтырпрайзе зачем дважды вставать с этими рельсами?

Я в сообщении дописал пример запроса, который мне иногда нужен. Redmine чонить подобное умеет?

В одной конторе, целая команда саппортила редмайн для одного (1шт) большого проекта.

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

Я не говорю, что это заслуги jira, просто наблюдал такой факт.

Субьективно, jira мне всегда нравилась больше чем redmine. Да и денег она стоит немного для успешного проекта и ценник гибкий и саппорт есть адекватный и оперативный.

Чем удобна? Почему любой популярный аналог неудобен?

Дьявол в деталях, в jira просто много мелких удобных деталей, которые по отдельности есть в различных треккерах, а в jira есть они все. Это и запросы, и дэшборды и всякие правила подписок(полезно кода ты трудишься на n подпроектах) и тайм трекинг(притом дюже умный). Консольное api, интеграция в любую щель. Банальные хоткеи в веб морде.

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

Сейчас всё больше людей, или уже все почти, забывают что какой бы ни был удобный инструмент вроде того же trellо(пользовали, вполне себе), им ещё надо пользоваться уметь. То есть когда в trello начинается что-то вроде чата, и каждый слушает только себя, ну какая это работа? Есть проекты у нас, где всё делается через skype, он у нас стандарт взаимодействия по быстрому, а есть те, где в skype только оперативное, всё остальное в github. И всё это зависит именно от людей.

Приведу ещё пример: вот есть у нас один человек, который сборки приложений обновляет перетаскивая через rdp файлы на сервер, которые он собирает в vs, хотя есть другие проекты, где успешно всё это делается автоматически через jenkins. Так вот этому и подобным ему людям не важно что, хоть trello, хоть teamwork, хоть чёрта. Всё равно все тикеты, которые он формирует придётся читать с телепатий, ибо чукча не писатель, чукча пишет так, что сам только понимает. Я это к тому, что таких людей даже лучше держать только на взаимодействии через почту и не подпускать к технологиям:)

если всякие метрики немного объективны только в рамках одной команды, потому что в каждой команде свои story point'ы, баги, важность и прочее, это всё очень субъективно

Аналитика работает не так. Ты не создаешь один раз магический kpi чтобы потом отслеживать по нему производительность работы команды.

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

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

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

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

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

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

Да, с опытом тебе не повезло. Рабы очень давно не работают достаточно эффективно. А нерабы на давление отвечают отказом работать вообще. Т.ч. единственный способ «заставить» делать что-то эффекивно - инструмент, которым весело и удобно пользоваться.

Аргумент принимается

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

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

Аналитики работает не так

Ты не создаешь один раз магический kpi чтобы потом отслеживать по нему производительность работы команды.

Магический KPI? А это только в рамках одной команды работает? А можно создать справедливый KPI для двух комманд, скажем фронтендеров и бекендеров?

Опыт рабства

Да, с опытом тебе не повезло. Рабы очень давно не работают достаточно эффективно.

Скорее вам не повезло с опытом. Если начальник сказал «Используем TeamCity, и точка!» то вы уже записываете сотрудников в рабы? А это всего лишь административное принуждение. Надо ли на такое отвечать отказом работать вообще?

Я бы не сказал даже, что я поклонник jira. Более того, пока я пользовался в основном этим продуктом не очень он мне и нравился(правда не нравился конкретный инстанс, на котором сотни проектов хостились и в основном из-за лагов).

Кстати, в недостатки можно записать такой момент, сходный с эффектом производимым ide: т.к. процессы строить и формализовать проще ввиду инструментальной поддержки, процессы могут становиться излишне сложными а проекты излишне монолитными.

Если начальник сказал «Используем TeamCity

То есть 2 варианта. «Используем TeamCity» - удобно и приятно, и оно работает. Или неудобно и трудоёмко, тогда работа останавливается. Существенно не то, что сказал начальник, а то, насколько то, что он сказал нравится исполнителям.

отвечать отказом работать

Это более честно. Иначе начальники так и не узнают, почему при бардачной организации труда всё делалось за 20 минут, а при «эффективной» не всё и за 2 месяца.

Перечитай на что отвечаешь.

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

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

любым популярным не пользовался. Пользовался редмайном. По ощущениями - гораздо «сырее», медленнее и менее удобен в мелочах. Плюс необходимость знать markdown (урезанный), что не всем удобно. Зато было диаграммы Гантта.