Из систем управления проектами знакомые больше всего хвалят 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, софта навалом). А если все и так уже работают с ней, там делов-то немного.