Много я перепробовал проджект-менеджеров и багтреккеров (пишу вместе, т.к. часто их совмещают в одной программе). Из списка http://en.wikipedia.org/wiki/Comparison_of_project_management_software проверил все бесплатные. Кроме того, проверял MS Project, Jirа и некоторые другие платные.

Так вот. Нет ни одного, который был бы настолько удобным и продуманным как TrackStudio. Больше всего меня волновала иерархия заданий (структурирование и разбиение работы на части -- залог успеха) + возможность одновременного использования несколькими людьми с разными правами (желательно через браузер, но не обязательно). Как вы думаете сколько софтин из того списка удовлетворяют этим двум требованиям? Из бесплатных (хотя бы с ограничением на кол-во пользователей) -- НИ ОДНОЙ!

В качестве благодарности автору программы создал эту тему. Кто не пробовал -- искренне рекомендую попробовать: http://www.trackstudio.com/.

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

0K>Больше всего меня волновала иерархия заданий (структурирование и разбиение работы на части -- залог успеха) + возможность одновременного использования несколькими людьми с разными правами (желательно через браузер, но не обязательно). Как вы думаете сколько софтин из того списка удовлетворяют этим двум требованиям? Из бесплатных (хотя бы с ограничением на кол-во пользователей) -- НИ ОДНОЙ!

В FogBugz (в том числе в их бесплатной версии) — перечисленное есть и отлично работает.

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

LMA>В FogBugz (в том числе в их бесплатной версии) — перечисленное есть и отлично работает.

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

Во-вторых, судя по скриншотам, вы не поняли о чем я говорил. В FogBugz задания выглядят как одно большое нагромождение -- психологически это сразу угнетает. Вся их иерархия -- это небольшой отступ слева. В TrackStudio есть дерево (как и на этом форуме, как и в MSDN-справке) -- это намного удобнее. Субзадания не смешиваются одно с другим, выглядят отдельным списком.

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

0K>Много я перепробовал проджект-менеджеров и багтреккеров (пишу вместе, т.к. часто их совмещают в одной программе). Из списка http://en.wikipedia.org/wiki/Comparison_of_project_management_software проверил все бесплатные. Кроме того, проверял MS Project, Jirа и некоторые другие платные.

0K> Больше всего меня волновала иерархия заданий (структурирование и разбиение работы на части -- залог успеха) + возможность одновременного использования несколькими людьми с разными правами (желательно через браузер, но не обязательно). Как вы думаете сколько софтин из того списка удовлетворяют этим двум требованиям? Из бесплатных (хотя бы с ограничением на кол-во пользователей) -- НИ ОДНОЙ!

bugzilla ?

Больше всего меня волновала иерархия заданий (структурирование и разбиение работы на части -- залог успеха) + возможность одновременного использования несколькими людьми с разными правами (желательно через браузер, но не обязательно). Как вы думаете сколько софтин из того списка удовлетворяют этим двум требованиям? Из бесплатных (хотя бы с ограничением на кол-во пользователей) -- НИ ОДНОЙ!

Мы не пользуемся TrackStudio потому что у нее нет десктопного клиента. А у JIRA есть. Я, честно говоря, сам не совсем понимаю чем десктопный клиент лучше чем веб — по идее они абсолютно одинаковые. Но практика показывает что десктопным клиентом просто удобнее пользоваться . Почему так — хз, вопрос в стадии изучения. Так что приходится плакаться, колоться но жрать JIRA. На 10 пользователей бесплатно (10$).

Вот так выглядит иерархия в запущенном у меня Jira Client:



Ниже более развесистое дерево по проектам и задачам, но его показать не могу by security reasons .

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

EOH>Мы не пользуемся TrackStudio потому что у нее нет десктопного клиента. А у JIRA есть. Я, честно говоря, сам не совсем понимаю чем десктопный клиент лучше чем веб — по идее они абсолютно одинаковые. Но практика показывает что десктопным клиентом просто удобнее пользоваться . Почему так — хз, вопрос в стадии изучения. Так что приходится плакаться, колоться но жрать JIRA. На 10 пользователей бесплатно (10$).

А сам клиент стоит почти 200 у.е.: http://almworks.com/jiraclient/purchase.html Или вы другой используете? И опять-таки -- сколько там уровней вложенности? В Жире вроде как 1 уровень вложенности, если включить Sub-задания.

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

T>bugzilla ?

Вы внимательно читали? Без иерархии с произвольным уровнем вложенности -- это не инструмент а куча дерьма.

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

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

LMA>>В FogBugz (в том числе в их бесплатной версии) — перечисленное есть и отлично работает.

0K>Во-первых, подскажите где там бесплатная версия? Не нашел по этому проверять его не стал.

Оно называется Student and Startup Edition.

0K>Вся их иерархия -- это небольшой отступ слева. В TrackStudio есть дерево (как и на этом форуме, как и в MSDN-справке) -- это намного удобнее.

В FogBugz обычное дерево — с возможностью открыть/свернуть любую ветку.

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

LMA>Оно называется Student and Startup Edition.

Зарегистрировался. Открыли раздел для меня на своем сайте. А скачать для установки на свой сервер нельзя?

LMA>В FogBugz обычное дерево — с возможностью открыть/свернуть любую ветку.

Как там дерево сделать? Все что я увидел -- таблица с отступами. Попробуйте поработать с настоящим деревом и вы меня поймете.

Объясню на примере этого сайта. Здесь меню -- в виде дерева. А форумные сообщения -- в виде таблицы с отступами. А теперь представьте какой бы был бардак, если бы весь сайт сделали в виде таблицы с отступами без дерева...

А в чем прелесь бесконечно йерархии issue? Только не надо бла-бла-бла про структурируемость это не критерий, вы дайте отчет в управленческих терминах

А зачем бесконечная йерархия в дереве?

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

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

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

А сам клиент стоит почти 200 у.е.

10 пользователей — бесплатно. 25 ~1000$, они все столько стоят.

И опять-таки -- сколько там уровней вложенности? В Жире вроде как 1 уровень вложенности, если включить Sub-задания.

Сколько угодно — я же специально скриншот привел. Просто там уровни вложенности не на 'задача-подзадача-подподподзадача' а на уровне фильтров. Я тоже сперва думал что задача-подзадача-....под(N)задача лучше, но после использования jira client понял, что монопенисуально как уровень вложенности определять — нативным деревом или деревом фильтров. Пользоваться удобно.

А в чем прелесь бесконечно йерархии issue? Только не надо бла-бла-бла про структурируемость это не критерий, вы дайте отчет в управленческих терминах

Я не автор топика, но мнение имею . Софтовая разработка отличается от, напрмер, вывоза мусора нет, что задачи очень любят делиться. Тоесть поставленная разработчику атомарная задача на день 'неожиданно' может породить три-четыре подзадачи. Это нормально, особенно при итеративной разработке. Соответственно, когда система управления это относительно прозрачно поддерживает, то пользоваться удобно.

В этом главная управленческая ошибка. Разработчик — низшее звено в йерархии проекта.
Если на него назначена задача и он ее исполняет, то никаких подзадач не может быть, так как он не имеет права их назначать на кого либо.
Задача сначала ставиться teamlead потом он атомарно ее разбивает на подзадачи разработчикам. Если надо параллелить, то делаеться, это не йерархией, а ссылками между issue. В виде исключения возможно создать мегазадачу для программиста напрямую, и разбить ее на подзадачи. В JIRA сделать на ура — поставил задачу на team lead, он создает задачу на программиста и линкует ее к своей, потом разбивает на подзадачи. В JIRА есть даже специальный плагин для визуализации ссылок в виде йерархического дерева.




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

EOH>

А в чем прелесь бесконечно йерархии issue? Только не надо бла-бла-бла про структурируемость это не критерий, вы дайте отчет в управленческих терминах

EOH>Я не автор топика, но мнение имею . Софтовая разработка отличается от, напрмер, вывоза мусора нет, что задачи очень любят делиться. Тоесть поставленная разработчику атомарная задача на день 'неожиданно' может породить три-четыре подзадачи. Это нормально, особенно при итеративной разработке. Соответственно, когда система управления это относительно прозрачно поддерживает, то пользоваться удобно.

В этом главная управленческая ошибка. Разработчик — низшее звено в йерархии проекта.

Щас меня будут учить финики собирать...

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

Это микроменеджмент или куда? Положим я тимлид. У меня стоит задача сделать что-то под айфон. Я даю разработчику ТЗ. Высокоуровневое. Там задачи вида 'сделать вот такой гуй' и 'сделать вот такую базу'. Кто эти высокоуровневые задачи будет дробить, чтобы можно было до разработки прикинуть время, а во время разработки — иметь критерии ее оценки?

Задача сначала ставиться teamlead потом он атомарно ее разбивает на подзадачи разработчикам.

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

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

0K>Зарегистрировался. Открыли раздел для меня на своем сайте. А скачать для установки на свой сервер нельзя?

Бесплатно только on demand.

LMA>>В FogBugz обычное дерево — с возможностью открыть/свернуть любую ветку.

0K>Как там дерево сделать? Все что я увидел -- таблица с отступами. Попробуйте поработать с настоящим деревом и вы меня поймете.

Чем "таблица с отступами" по Вашему отличается от "настоящего дерева"?

0K>Объясню на примере этого сайта. Здесь меню -- в виде дерева. А форумные сообщения -- в виде таблицы с отступами. А теперь представьте какой бы был бардак, если бы весь сайт сделали в виде таблицы с отступами без дерева...

Я местным меню не пользуюсь — оно не позволяет добраться куда мне надо за 2 клика, поэтому бесполезно для меня.

В FogBugz быстро оставить только нужный кусочек дерева позволяют filter, reports и starred. Все 3 очень удобны, IMHO.
То, о чем пишете Вы, видимо ближе всего к filter, хотя filter гибче, чем простое дерево — для того, чтобы его вызвать просто щелкните по слову Filter над деревом в FogBugz.

Учить как финики...а у вам есть высшее финиковое образование?

Тимлид тем и отличаеться от PM'а, что разбирается во всех технических деталях своей команды иначе нафига он нужен (ставил бы PM задачи напрямую разработчикам)?

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





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

EOH>

В этом главная управленческая ошибка. Разработчик — низшее звено в йерархии проекта.

EOH>Щас меня будут учить финики собирать...

EOH>

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

EOH>Это микроменеджмент или куда? Положим я тимлид. У меня стоит задача сделать что-то под айфон. Я даю разработчику ТЗ. Высокоуровневое. Там задачи вида 'сделать вот такой гуй' и 'сделать вот такую базу'. Кто эти высокоуровневые задачи будет дробить, чтобы можно было до разработки прикинуть время, а во время разработки — иметь критерии ее оценки?

EOH>

Задача сначала ставиться teamlead потом он атомарно ее разбивает на подзадачи разработчикам.

EOH>Он что, должен разбираться во всем лучше своих разработчиков? И на все классы прототипы писать? И все что нужно гуглить? А такой тимлид не сдохнет, как та корова?

Учить как финики...а у вам есть высшее финиковое образование?

Неа. Зато у меня есть более 15 лет разработки из которых лет 5 я ею управляю . Так что не то чтобы я хорошо разбирался в вопросе, но некий опыт имею. Хотя согласен с тем, что могу ошибаться . А у Вас, кстати, есть? Какого заведения и какого года выпуска, если не секрет?

Тимлид тем и отличаеться от PM'а, что разбирается во всех технических деталях своей команды иначе нафига он нужен (ставил бы PM задачи напрямую разработчикам)?

Кхм. Практический опыт показывает что микроменеджмент — это не очень хорошая практика. И что разработчикам надо давать немного свободы, иначе проект захлебывается в контроле а разработчики пухнут и дохнут. Но это наверное часть более глобального холивора, Agile versus Waterfall?

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

Ну вот как бы считается что Team Lead он как раз для того и сидит чтобы разбивку оценивать, указывать неточности, нюансы, помогать в сложных случаях, code review делать... ИМХО, если бы я за всех своих разработчиков классы писал и атомарные подзадачи ставил... Наверное, я бы гарантированно ничего не успел.

При таком повороте сюжета я с Вами соглашусь, что если тим лид микроменеджит разработчиков и ставит им строго атомарные задачи — то иерархия не нужна. Если же у нас Agile, то она как бы полезна. Мне больше Agile нравится, в SCRUM имплементации . Но это уже дело вкуса.

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

EOH>Но это наверное часть более глобального холивора, Agile versus Waterfall?

Нет, это не Agile vs. Waterfall, а разумный подход против бездумного.

P.S. Самый противный и нудный микроменеджмент я лично испытал как раз с одиной из конкретной реализацией SCRUM'а
Планировать и отчитываться перед командой с точностью до часа — это блин тот еще микроменеджмент

Высшее по "сбору фиников" у меня есть, скажу так один из тройки ведущих российских финансово-экономических вузов, закончил в самом начале 2000-х

Теперь про микроменеджмент, можно я начну с конца? Про SCRUM, вот я в свое время шарил некоторые программы для управлени по SCRUM — Targetprocess видел, работал и работаю в JIRA (счас кстати вы в курсе, что в новом GreenHopper есть проектные шаблоны, в том числе SCRUM и Kanban?), еще парочку из серии "всеонихзнают" и "зашибисьсколькостоит". Везде в SCRUM одноуровневая иерархия задач, точнее иерарахия юзерстори-задача один раз видел юзерстори — задача-подзадача и ...и все
Ведь ноги растут от доски, а как на доске создать подзадачу то?

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




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

EOH>

Учить как финики...а у вам есть высшее финиковое образование?

EOH>Неа. Зато у меня есть более 15 лет разработки из которых лет 5 я ею управляю . Так что не то чтобы я хорошо разбирался в вопросе, но некий опыт имею. Хотя согласен с тем, что могу ошибаться . А у Вас, кстати, есть? Какого заведения и какого года выпуска, если не секрет?

EOH>

Тимлид тем и отличаеться от PM'а, что разбирается во всех технических деталях своей команды иначе нафига он нужен (ставил бы PM задачи напрямую разработчикам)?

EOH>Кхм. Практический опыт показывает что микроменеджмент — это не очень хорошая практика. И что разработчикам надо давать немного свободы, иначе проект захлебывается в контроле а разработчики пухнут и дохнут. Но это наверное часть более глобального холивора, Agile versus Waterfall?

EOH>

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

EOH>Ну вот как бы считается что Team Lead он как раз для того и сидит чтобы разбивку оценивать, указывать неточности, нюансы, помогать в сложных случаях, code review делать... ИМХО, если бы я за всех своих разработчиков классы писал и атомарные подзадачи ставил... Наверное, я бы гарантированно ничего не успел.

EOH>При таком повороте сюжета я с Вами соглашусь, что если тим лид микроменеджит разработчиков и ставит им строго атомарные задачи — то иерархия не нужна. Если же у нас Agile, то она как бы полезна. Мне больше Agile нравится, в SCRUM имплементации . Но это уже дело вкуса.