Здравствуйте, 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