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

Я вот глянул RedMine и TeamLab. Последний показался более удобны (но в нем вроде нет интеграции с SVN).

Кто что может сказать по этому поводу? И вообще что порекомендуете использовать для управления проектом?

0K>Из систем управления проектами знакомые больше всего хвалят RedMine (и Jira, но Jira -- это не полноценная система управления, хоть ее иногда в этой роли используют).

Если не секрет, почему Jira — не полноценная система управления? Как раз для управления она даже более функциональна, чем Redmine.

0K>Я вот глянул RedMine и TeamLab. Последний показался более удобны (но в нем вроде нет интеграции с SVN).

TeamLab не использовал — он появился совсем недавно, в конце 2009-го.

0K>Кто что может сказать по этому поводу? И вообще что порекомендуете использовать для управления проектом?

Сейчас в лидерах Jira (платная, но до 10-и человек стоит 10$ за все) и Redmine (бесплатная, но несколько менее функциональная и вылизанная). Для Jira есть Jira Client — очень высокого качества кроссплатформенный Desktop клиент который существенно ускоряет и упрощает работу с задачами. До 10 пользователей бесплатен.

Здравствуйте, Eye of Hell, Вы писали:

EOH>Если не секрет, почему Jira — не полноценная система управления? Как раз для управления она даже более функциональна, чем Redmine.

Нет форумов и wiki.

Без форумов удаленная работа не возможна.

EOH>TeamLab не использовал — он появился совсем недавно, в конце 2009-го.

Пока он хуже всех. Начали использовать -- не удобно... Нужно будет переезжать.

EOH>Сейчас в лидерах Jira (платная, но до 10-и человек стоит 10$ за все) и Redmine (бесплатная, но несколько менее функциональная и вылизанная). Для Jira есть Jira Client — очень высокого качества кроссплатформенный Desktop клиент который существенно ускоряет и упрощает работу с задачами. До 10 пользователей бесплатен.

Пробовали работать с MS Team Server + MS Project? Немного присмотрелся -- с первого взгляда очень даже достойно. Может перейти на него? Минус в том, что интеграция только с Visual Studio (с тем же elipse не работает, а Jira работает со всеми).

Здравствуйте, 0K, Вы писали:

0K>Кто что может сказать по этому поводу? И вообще что порекомендуете использовать для управления проектом?

Я работаю с RedMine & Trac. В принципе обе системы полностью и нормально выполняют свои задачи, но лично мне RedMine почему-то чуть более симпатичен.

Здравствуйте, 0K, Вы писали:

0K>Нет форумов и wiki.

Вот как чуял, что ты изобретаешь проблему там где ее нет. Ставишь Confluence и у тебя есть wiki. Confluence c JIRA можно интегрировать довольно глубоко. Вместо форумов можно взять google groups, по удобству дадут сто очков вперед любым встроенным решениям.

У JIRA есть недостатки, но совершенно не эти. В частности цена владения. Внедрение JIRA на команду из 10 человек занимает где-то полгода и около 200 человеко-часов. Это при условии, что процесс разработки адаптируется под инструмент, а не наоборот. В противном случае год уйдет только на то, чтобы допилить JIRA до соответствия процессу.

Здравствуйте, Аноним, Вы писали:

А>Внедрение JIRA на команду из 10 человек занимает где-то полгода и около 200 человеко-часов.

А можете мне пояснить что именно отнимет пол года? Запомнить на какую кнопку нажать, чтобы создать задачу/баг, запомнить последовательность изменения статусов и не забывать добавлять время в ворк-лог?

Что там такого сложного, что занимает целых пол года?

А>В противном случае год уйдет только на то, чтобы допилить JIRA до соответствия процессу.

А что именно допиливать? Добавить кастомные поля (ака категория, веха и пр.)?

Здравствуйте, Аноним, Вы писали:

А>Вот как чуял, что ты изобретаешь проблему там где ее нет. Ставишь Confluence и у тебя есть wiki. Confluence c JIRA можно интегрировать довольно глубоко. Вместо форумов можно взять google groups, по удобству дадут сто очков вперед любым встроенным решениям.
А>У JIRA есть недостатки, но совершенно не эти.

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

А> В частности цена владения. Внедрение JIRA на команду из 10 человек занимает где-то полгода и около 200 человеко-часов. Это при условии, что процесс разработки адаптируется под инструмент, а не наоборот. В противном случае год уйдет только на то, чтобы допилить JIRA до соответствия процессу.

А вот это неправда. Причем в каждом предложении.

1) У JIRA низкая цена владения, и ручных допилов требуется на порядок меньше, чем в разного рода редмайнах. Последнее, во многом, благодаря большому количеству доступных плагинов.
2) Внедрение JIRA на команду из 10 человек занимает чистого времени в районе недели, при стоимости лицензии 10 (десять) долларов. Это включает в себя настройку воркфлоу и дашбордов на каждую роль, и установку необходимых плагинов, настройку интеграции с почтой и системой контроля версий, и пр.
3) Эта неделя — при условии адаптации JIRA под существующий процесс разработки. Без такой адаптации — процесс внедрения технически занимает примерно полдня.

Не, я вовсе не хочу сказать, что перечисленным при желании (и наличии помощников) можно заниматься год. Можно и два, и три.

Здравствуйте, Gaperton, Вы писали:

Просто мы по разному понимаем что есть внедрение. Ты считаешь что внедрено это "подписан акт", а я уверен, что внедрено это включено в реальную работу хотя бы на 80%.

G>2) Внедрение JIRA на команду из 10 человек занимает чистого времени в районе недели, при стоимости лицензии 10 (десять) долларов. Это включает в себя настройку воркфлоу и дашбордов на каждую роль, и установку необходимых плагинов, настройку интеграции с почтой и системой контроля версий, и пр.

На первоначальную установку и настройку да, около недели. Остальное — скрытые затраты. JIRA обязательно потребует стартового обучения (еще минимум плюс 2*10 часов), иначе откуда команда узнает как ей пользоваться. Регулярно придется бить народ по рукам, потому что кастомные ограничители в JIRA куцые. В процессе работы выяснится, что для каких-то этапов процесса интерфейс JIRA не очень удобен. Между нами, он вообще не удобен ни для чего за пределами ванильной конфигурации. Будет допиливаться процесс, настраиваться дополнительный интеграции. Например, тот же формальный code review через JIRA довольно-таки непросто организовать. ИЧСХ, плагины не очень-то в этом помогают, хотя есть и очень полезные. На всю эту возню уйдет как раз год _календарного_ времени. И только потом, JIRA станет инструментом, который just works.

G>3) Эта неделя — при условии адаптации JIRA под существующий процесс разработки. Без такой адаптации — процесс внедрения технически занимает примерно полдня.
FYI, полдня это уже 40 часов. И этим ограничится только в случае если команда мигрирует с JIRA на JIRA. В противном случае добавляем обучение, интеграцию с внешними сервисами, контроль и получаем те же 200 часов и календарных полгода.

Здравствуйте, Аноним, Вы писали:

А>Просто мы по разному понимаем что есть внедрение. Ты считаешь что внедрено это "подписан акт", а я уверен, что внедрено это включено в реальную работу хотя бы на 80%.

Нет, не "просто". Актов по внедрению JIRA мне подписывать не приходилось. А вот внедрять — многократно.

G>>2) Внедрение JIRA на команду из 10 человек занимает чистого времени в районе недели, при стоимости лицензии 10 (десять) долларов. Это включает в себя настройку воркфлоу и дашбордов на каждую роль, и установку необходимых плагинов, настройку интеграции с почтой и системой контроля версий, и пр.

А>На первоначальную установку и настройку да, около недели.

Установка занимает примерно полдня.

А>Остальное — скрытые затраты.

Видимо, очень сильно скрытые.

А>JIRA обязательно потребует стартового обучения (еще минимум плюс 2*10 часов), иначе откуда команда узнает как ей пользоваться.

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

А>Регулярно придется бить народ по рукам, потому что кастомные ограничители в JIRA куцые.

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

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

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

А>Например, тот же формальный code review через JIRA довольно-таки непросто организовать. ИЧСХ, плагины не очень-то в этом помогают, хотя есть и очень полезные. На всю эту возню уйдет как раз год _календарного_ времени. И только потом, JIRA станет инструментом, который just works.

Элементарно организовать. Ставится Atlassian Crucible, которая из коробки интегрирована с JIRA, и вперед. Делается и без него (достаточно отразить шаг review в workflow и воспользоваться интеграцией с VCS, как я в последний раз и сделал).

G>>3) Эта неделя — при условии адаптации JIRA под существующий процесс разработки. Без такой адаптации — процесс внедрения технически занимает примерно полдня.

А>FYI, полдня это уже 40 часов.

Спасибо, кэп, я в курсе.

А> И этим ограничится только в случае если команда мигрирует с JIRA на JIRA. В противном случае добавляем обучение, интеграцию с внешними сервисами, контроль и получаем те же 200 часов и календарных полгода.

Ерунда.

Здравствуйте, Аноним, Вы писали:

G>>>3) Эта неделя — при условии адаптации JIRA под существующий процесс разработки. Без такой адаптации — процесс внедрения технически занимает примерно полдня.

А>>FYI, полдня это уже 40 часов.

А>Спасибо, кэп, я в курсе.

Не, не в курсе. Прочитал эту чушь как "неделя это уже 40 часов", а у вас тут, оказывается о полднях идет . Каких часов-то? Марсианских?

Давайте, порадуйте объяснением, FMI.

Здравствуйте, Gaperton, Вы писали:

А>> В частности цена владения. Внедрение JIRA на команду из 10 человек занимает где-то полгода и около 200 человеко-часов. Это при условии, что процесс разработки адаптируется под инструмент, а не наоборот. В противном случае год уйдет только на то, чтобы допилить JIRA до соответствия процессу.

G>А вот это неправда. Причем в каждом предложении.

G>1) У JIRA низкая цена владения, и ручных допилов требуется на порядок меньше, чем в разного рода редмайнах. Последнее, во многом, благодаря большому количеству доступных плагинов.
G>2) Внедрение JIRA на команду из 10 человек занимает чистого времени в районе недели, при стоимости лицензии 10 (десять) долларов. Это включает в себя настройку воркфлоу и дашбордов на каждую роль, и установку необходимых плагинов, настройку интеграции с почтой и системой контроля версий, и пр.
G>3) Эта неделя — при условии адаптации JIRA под существующий процесс разработки. Без такой адаптации — процесс внедрения технически занимает примерно полдня.

G>Не, я вовсе не хочу сказать, что перечисленным при желании (и наличии помощников) можно заниматься год. Можно и два, и три.

Переделать дефолтный воркфлоу можно и нужно ручками — но проблема тут основная уже не в JIRA, а в головах людей, которые этот воркфлоу вначале должны отобразить на бумаге, с состояниями и переходами. Самое трудное — получить эту картинку РЕАЛЬНОГО процесса разработки, дальше задача действительно техническая и решается быстро.

Если же тимлид сам не понимает, как, собственно, устроен у них процесс разработки — при чем тут JIRA? Возьми хоть редмайн, хоть тимлаб — легче не будет.

О чем тут еще говорили ранее — если подстраивать процесс под воркфлоу, будет сильно легче, но дефолтный воркфлоу в JIRA заточен под поддержку и багфиксинг, а не под разработку. Отсюда и проблемы. C плагинами JIRA я, увы, не работал, все как-то ручками правилось, возможно, есть что-то готовое, заточенное под R&D. Тогда действительно проще.

Здравствуйте, nvb, Вы писали:

G>>Не, я вовсе не хочу сказать, что перечисленным при желании (и наличии помощников) можно заниматься год. Можно и два, и три.

nvb>Переделать дефолтный воркфлоу можно и нужно ручками — но проблема тут основная уже не в JIRA, а в головах людей, которые этот воркфлоу вначале должны отобразить на бумаге, с состояниями и переходами. Самое трудное — получить эту картинку РЕАЛЬНОГО процесса разработки, дальше задача действительно техническая и решается быстро.
nvb>Если же тимлид сам не понимает, как, собственно, устроен у них процесс разработки — при чем тут JIRA? Возьми хоть редмайн, хоть тимлаб — легче не будет.

Нет в этом никакой проблемы. Не бином ньютона этот ваш РЕАЛЬНЫЙ процесс разработки, везде примерно одно и то же, похожи друг на друга как две капли воды. Было бы странно, если бы было иначе — или, может быть, вы программируете каким-то особенным образом — на головах? Обычно у меня на набросок процесса уходит пара часов — вместе с интервью указанного тимлида (причем, совершенно пофигу, что он понимает, а что нет).

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

Подсказать плагин, или сам найдешь?

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

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

nvb>C плагинами JIRA я, увы, не работал, все как-то ручками правилось, возможно, есть что-то готовое, заточенное под R&D. Тогда действительно проще.

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

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

Здравствуйте, Gaperton, Вы писали:

G>И — да, JIRA сложна в настройке, настолько, что ее не сможет с ходу, без чтения мануалов, настроить полный лохопед. Это, вне всяких сомнений, ее минус.

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

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

Здравствуйте, Gaperton, Вы писали:

G>Давайте, порадуйте объяснением, FMI.
Поясняю. Полдня == 4 часа. С этим согласны? Идем дальше, умножаем 4 часа на 10 разработчиков. Получаем сколько? Правильно, 40 часов.

Здравствуйте, Аноним, Вы писали:

А>Видимо, очень сильно скрытые.

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

А>Необходимость стартового обучения, во-первых, касается абсолютно любого трекера (в обычном использовании JIRA не сложнее их, а наоборот — проще), а во-вторых, это не 2*10 часов, а одна "лекция" на 45 минут с демонстрацией программы. Это все, что необходимо для старта, дальше люди разбираются сами, благо что не идиоты, да и предмет не ракетостроение.

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

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

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

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

Люди "правильного приготовления" это и есть миграция с JIRA на JIRA. А я говорю про первоначальное внедрение, когда никто из команды с JIRA раньше плотно не работал и даже не настраивал. Для них, ИМХО, единственный нормальный вариант это ванильная конфигурация без изменений.

А>Элементарно организовать. Ставится Atlassian Crucible, которая из коробки интегрирована с JIRA, и вперед. Делается и без него (достаточно отразить шаг review в workflow и воспользоваться интеграцией с VCS, как я в последний раз и сделал).

Crucible поддерживает только один сценарий: post-commit review. В более сложных случаях придется делать руками, т.е. придется повозиться хотя бы с интеграцией с VCS.

Здравствуйте, Gaperton, Вы писали:

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

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

Я бы сказал, для коротких проектов JIRA не дает осязаемых бенефитов.

Здравствуйте, Miroff, Вы писали:

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

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

M>Я бы сказал, для коротких проектов JIRA не дает осязаемых бенефитов.

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

Здравствуйте, Miroff, Вы писали:

G>>Давайте, порадуйте объяснением, FMI.
M>Поясняю. Полдня == 4 часа. С этим согласны? Идем дальше,

M>умножаем 4 часа на 10 разработчиков.

Дальше мы куда-то не туда идем. С какого это вдруг дуба мы умножаем мое личное время развертывания и конфигурирования JIRA на десять разработчиков?

M>Получаем сколько? Правильно, 40 часов.

Получаем, правильно, ерунду.

Здравствуйте, Miroff, Вы писали:

А>>Видимо, очень сильно скрытые.

M>Ну, как бы, если разработчик вместо того чтобы делать дело возится с JIRA, логично отнести это время на затраты по внедрению, разве нет?

А с какой стати он должен "возиться с JIRA"? И что значит "возиться"? У нас почему-то никто с ней не "возится".

А>>Необходимость стартового обучения, во-первых, касается абсолютно любого трекера (в обычном использовании JIRA не сложнее их, а наоборот — проще), а во-вторых, это не 2*10 часов, а одна "лекция" на 45 минут с демонстрацией программы. Это все, что необходимо для старта, дальше люди разбираются сами, благо что не идиоты, да и предмет не ракетостроение.

M>Ну да, 1 час на лекцию (не забываем умножить на количество разрабочиков) плюс еще столько же уйдет на то чтобы пощупать руками.

За этот "час" (на самом деле поменьше) будет объяснен процесс обработки задач. И, во время объяснения, он будет прогнан на задачах в JIRA, для примера. Что, изобрели какой-то способ внедрять трекеры без объяснения стоящего за ним процесса?

И зачем ее "щупать"? Сразу после демонстрации, разработчики начинают работать со своими задачами.

M>От того что люди разбираются сами, они не перестают тратить на это рабочие часы.

При настроенной JIRA разработчику разбираться особо не в чем. У него есть один дашборд, в который надо смотреть, и кнопки переходов воркфлоу в тикете, которые надо жамкать. И это гораздо проще, чем пользоваться тем же Redmine — не надо помнить статусов и какие поля когда ставить.

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

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

https://studio.plugins.atlassian.com/wiki/display/FISH/JIRA+FishEye+Plugin;jsessionid=5C713676CC8AA1CC3ED819E8FF0DED70

The FishEye plugin also provides workflow conditions, that can be configured separately or combined to restrict issue transitions until a particular action has been taken, for example:
— Transition only if code has or has not (depending on configuration) been committed against a particular issue.
— Transition only if there are no open Crucible reviews associated with an issue.
— Transition only if there are no unreviewed changesets assoicated with an issue.

Все понятно, или требуются пояснения?

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

M>Люди "правильного приготовления" это и есть миграция с JIRA на JIRA.
M>А я говорю про первоначальное внедрение, когда никто из команды с JIRA раньше плотно не работал и даже не настраивал. Для них, ИМХО, единственный нормальный вариант это ванильная конфигурация без изменений.

Что мешает все правильно с самого начала-то сделать? Почему мне ничего не мешает? Ну вот сколько раз внедряли — ни разу за 5 лет "ванильным воркфлоу" не пользовались. Что заставляет это делать?

А>>Элементарно организовать. Ставится Atlassian Crucible, которая из коробки интегрирована с JIRA, и вперед. Делается и без него (достаточно отразить шаг review в workflow и воспользоваться интеграцией с VCS, как я в последний раз и сделал).

M>Crucible поддерживает только один сценарий: post-commit review. В более сложных случаях придется делать руками, т.е. придется повозиться хотя бы с интеграцией с VCS.

Crucible поддерживает множество разных сценариев. Смотри документацию.

G>Дальше мы куда-то не туда идем. С какого это вдруг дуба мы умножаем мое личное время развертывания и конфигурирования JIRA на десять разработчиков?

Разработчикам время требуется на "въехать". Ну, разобраться.
Иногда — на побороться с глюками. И если проект реально короткий (скажем, до идеальных 1000 человеко-часов), потеря 40 из них ощутима. Но столько нужно только в том случае, если еще нет уже готовой настроенной трекинг-системы (почему сразу jira, софта навалом). А если все и так уже работают с ней, там делов-то немного.

Здравствуйте, Eye of Hell, Вы писали:

EOH>Если не секрет, почему Jira — не полноценная система управления? Как раз для управления она даже более функциональна, чем Redmine.

Почему то упустил: в сравнении с MS Project, у Jira нет удобного планирования (включая диаграмму Ганта и сетевой график). По этому одной Jira для управления проектом где требуется планирование -- не достаточно -- нужен как минимум еще один инструмент типа MS Project.

Здравствуйте, SkyDance, Вы писали:

G>>Дальше мы куда-то не туда идем. С какого это вдруг дуба мы умножаем мое личное время развертывания и конфигурирования JIRA на десять разработчиков?

SD>Разработчикам время требуется на "въехать". Ну, разобраться.
SD>Иногда — на побороться с глюками. И если проект реально короткий (скажем, до идеальных 1000 человеко-часов), потеря 40 из них ощутима.

Во-первых, нет никаких 40-ка часов.

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

SD>Но столько нужно только в том случае, если еще нет уже готовой настроенной трекинг-системы (почему сразу jira, софта навалом). А если все и так уже работают с ней, там делов-то немного.

Смысла этого абзаца я вообще не понимаю. Я что — кого-то агитирую применять JIRA? Или указываю на фактические ошибки и глупости в описании косков JIRA разными анонимусами?

Холивары "какой трекер лучше" — без меня пожалуйста.

Здравствуйте, 0K, Вы писали:

0K>Здравствуйте, Eye of Hell, Вы писали:

EOH>>Если не секрет, почему Jira — не полноценная система управления? Как раз для управления она даже более функциональна, чем Redmine.

0K>Почему то упустил: в сравнении с MS Project, у Jira нет удобного планирования (включая диаграмму Ганта и сетевой график). По этому одной Jira для управления проектом где требуется планирование -- не достаточно -- нужен как минимум еще один инструмент типа MS Project.

Во-первых, тезис об удобстве MS Project для планирования как минимум спорен. Особенно если идет речь о смешанном цикле разработки поддержка-развитие, в котором на деле работает большинство "проектов".

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

Что касается JIRA, то она хотя-бы умеет интегрироваться с Project умеет (theConnector), и там есть бесплатные плагины с Gantt Chart-ами, которые хотя бы пытаются делать шедулинг. У остальных и этого нет.

Здравствуйте, Gaperton, Вы писали:

nvb>>Переделать дефолтный воркфлоу можно и нужно ручками — но проблема тут основная уже не в JIRA, а в головах людей, которые этот воркфлоу вначале должны отобразить на бумаге, с состояниями и переходами. Самое трудное — получить эту картинку РЕАЛЬНОГО процесса разработки, дальше задача действительно техническая и решается быстро.
nvb>>Если же тимлид сам не понимает, как, собственно, устроен у них процесс разработки — при чем тут JIRA? Возьми хоть редмайн, хоть тимлаб — легче не будет.

G>Нет в этом никакой проблемы. Не бином ньютона этот ваш РЕАЛЬНЫЙ процесс разработки, везде примерно одно и то же, похожи друг на друга как две капли воды. Было бы странно, если бы было иначе — или, может быть, вы программируете каким-то особенным образом — на головах? Обычно у меня на набросок процесса уходит пара часов — вместе с интервью указанного тимлида (причем, совершенно пофигу, что он понимает, а что нет).

"У них нет хлеба? Тогда пусть едят пирожные". Рад за тебя. Но у большинства тимлидов, с которыми я встречался, дела обстоят далеко не так. Команда в 10 человек, не забываем. Учиться не у кого.

G>Далее воркфлоу замечательно "отображается на бумаге" посредством одного бесплатного плагина. Причем, для каждого issue на картинке в специальной закладке рисуется, какое состояние сейчас активно, а также какие переходы, когда, и кем были сделаны. Так, что понятно даже идиоту.

G>Подсказать плагин, или сам найдешь?

Да я как-то по старинке, вначале в AllFusion рисую IDEF0 диаграмму, а дальше из нее уже все остальное просто

Здравствуйте, Gaperton, Вы писали:

G>Да нет ровным счетом никаких проблем. Дефолтный воркфлоу никуда не годится — но тут уж не надо строить иллюзий, а сразу его выкинуть.
G>Обычно у меня на набросок процесса уходит пара часов — вместе с интервью указанного тимлида (причем, совершенно пофигу, что он понимает, а что нет).
Оно, конечно, круто, когда у этого тилида есть кто-то с опытом, который *может* за пару часов набросать процесс. А если тимлид один (см. мою специфику ниже)? Если у нас есть специалист по качеству (единственный чел, к которому я могу обратиться с соответствующим вопросов), но знания у него строго по докам к ISO 9000 (или как там называется та хрень, которую мы подтверждаем каждый год) и никакого практического опыта?

Так вот, строил я воркфлоу, построил. Забил в Рэдмайн. Пришел ко мне тестер, обсудили... исправил, пришел разработчик... дополнили. В итоге разрешил любой статус из любого, вот весь воркфлоу.

Возвращаясь к контексту (хотя он меня не сильно интересует, интересует именно процитированная фраза), до внедрения Рэдмайна процесс был, но совершенно не формализованный. Взяли Рэдмайновский, в дальнейшем оказалось, что не хватает вот такой фазы, такой и такой, добавили, сделали переходы, после использования разрешили переходы откуда хочешь куда хочешь.
Процесс "вхождения" идет уже больше года, сколько времения я потратил на борьбу с трэкером и адаптацию нашего процесса (назовем то, что у нас есть сейчас так) к трэкеру и трэкера к процессу я хз.
В чем прелесть Рэдмайна для меня, так это в том, что он легкий. Он не заставляет тебя начинать с мануала. Мы начали с очень простого юзкейса: зарегил таск/баг в трэкере, взял, сделал, перевел в тест, оттестировал, закрыл. При этом все таски видный на одной страницы (у нас меньше 100 тасков) и не нужно пробираться через 10 стадий и резолюций.

Мой environment: аутсорс, команда из 4 человек, тимлид-программер+2программера+тестер, на стороне заказчика процесса нет (во всяком случае в моей части), вся инициатива по внедрению ее исходит от меня. Для меня основная цель внедрения процесса и трэкера -- прикрыть жопу, следующая -- облегчить себе жизнь (я теперь всегда знаю что мне осталось сделать и что я не забуду сделать записанный на листочке таск).

СУВ, Aikin

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Gaperton, Вы писали:

G>>И — да, JIRA сложна в настройке, настолько, что ее не сможет с ходу, без чтения мануалов, настроить полный лохопед. Это, вне всяких сомнений, ее минус.

G>Посему для товарищей, не имеющих большого опыта с трекерами, не имеющих особых запросов, и не желающих тратить много времени на настройку, я однозначно рекомендую Redmine. Сел и поехал.
Не дочитал до сюда, начал отвечать. Именно к этому мы пришли у себя (правда практического опыта использования Jira у меня нет).

G>Пользоваться тока им куда как тяжелее, чем грамотно запиленной JIRA. Но тут уж каждый сам выбирает.
Где же взять этого зверя в среднестатистической конторе?


С другой стороны:
G>>И — да, JIRA сложна в настройке, настолько, что ее не сможет с ходу, без чтения мануалов, настроить полный лохопед. Это, вне всяких сомнений, ее минус.
G>Посему для товарищей, не имеющих большого опыта с трекерами, не имеющих особых запросов, и не желающих тратить много времени на настройку, я однозначно рекомендую Redmine. Сел и поехал.
Какое-то несоответствие между предложениями. То ли "Посему для товарищей, не имеющих большого опыта с трекерами" -- лохопеды, то ли там не все так просто, или еще что-то.


СУВ, Aikin

Из своего опыта могу сказать, первое что начали делать добавлять тучу трекеров и все жестко запрещать, второе — убирать все трекеры и все разрешать. Я считаю что лучшие ограничения это административное воздействие, так гораздо проще работать чем все запрещать. Рассказал как не надо, накосячили — по шапке, после пары раз все как по маслу.
По времени внедрения у нас (компания 150 чел) заняло 3 года и еще не закончилось. Сначала два проекта по программерам перевели, потом весь отдел, сейчас стали подтягиваться остальные отделы (бухгалтерия, делопроизводство и т.п.)

Так что сел и поехал это только начало, потом хочется большего. Год назад стали кастомизировать, плешины писать, отчеты добавлять. Вот например даже продуктом сделали http://redminecrm.com/contacts.

Сейчас есть мысли сделать легкую ERP из нее, с бухгалтерией, персоналом и всем остальным

Здравствуйте, Аноним, Вы писали:

А>Во-первых, тезис об удобстве MS Project для планирования как минимум спорен. Особенно если идет речь о смешанном цикле разработки поддержка-развитие, в котором на деле работает большинство "проектов".

Планирование и отслеживание — разные вещи. Для планирования удобен Проджект. Для отслеживания и поддержки — трекеры.

А>Во-вторых, JIRA тут не одинока — на данный момент в природе не существует ни одного трекера, который умеет выполнять нормальный шедулинг с ограничениями. Кроме, разве что, гвоздями прибитого к SVN Polarion-а, но он в версии с шедулером настолько дорог, что можно считать что его нет.

А>Что касается JIRA, то она хотя-бы умеет интегрироваться с Project умеет (theConnector), и там есть бесплатные плагины с Gantt Chart-ами, которые хотя бы пытаются делать шедулинг. У остальных и этого нет.

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

Здравствуйте, Gaperton

А>Во-первых, нет никаких 40-ка часов.

Если нет, тогда не о чем говорить. К чему было все то, что дальше?

А>Во-вторых, внедрять трекер только на один проект, затачивая его под процесс, как говорится выше, и свернуть по окончании проекта, чтобы потом начать все с начала — это идиотизм, который мне обсуждать совсем не хочется. Вы тут хорошо отдаете себе отчет в том, что говорите, интересно?

С этим уже не ко мне. Я пытаюсь донести довольно очевидные вещи — не всегда и не у всех уже есть готовые трекеры, к которым все приучены. IMHO — во многих конторах до сих пор есть в лучшем случае bugzilla/RT.

А>Холивары "какой трекер лучше" — без меня пожалуйста.

Эт вы удачно в такую ветку написали

Здравствуйте, kirbez, Вы писали:

K>Из своего опыта могу сказать, первое что начали делать добавлять тучу трекеров и все жестко запрещать, второе — убирать все трекеры и все разрешать. Я считаю что лучшие ограничения это административное воздействие, так гораздо проще работать чем все запрещать. Рассказал как не надо, накосячили — по шапке, после пары раз все как по маслу.
+1 Пришел к тому же. Единственное, команда у меня маленькая (4 человека), поэтому я достаточно быстро замечаю такие косяки и хватает устного замечания.

K>Так что сел и поехал это только начало, потом хочется большего. Год назад стали кастомизировать, плешины писать, отчеты добавлять. Вот например даже продуктом сделали http://redminecrm.com/contacts.
Да, затюнить его уже хочется, но сравнивая value/cost прихожу к выводу что не нужно пока.


СУВ, Aikin

Здравствуйте, SkyDance, Вы писали:

SD>Здравствуйте, Gaperton

А>>Во-первых, нет никаких 40-ка часов.

SD>Если нет, тогда не о чем говорить. К чему было все то, что дальше?

Не о чем говорить, так не говорите. К чему все то, что дальше?

Вот это — к чему?
SD>С этим уже не ко мне. Я пытаюсь донести довольно очевидные вещи — не всегда и не у всех уже есть готовые трекеры, к которым все приучены. IMHO — во многих конторах до сих пор есть в лучшем случае bugzilla/RT.

Вот это — к чему?
SD>Эт вы удачно в такую ветку написали

Здравствуйте, Aikin, Вы писали:

G>>Пользоваться тока им куда как тяжелее, чем грамотно запиленной JIRA. Но тут уж каждый сам выбирает.
A> Где же взять этого зверя в среднестатистической конторе?

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

A>С другой стороны:
G>>>И — да, JIRA сложна в настройке, настолько, что ее не сможет с ходу, без чтения мануалов, настроить полный лохопед. Это, вне всяких сомнений, ее минус.
G>>Посему для товарищей, не имеющих большого опыта с трекерами, не имеющих особых запросов, и не желающих тратить много времени на настройку, я однозначно рекомендую Redmine. Сел и поехал.
A>Какое-то несоответствие между предложениями. То ли "Посему для товарищей, не имеющих большого опыта с трекерами" -- лохопеды, то ли там не все так просто, или еще что-то.

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

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

Где и в чем несоответствие? По-моему, все очевидно.

Здравствуйте, nvb, Вы писали:

nvb>Здравствуйте, Аноним, Вы писали:

А>>Во-первых, тезис об удобстве MS Project для планирования как минимум спорен. Особенно если идет речь о смешанном цикле разработки поддержка-развитие, в котором на деле работает большинство "проектов".

nvb>Планирование и отслеживание — разные вещи. Для планирования удобен Проджект. Для отслеживания и поддержки — трекеры.

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

А>>Что касается JIRA, то она хотя-бы умеет интегрироваться с Project умеет (theConnector), и там есть бесплатные плагины с Gantt Chart-ами, которые хотя бы пытаются делать шедулинг. У остальных и этого нет.

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

И именно поэтому грамотные парни применяют theConnector, который обеспечивает автоматическую двухсторонюю синхронизацию задач jira и project.

Но за совет спасибо, он поднял мне настроение. Ты вообще пробуешь читать посты, по ссылкам ходить, или как видишь анонима — так сразу даешь ему вредные советы? Ай-ай, Гапертон такого не одобрит. Особенно, если он и есть аноним.

Здравствуйте, Gaperton, Вы писали:

Я, если честно, ожидал ответа на соседнее сообщение

Автор: Aikin
Дата: 14.09.11

. То, на которое ты ответил по большей части бесполезное и бессмысленное.


G>>>Пользоваться тока им куда как тяжелее, чем грамотно запиленной JIRA. Но тут уж каждый сам выбирает.
A>> Где же взять этого зверя в среднестатистической конторе?

G>Кэп очевидность подсказывает, что есть целых два варианта:
G>- Научиться это делать, прочитав документацию по JIRA.
G>- Нанять того, кто умеет.
Капитан неочевидность подсказывает, что грамотно запиленная JIRA в одной конторе будет совершенно бесполезной и даже вредной для другой. Она же, "запилинная для нашей конторы", но без учета реальных процессов или людьми слабо в этом разбирающимися будет так же бесполезна.
Поэтому пункт 1 для меня совершенно не подходит. Что касается 2го, то лично для моей ситуации полезнее будет не "консультант, умеющий настраивать JIR-у", а просто консультант, который разберется в моей специфике, поставит процесс и !самое главное! подскажет как этот процесс интегрировать с отсутствием процесса на стороне заказчика.

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

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



Я полностью осознаю, что теперь врядли получу ответ на интересующий меня вопрос

Автор: Aikin
Дата: 14.09.11

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




G>JIRA — это сложный инструмент, он дает больше возможностей, чем другие трекеры, и это вполне естественно, что JIR-у при этом сложнее конфигурировать.

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

СУВ, Aikin

Здравствуйте, <Аноним>, Вы писали:

А>>>Во-первых, тезис об удобстве MS Project для планирования как минимум спорен. Особенно если идет речь о смешанном цикле разработки поддержка-развитие, в котором на деле работает большинство "проектов".
nvb>>Планирование и отслеживание — разные вещи. Для планирования удобен Проджект. Для отслеживания и поддержки — трекеры.

А>Планирование и отслеживание не имеют смысла друг без друга, и являются неотъемлемыми частями одной задачи. Прям как разработка и поддержка .
Я как бэ нэ согласен.
У меня Рэдмайн выполняет функции именно отслеживания задач. И справляется с этим великолепно. Планирование же лежит на стороне заказчика (я хз как он там планирует (в Проджекте) не видя реальные таски). Максимум что мне нужно это ответить на вопрос "успеем?" ответы обычно -- "да", "хз, но будем стараться", "да ты что, посмотри сколько у нас тасков. Успеем только это, это и вот это, а это и это хз, но постораемся". А теперь назови меня ламером-лохопедом и скажи, чтобы мне нужно семечками на базаре торговать, а не разработкой заниматься.

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

G>>Кэп очевидность подсказывает, что есть целых два варианта:
G>>- Научиться это делать, прочитав документацию по JIRA.
G>>- Нанять того, кто умеет.
A>Капитан неочевидность подсказывает, что грамотно запиленная JIRA в одной конторе будет совершенно бесполезной и даже вредной для другой. Она же, "запилинная для нашей конторы", но без учета реальных процессов или людьми слабо в этом разбирающимися будет так же бесполезна.
A>Поэтому пункт 1 для меня совершенно не подходит.

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

A>Что касается 2го, то лично для моей ситуации полезнее будет не "консультант, умеющий настраивать JIR-у", а просто консультант, который разберется в моей специфике, поставит процесс и !самое главное! подскажет как этот процесс интегрировать с отсутствием процесса на стороне заказчика.

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

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

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

Redmine хорош ровно тремя вещами.
1) Иерархия задач и проектов.
2) Сравнительно низкий порог вхождения при конфигурировании.
3) Бесплатность.

А во всем остальном это ничем не выдающийся трекер. JIRA дает на порядок больше возможностей. По возможностям настройки воркфлоу — рвет Redmine в тряпки.

Я понимаю, что у тебя даже в Redmine настроить workflow не получилось (было бы очень странно, если бы сразу получилось), поэтому и говорю — что для людей без опыта работы с трекерами Redmine предпочтителен. Для профессионалов — лучше JIRA, она дает больше возможностей.

A>В свете всего вышенаписанного, твое заявление про "грамотно запиленую JIRA", ИМО,обычный треп на форуме в стиле: вы все, эти самые, лохопеды и просто не умеете готовить JIRA, вот если бы вы ее смогли приготовить всем бы стало хорошо, коммунизм и бесплатное мороженое для детей.

Так вы ведь и в самом деле не умеете ее готовить, разве нет?

A>Я полностью осознаю, что теперь врядли получу ответ на интересующий меня вопрос

Автор: Aikin
Дата: 14.09.11

, но и йух с ним.

Там набор риторических вопросов, и объяснение, чем тебе нравится Redmine. На это надо отвечать? Ну вот эти вопросы:

A>Оно, конечно, круто, когда у этого тилида есть кто-то с опытом, который *может* за пару часов набросать процесс. А если тимлид один (см. мою специфику ниже)? Если у нас есть специалист по качеству (единственный чел, к которому я могу обратиться с соответствующим вопросов), но знания у него строго по докам к ISO 9000 (или как там называется та хрень, которую мы подтверждаем каждый год) и никакого практического опыта?

Кэп отвечает. У тебя два варианта. Предлагаю изучить оба варианта внимательно.
— Научиться самому.
— Нанять того, кто умеет.

Или ты думаешь, люди от рождения умеют трекерные процессы рисовать, штоли?

G>>JIRA — это сложный инструмент, он дает больше возможностей, чем другие трекеры, и это вполне естественно, что JIR-у при этом сложнее конфигурировать.

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

Поздно.

Здравствуйте, Aikin, Вы писали:

А>>>>Во-первых, тезис об удобстве MS Project для планирования как минимум спорен. Особенно если идет речь о смешанном цикле разработки поддержка-развитие, в котором на деле работает большинство "проектов".
nvb>>>Планирование и отслеживание — разные вещи. Для планирования удобен Проджект. Для отслеживания и поддержки — трекеры.

А>>Планирование и отслеживание не имеют смысла друг без друга, и являются неотъемлемыми частями одной задачи. Прям как разработка и поддержка .
A>Я как бэ нэ согласен.

Когда ты заявляешь несогласие — тебе полагается для начала обозначить, с чем именно ты не согласен, а потом — почему. А потому уже удаляться в разные дали — "А у меня..." и пр.

Давай начнем с простого. Вот мое предложение. С какой именно частью этого предложения ты не согласен?
1) Планирование и отслеживание не имеют смысла друг без друга
2) являются неотъемлемыми частями одной задачи
3) Прям как разработка и поддержка

Почему не согласен?

A>У меня Рэдмайн выполняет функции именно отслеживания задач. И справляется с этим великолепно. Планирование же лежит на стороне заказчика (я хз как он там планирует (в Проджекте) не видя реальные таски).
A>Максимум что мне нужно это ответить на вопрос "успеем?" ответы обычно -- "да", "хз, но будем стараться", "да ты что, посмотри сколько у нас тасков. Успеем только это, это и вот это, а это и это хз, но постораемся".

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

A> А теперь назови меня ламером-лохопедом и скажи, чтобы мне нужно семечками на базаре торговать, а не разработкой заниматься.

Это обязательно?

Здравствуйте, Gaperton, Вы писали:

A>>Я полностью осознаю, что теперь врядли получу ответ на интересующий меня вопрос

Автор: Aikin
Дата: 14.09.11

, но и йух с ним.
G>Там набор риторических вопросов, и объяснение, чем тебе нравится Redmine. На это надо отвечать? Ну вот эти вопросы:
О, спасибо что ответил! Там вопрос в первом обзаце (ты его, кстати, правильно идентефицировал). И этот для тебя риторический вопрос имеют высокую важность для меня. Все остальное написано только для вхождения в мой контекст, ну и, чтобы совсем не было офтопа к самой теме, для популяризации Редмайна.

A>>Оно, конечно, круто, когда у этого тилида есть кто-то с опытом, который *может* за пару часов набросать процесс. А если тимлид один (см. мою специфику ниже)? Если у нас есть специалист по качеству (единственный чел, к которому я могу обратиться с соответствующим вопросов), но знания у него строго по докам к ISO 9000 (или как там называется та хрень, которую мы подтверждаем каждый год) и никакого практического опыта?

G>Кэп отвечает. У тебя два варианта. Предлагаю изучить оба варианта внимательно.
G>- Научиться самому.
Дяденька, а чем я, блять, по вашему занимаюсь мониторя этот форум как не самообразованием?
G>- Нанять того, кто умеет.
Я не зря написал, что у меня средняя аутсорсерная контора, от которой йух что можно добиться в этом плане. Сорри, что эта информация не была изложена доступно.


Так вот, что я хотел от тебя, когда задавал этот вопрос. Я хотел помощи в реализации пункта 1 из списка КО (это который про научитсья самому).
Я понимаю, что для тебя идентефикация и построение процесса настолько же естественно как для меня "завязыванине шнурков", но все же, плиз, отправь меня в пеший путь на RTFM не забыв кинуть один-два(-три) линка на статьи/книги по интересующей меня тематике. А еще лучше, если ты напишешь об этом в блоге.

Спасибо.

---

G>>>Кэп очевидность подсказывает, что есть целых два варианта:
G>>>- Научиться это делать, прочитав документацию по JIRA.
G>>>- Нанять того, кто умеет.
G>В самом деле? А мне казалось, что в пункте один написано вовсе не про то, что надо воровать конфигурацию JIRA из другой "конторы", не учитывая "реального процесса" своей.
В самом деле? А мне казалось, что в пункте один написано ровно про то, что все что нужно знать для "правильного запиливания JIRA" -- прочитать документацию. Нет?
Я же говорю что нужно еще дохрена знаний в управлении проектом. И это я еще доверюсь тебе и предположу что у ПМа не произойдет вынос мозга и ломание стереотипов после прочтения документации и попытке настроить Жиру под свой процесс самому.

G>Я, вообще-то, отвечал на ваш вопрос, "как получить грамотно запиленную JIRA в среднестатистической конторе". И я понятия не имею, что будет полезнее лично для вашей ситуации. Если вы считаете, что для этого не надо разбираться в JIRA, или что те, кто в ней разбираются, нипочем не сможет "поставить процесс", — ваше право и ваши тараканы .
Это был ответ в стиле "я вам не скажу за всю Одессу", а скажу про свою среднестатистическую контору.

G>P.S.: Эти ответы настолько не соответствуют контексту разговора, и кажутся мне до такой степени дикими, что я не вижу смысла в его продолжении.
Да, я уже заметил что ты стал отвечать на что-то тебе интересное, а не на заданный вопрос (но все так делают, так что проехали).

---

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

G>Redmine хорош ровно тремя вещами.
G>1) Иерархия задач и проектов.
G>2) Сравнительно низкий порог вхождения при конфигурировании.
G>3) Бесплатность.
Согласен. И два первых пункта полностью покрывают мои нужды на данном этапе моей деятельности.

G>А во всем остальном это ничем не выдающийся трекер. JIRA дает на порядок больше возможностей. По возможностям настройки воркфлоу — рвет Redmine в тряпки.
Я, конечно же, оценю эти возможности Jira когда буду тимлидить/управлять более крупной командой (скажем так, более 10 человек). Сейчас меня "хиленькие" возможности Редмайна устраивают.

G>Я понимаю, что у тебя даже в Redmine настроить workflow не получилось (было бы очень странно, если бы сразу получилось), поэтому и говорю — что для людей без опыта работы с трекерами Redmine предпочтителен. Для профессионалов — лучше JIRA, она дает больше возможностей.
Не, у меня получилось настроить (там не сложно, но муторно галки ставить). У меня не получилось создать хороший воркфлоу, который выдержал бы реалии проекта. Единственное, что реально работает -- это ограничения возможностей репортерам (но там все просто).

A>>В свете всего вышенаписанного, твое заявление про "грамотно запиленую JIRA", ИМО,обычный треп на форуме в стиле: вы все, эти самые, лохопеды и просто не умеете готовить JIRA, вот если бы вы ее смогли приготовить всем бы стало хорошо, коммунизм и бесплатное мороженое для детей.
G>Так вы ведь и в самом деле не умеете ее готовить, разве нет?
А кто спорит. Но весь мой опыт говорит, что лично для меня (и, уверен, большинства среднестатистических контор) Jira не даст ничего сверх того, что мы имеем с Redmine.
Поэтому я не кидаюсь изучать Jira, хотя "бесплатное мороженое для детей" не помешало бы.

G>>> Нормальные люди себя так не ведут — на темы, в которых ничерта не разбираются, не спорят.
A>>Прикинусь нормальным человеком и спорить не буду
G>Поздно.
Мне мама говорила, что стать нормальным человеком никогда не поздно

Здравствуйте, Gaperton, Вы писали:

А>>>Планирование и отслеживание не имеют смысла друг без друга, и являются неотъемлемыми частями одной задачи. Прям как разработка и поддержка .
A>>Я как бэ нэ согласен.
G>Когда ты заявляешь несогласие — тебе полагается для начала обозначить, с чем именно ты не согласен, а потом — почему. А потому уже удаляться в разные дали — "А у меня..." и пр.
Как бэ очевидно, что я не согласен со всем процитированным обзацем. Нет?
Дальше шел контрпример при котором отслеживание вполне себе существует без планирования и наоборот на конкреном отдельно взятом проекте.
Даже с точки зрения математики такое доказательство вполне прокатывает


G>Давай начнем с простого. Вот мое предложение. С какой именно частью этого предложения ты не согласен?
G>1) Планирование и отслеживание не имеют смысла друг без друга
В теории нет, но в моем конкретном частном случае имеют. Кроме того, этими "активностями" занимаются совершенно разные люди между собой почти не контачащие.
G>2) являются неотъемлемыми частями одной задачи
Непонятно о какой задаче идет речь, но если предположить, что это "задача управления проектом", то "отъемлемость" в моем случае я продемонстрировал.
G>3) Прям как разработка и поддержка
Это был оборот речи, который попал в цитату с одной стороны по моему недосмотру, а с другой стороны так же не верен: на ум приходять слова "распил", "никому не нужный проект", "провальный проект". Ну и, кроме того, какой процент проектов реально пишутся с ориентиром на последующую поддержку? Мой опыт говорит, что маленький.

G>Да? А я в свою очередь хз, как у тебя получается заводить в Redmine "реальные таски", не выполняя при этом планирования. Ты, может быть, посредством божественного озарения эти таски получаешь?
Тебе это интересно, или это риторический вопрос?

A>> А теперь назови меня ламером-лохопедом и скажи, чтобы мне нужно семечками на базаре торговать, а не разработкой заниматься.
G>Это обязательно?
Если после этого пойдет что-то реально полезное для меня, то да!

Здравствуйте, Aikin, Вы писали:

A>Здравствуйте, kirbez, Вы писали:

K>>Из своего опыта могу сказать, первое что начали делать добавлять тучу трекеров и все жестко запрещать, второе — убирать все трекеры и все разрешать. Я считаю что лучшие ограничения это административное воздействие, так гораздо проще работать чем все запрещать. Рассказал как не надо, накосячили — по шапке, после пары раз все как по маслу.
A>+1 Пришел к тому же. Единственное, команда у меня маленькая (4 человека), поэтому я достаточно быстро замечаю такие косяки и хватает устного замечания.

Самое эффективное получилось вот что: мы сделали привязку отчетов из редмайна к зарплате. Короче говоря, трудоемкость стали считать, и в конце месяца проверять KPI (у нас только один 40 час в неделю и субъективное мнение руководителя). И так быстро все сразу стало наполняться, все задачи появились, все время учтено и траффик потек. И теперь почти все свой день начинают с редмайна.

K>>Так что сел и поехал это только начало, потом хочется большего. Год назад стали кастомизировать, плешины писать, отчеты добавлять. Вот например даже продуктом сделали http://redminecrm.com/contacts.
A>Да, затюнить его уже хочется, но сравнивая value/cost прихожу к выводу что не нужно пока.

Вот промокоды на скидку 75% (есть еще старая бесплатная версия, могу почтой кинуть.)
379A1CCF
0AC6360F
77FC6E32
2CFC7E94
7EE694FE

Здравствуйте, kirbez, Вы писали:

A>>+1 Пришел к тому же. Единственное, команда у меня маленькая (4 человека), поэтому я достаточно быстро замечаю такие косяки и хватает устного замечания.
K>Самое эффективное получилось вот что: мы сделали привязку отчетов из редмайна к зарплате. Короче говоря, трудоемкость стали считать, и в конце месяца проверять KPI (у нас только один 40 час в неделю и субъективное мнение руководителя). И так быстро все сразу стало наполняться, все задачи появились, все время учтено и траффик потек. И теперь почти все свой день начинают с редмайна.
Не, это не мой путь. Не одобряю я формализацию. А тем более когда на основании "формул" считается зарплата. Где-то вглубине меня сидит уверенность, что при таком подходе легко получить ситуацию когда работа кипит, таски открываются/закрываются, а реального выхлопа нет -- проект не движется вперед.

K>Вот промокоды на скидку 75% (есть еще старая бесплатная версия, могу почтой кинуть.)
Нет, спасибо. Мой тюнинг имеет менее локальный характер: уведомление групп позльзователей при наступлении определенного события. Перевод таска на тестера при установке статуса Test. Чтобы иерархия тасков в списке не "плыла" на каждый чих фильтра.
А плагин контактов я вообще хз зачем нам. У нас пользователей меньше десятка на весь Рэдмайн.

Здравствуйте, Аноним, Вы писали:

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

А>И именно поэтому грамотные парни применяют theConnector, который обеспечивает автоматическую двухсторонюю синхронизацию задач jira и project.

Как-то даже и неудобно возражать после таких слов Я — неграмотный парень и делаю лишь то, что считаю нужным. И если у меня в исполнителях задачи в Проджекте стоят люди, которых я знаю и в которых я уверен, я не стану заводить таск в JIRA. Потому что 9/10 таких тасков закрывается без комментов, разве только спасибо исполнителю написать. Жалко своего времени, только и всего. Никакой идеологии.

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

А>Но за совет спасибо, он поднял мне настроение. Ты вообще пробуешь читать посты, по ссылкам ходить, или как видишь анонима — так сразу даешь ему вредные советы? Ай-ай, Гапертон такого не одобрит. Особенно, если он и есть аноним.

Даже если Сам Великий и Ужасный Гапертон такого не одобрит — как-нибудь переживу, не впервой

Здравствуйте, Aikin, Вы писали:

А>>>>Планирование и отслеживание не имеют смысла друг без друга, и являются неотъемлемыми частями одной задачи. Прям как разработка и поддержка .
A>>>Я как бэ нэ согласен.
G>>Когда ты заявляешь несогласие — тебе полагается для начала обозначить, с чем именно ты не согласен, а потом — почему. А потому уже удаляться в разные дали — "А у меня..." и пр.
A>Как бэ очевидно, что я не согласен со всем процитированным обзацем. Нет?

По твоему ответу далеко не очевидно, что ты понял именно то, что написано в абзаце. Мог понять что-то другое, и с ним не согласиться. И, судя по всему, именно это и произошло.

A>Дальше шел контрпример при котором отслеживание вполне себе существует без планирования и наоборот на конкреном отдельно взятом проекте.

Это невозможно. Не имея плана, тебе просто нечего отслеживать. У тебя предмет отслеживания отсутствует. Это раз.

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

Так как задачи формулируешь ты, то ты занимаешься планированием. А вот из факта использования project-а наличие планирования вовсе не следует.

A>Даже с точки зрения математики такое доказательство вполне прокатывает

Оно даже с точки зрения элементарного здравого смысла не прокатывает.

G>>Давай начнем с простого. Вот мое предложение. С какой именно частью этого предложения ты не согласен?
G>>1) Планирование и отслеживание не имеют смысла друг без друга
A>В теории нет, но в моем конкретном частном случае имеют. Кроме того, этими "активностями" занимаются совершенно разные люди между собой почти не контачащие.

На практике, а не в теории, судя по твоему описанию, планированием занимаешься ты. "Эти люди" только думают, что им занимаются. Но они не правы.

G>>2) являются неотъемлемыми частями одной задачи
A>Непонятно о какой задаче идет речь, но если предположить, что это "задача управления проектом", то "отъемлемость" в моем случае я продемонстрировал.

Если относиться к задаче управления формально, для галки, ориентируясь на названия — то в твоем случае это так. А если говорить по сути — то "отъемлемости" не может быть по определению управления. Для управления необходимо наличие обратной связи, то есть контроля. "Эти люди" не занимаются в твоем случае управлением, оно де-факто сброшено на тебя. Вместе с планированием.

G>>3) Прям как разработка и поддержка
A>Это был оборот речи, который попал в цитату с одной стороны по моему недосмотру, а с другой стороны так же не верен: на ум приходять слова "распил", "никому не нужный проект", "провальный проект". Ну и, кроме того, какой процент проектов реально пишутся с ориентиром на последующую поддержку? Мой опыт говорит, что маленький.

Это место я поясню.

Поддержка не имеет смысла без разработки. Не будет разработки — поддерживать будет попросту нечего.

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

Если говорить о "распиле" — то это вообще к разработке отношения имеет мало. Нечего его сюда приплетать.

G>>Да? А я в свою очередь хз, как у тебя получается заводить в Redmine "реальные таски", не выполняя при этом планирования. Ты, может быть, посредством божественного озарения эти таски получаешь?
A>Тебе это интересно, или это риторический вопрос?

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

A>>> А теперь назови меня ламером-лохопедом и скажи, чтобы мне нужно семечками на базаре торговать, а не разработкой заниматься.
G>>Это обязательно?
A>Если после этого пойдет что-то реально полезное для меня, то да!

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

Здравствуйте, nvb, Вы писали:

nvb>Здравствуйте, Аноним, Вы писали:

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

А>>И именно поэтому грамотные парни применяют theConnector, который обеспечивает автоматическую двухсторонюю синхронизацию задач jira и project.

nvb>Как-то даже и неудобно возражать после таких слов Я — неграмотный парень и делаю лишь то, что считаю нужным.

Мне непонятно, откуда у тебя в этой ситуации вообще желание что-либо возражать берется. Вместо того, чтобы, для разнообразия, сходить по ссылке, и узнать — что это.
http://the-connector.com/index.aspx

nvb>И если у меня в исполнителях задачи в Проджекте стоят люди, которых я знаю и в которых я уверен, я не стану заводить таск в JIRA. Потому что 9/10 таких тасков закрывается без комментов, разве только спасибо исполнителю написать. Жалко своего времени, только и всего. Никакой идеологии.

Если ты используешь theConnector, то тебе никогда не нужно заводить задачи в JIRA, они в JIRA сами заводятся, прикинь? И до кучи сами обновляются в обе стороны — то есть, задачи в Project сами закрываются .

nvb>С другой стороны — я про The Connector не знал, т.к. не ощущал необходимости. Попробую. Наверняка, как-то можно замаскировать ненужные для отслеживания задачи. Каждый раз искать и вбивать поле ссылки было лениво, а если автоматом — другое дело. Спасибо.

Да на здоровье. По сути, TheConnector заменяет собой угребищный веб-интерфейс Project Server, и ты получаешь лучшее из двух миров.

nvb>Даже если Сам Великий и Ужасный Гапертон такого не одобрит — как-нибудь переживу, не впервой

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

Здравствуйте, Gaperton, Вы писали:

А>>>И именно поэтому грамотные парни применяют theConnector, который обеспечивает автоматическую двухсторонюю синхронизацию задач jira и project.

nvb>>Как-то даже и неудобно возражать после таких слов Я — неграмотный парень и делаю лишь то, что считаю нужным.

G>Мне непонятно, откуда у тебя в этой ситуации вообще желание что-либо возражать берется. Вместо того, чтобы, для разнообразия, сходить по ссылке, и узнать — что это.
G>http://the-connector.com/index.aspx

Я предварительно почитал, и выступаю в роли покупателя The Connector , так что аргумент "давай будем спорить о вкусе устриц с теми, кто их ел" — не катит.

nvb>>И если у меня в исполнителях задачи в Проджекте стоят люди, которых я знаю и в которых я уверен, я не стану заводить таск в JIRA. Потому что 9/10 таких тасков закрывается без комментов, разве только спасибо исполнителю написать. Жалко своего времени, только и всего. Никакой идеологии.

G>Если ты используешь theConnector, то тебе никогда не нужно заводить задачи в JIRA, они в JIRA сами заводятся, прикинь? И до кучи сами обновляются в обе стороны — то есть, задачи в Project сами закрываются .

Ну что же, если меня неправильно поняли, то это моя проблема. Попробую по-другому. Я не хочу, чтобы в JIRA было столько же тасков, сколько задач в проджекте. Даже если они заводятся сами. Даже с учетом замены многих задач вроде "анализа контракта юротделом" майлстоунами, все равно тасков получается раз в 10 больше, чем на самом деле нужно. Я не хочу в них путаться, ставить тэги для их сортировки, и т.д. Мне это неудобно. Что хуже, это неудобно и исполнителям, на которых валятся тонны уведомлений от JIRA об изменении статуса этих тасков при открытии-закрытии задачи в Project. С двадцатым письмом исполнитель заводит в Оутлуке папку "Jira" с правилом и все уведомления от трекера, в том числе действительно важные, перемещаются туда автоматом, с пометкой "прочитанное". А после этой операции во многом теряется смысл трекера как такового.

Это все лирика. Вопрос вот в чем — есть ли какие-нибудь способы маскировки генерации тасков JIRA при создании задачи в Project или нет? Беглый просмотр The Connector release notes ответа не дал. А ставить его, чтобы попробовать — не хочется, у меня и без этого достаточно тем для общения с ИТ-сервисом.

Здравствуйте, nvb, Вы писали:

G>>Мне непонятно, откуда у тебя в этой ситуации вообще желание что-либо возражать берется. Вместо того, чтобы, для разнообразия, сходить по ссылке, и узнать — что это.
G>>http://the-connector.com/index.aspx

nvb>Я предварительно почитал, и выступаю в роли покупателя The Connector , так что аргумент "давай будем спорить о вкусе устриц с теми, кто их ел" — не катит.

Ну, меня-то с продавцом theConnector путать не надо. Мне процентов с продаж не отчисляют, и, таким образом, никакого мотива спорить с тобой о вкусе устриц у меня нет.

G>>Если ты используешь theConnector, то тебе никогда не нужно заводить задачи в JIRA, они в JIRA сами заводятся, прикинь? И до кучи сами обновляются в обе стороны — то есть, задачи в Project сами закрываются .

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

Насколько я припоминаю, там есть возможность выбирать задачи для синхронизации. Попробуй, все таки, почитать документацию. Или лучше, скачать evaluation. Если ты не понимаешь, как работает софтина, которая тебе нужна — это все-ж таки твоя проблема, не моя.

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

Здравствуйте, Gaperton, Вы писали:

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

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

Планирование:
1) Разбиение работы на этапы
2) Установка конкретных сроков для каждого этапа
3) Назначение приоритетов задачам
4) Принятие решений о переносе сроков, уменьшении функционала конкретного этапа и др. изменения в плане

Отслеживание:
1) Занесение задачи в "список" и изменение ее в ответ на любые активности с ней
2) Возможность в любой момент узнать текущий "статус разработки" (сколько сделано, сколько багов/фич осталось, сколько сейчас, кто над чем работает)
3) Возможность делать прогнозы (во всяком случае краткосрочные)
4) Возможность поднять историю задачи и посмотреть кто, зачем и в каком объеме ее делал/сделал


Приму любые замечания/дополнения/исправления. Внимательно выслушаю твой вариант определения этих понятий.
Эти характеристики далеки от идеала. Вполне возможно ты их сочтешь ламерскими. Мне даже самому не нравится эти характеристики (особенно для Отслеживания).


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

СУВ, Aikin

А>>Планирование и отслеживание не имеют смысла друг без друга, и являются неотъемлемыми частями одной задачи. Прям как разработка и поддержка .
A>Я как бэ нэ согласен.
Понял свою ошибку. Я хотел сказать не про отъемлемость/неотъемлемость. А про то, что планированием и отслеживанием могут заниматься разные люди. Они же, соответственно, будут использовать разные инструменты (тул для планирования и трекер).
К разработке и поддержке это точно так же относится.

A>У меня Рэдмайн выполняет функции именно отслеживания задач. И справляется с этим великолепно. Планирование же лежит на стороне заказчика (я хз как он там планирует (в Проджекте) не видя реальные таски). Максимум что мне нужно это ответить на вопрос "успеем?" ответы обычно -- "да", "хз, но будем стараться", "да ты что, посмотри сколько у нас тасков. Успеем только это, это и вот это, а это и это хз, но постораемся". А теперь назови меня ламером-лохопедом и скажи, чтобы мне нужно семечками на базаре торговать, а не разработкой заниматься.
Я -- отслеживаю, наш ПМ -- планирует. Я использую Рэдмайн, он MS Project.

СУВ, Aikin

Здравствуйте, 0K, Вы писали:

0K>Из систем управления проектами знакомые больше всего хвалят RedMine (и Jira, но Jira -- это не полноценная система управления, хоть ее иногда в этой роли используют).

0K>Я вот глянул RedMine и TeamLab. Последний показался более удобны (но в нем вроде нет интеграции с SVN).

0K>Кто что может сказать по этому поводу? И вообще что порекомендуете использовать для управления проектом?

Ставил битнами на работе. Пару лет назад пробовал вручную дома, просто поковырять — не получилось, тоже тогда поставил битнами.
На работе сначала боялся, что будут конфликты с SQL Server и апачем, которые уже стояли на сервере (возможно, из-за этого не всегда ставят битнами — не у всех есть отдельный сервер для подобных экспериментов), но потом вспомнили про другой сервер, на который уже давно только бэкапы кладутся. Туда встало все само, только оставалось настроить бэкап базы и файлов редмайна, и уведомления по почте.
А еще, возможно, битнами не ставят, чтобы лучше разобраться, чтобы потом оперативнее решать проблемы, обновляться и т.д.
Да и по поисковой выдаче оценить соотношение битнами/не битнами довольно трудно.

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