Существуют в принципе два очень похожих вида программных инструментов:
— система управления задачами и
— система управления проектами.

Кто имеет большой опыт работы с ними, разъясните, пожалуйста:
1) в чем у них сходства и отличия?
2) существуют ли системы совмещающие в себе и систему управления задачами и систему управления проектами?

Задачи и проекты — это разные сущности. В общем случае задачи являются частью организации проекта. Соответственно, средства управления проектами содержат в себе средство управления задачами как подсистему.

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

AD>Задачи и проекты — это разные сущности. В общем случае задачи являются частью организации проекта. Соответственно, средства управления проектами содержат в себе средство управления задачами как подсистему.

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

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

E>Почему тогда большинство команд программистов используют именно
E>системы управления задачами типа JIRA, а не системы управлени проектами типа MS Project,
E>они же ведь проекты реализуют?

Потому что чтобы всерьез пользоваться MS Project нужно сильно упороться

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

E>Почему тогда большинство команд программистов используют именно
E>системы управления задачами типа JIRA, а не системы управления проектами типа MS Project,
E>они же ведь проекты реализуют?

Программисты реализуют поставленные задачи. Поэтому они пользуются средствами для управления задачами.
Проекты реализуют ответственные за проекты — руководители, менеджеры, отдельно выделенные программисты и т.п. Вот они как раз пользуются средствами управления проектами.

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

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

E>>Почему тогда большинство команд программистов используют именно
E>>системы управления задачами типа JIRA, а не системы управления проектами типа MS Project,
E>>они же ведь проекты реализуют?

AD>Программисты реализуют поставленные задачи. Поэтому они пользуются средствами для управления задачами.
AD>Проекты реализуют ответственные за проекты — руководители, менеджеры, отдельно выделенные программисты и т.п. Вот они как раз пользуются средствами управления проектами.

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

Делается ли так на самом деле?
Пользуются ли обычно менеджеры проектов чем-нибудь типа MS Project? Что-то я о таком не слышал.
Обычно вся команда включая менеджера работает в системе управления задачами типа JIRA.
Почему так?

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

E>Пользуются ли обычно менеджеры проектов чем-нибудь типа MS Project?
Да.

E>Что-то я о таком не слышал.
Плохо. Очень плохо

E>Обычно вся команда включая менеджера работает в системе управления задачами типа JIRA.
E>Почему так?
Я без понятия о какой конкретно команде ты говоришь, но могу лишь предположить, что проекты у неё настолько простые и их очень мало, что средство для управления проектами особо не требуется.

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

PS: JIRA — функциональная и расширяемая система. Она может использоваться много для чего, в том числе и для управления проектами.
PPS: ты бы почитал на эту тему что-нибудь. Все вопросы сами отпадут.

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

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

E>>Пользуются ли обычно менеджеры проектов чем-нибудь типа MS Project?
AD>Да.

E>>Что-то я о таком не слышал.
AD>Плохо. Очень плохо
ну вообще я конечно знаю, что MS-Project-ом пользуются,
я имел ввиду что здесь на форуме о нем не говорят, поэтому я и решил что не пользуются

E>>Обычно вся команда включая менеджера работает в системе управления задачами типа JIRA.
E>>Почему так?
AD>Я без понятия о какой конкретно команде ты говоришь, но могу лишь предположить, что проекты у неё настолько простые и их очень мало, что средство для управления проектами особо не требуется.
опять же я имел ввиду, что здесь на форуме говорят только про Джиру, и прочее

я в своих проектах использую MS Project

AD>К тому-же у тебя речь идёт о одной команде. А проект может охватывать несколько команд или несколько подразделений или даже несколько организаций. Кроме того, проектов, которые реализуются в конкретный момент времени (как одной командой, так и несколькими) может быть очень много, а некоторые из них могут быть связаны между собой. Вот и попробуй с таким состоянием дел управиться одними лишь задачами

AD>PS: JIRA — функциональная и расширяемая система. Она может использоваться много для чего, в том числе и для управления проектами.
AD>PPS: ты бы почитал на эту тему что-нибудь. Все вопросы сами отпадут.
посоветуй что-нибудь,
что почитать

E>что почитать

Тема называется "Программная инженерия".
SWEBOK (главы в pdf на русском)
Основы программной инженерии. Ицыксон (видео)

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

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

E>Существуют в принципе два очень похожих вида программных инструментов:
E>- система управления задачами и
E>- система управления проектами.

E>Кто имеет большой опыт работы с ними, разъясните, пожалуйста:
E>1) в чем у них сходства и отличия?
E>2) существуют ли системы совмещающие в себе и систему управления задачами и систему управления проектами?

Системы управления задачами (которые выросли из грубо говоря bug tracker'ов) — это некий административный инструмент для ведения списка появляющихся задач, распределения их между исполнителями и контроля их выполнения. Соответственно реализация всегда в виде какой-то разновидности базы данных с доступом каждого сотрудника.

Система управления проектами — это скорее аналитический инструмент для руководителя проекта, который позволяет составить план работ и оценить время работы, затраты и т.п. В простейшем случае это вообще может быть листок бумаги у руководителя. Часто это может быть лист excel'а. Но есть и специализированные удобные инструменты с уже реализованными диаграммами Ганта и т.п. В особо запущенных случаях (когда имеем множество руководителей на разных уровнях и т.п.) подобные инструменты тоже становятся многопользовательскими базами и даже посложнее систем управления задачами.

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

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

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

Вот ты, как менеджер, составил план проекта, сделал необходимые оценки, нарисовал диаграммы Ганта. В конечном итоге этот план найдет отражение в задачах в планировщике задач. Но как ты собираешься контролировать выполнение своего плана? Есть только три варианта: 1) руками в разных инструментах, 2) автоматически в разных инструментах и 3) автоматически в одном инструменте. Реальный выбор только между вариантами 2 и 3, и я бы не сказал что у варианта 2 есть какие-то ощутимые преимущества.

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

M>Вот ты, как менеджер, составил план проекта, сделал необходимые оценки, нарисовал диаграммы Ганта. В конечном итоге этот план найдет отражение в задачах в планировщике задач. Но как ты собираешься контролировать выполнение своего плана? Есть только три варианта: 1) руками в разных инструментах, 2) автоматически в разных инструментах и 3) автоматически в одном инструменте. Реальный выбор только между вариантами 2 и 3, и я бы не сказал что у варианта 2 есть какие-то ощутимые преимущества.

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

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

_>Не очень понял, речь о переносе пунктов плана в задачи? А зачем?

Попробую поработать телепатом.
Есть план (или даже ПЛАН). Он разбит на этапы, каждый этап — это совокупнсоть взаимосвязанных задач. И даже нам удалось задачи сформировать в виде дерева и загнать их в диаграмму Ганта.
И теперь есть желание знать — в каком состоянии _задачи_, т.к. задержка по какой-либо задаче может привести к задержке этапа и придется план (а это не просто план, а ПЛАН) переформатировать — этапы двигать, задачи перераскидывать (сроки поехали). А тут еще у сотрудниках есть задачи по другим проектам и надо согласовывать либо сдвижку задач по другим проектам либо выделение новых ресурсов...

"Враг заходит в город, пленных не щадя.
Оттого что в кузнице не было гвоздя" (с)

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

_>Не очень понял, речь о переносе пунктов плана в задачи? А зачем? Они же всё равно работают на совершенно разных уровнях детализации (каждый пункт плана обычно оборачивается множеством задач).

А как иначе этот план исполнять? Только конвертировав цели плана в задачи и назначив задачи на конкретных исполнителей.

_>Если бы системы управления задач были бы иерархическими, то это ещё имело бы какой-то смысл — тогда подобный перенос автоматически задавал бы верхний уровень иерархии задач. Но большинство современных систем линейные.

Уже не в первый раз встречаю среди менеджеров какую-то странную любовь к иерархическим задачам. Зачем? У тебя есть в плане цель сделать X. Ты разбиваешь эту цель на задачи A, B и C. Критерий достижения цели это закрытие всех трех задач A, B, C. Зачем здесь иерархия? Достаточно майлстоунов и версий.

_>Да, но даже если бы и были иерархическими, то всё равно как отслеживать по ним выполнение пункта плана? По соотношению открытых/закрытых задач? Но ведь при нормальной разработке абсолютно естественно появление новых задач по ходу дела, а не при старте модуля.

Контролировать выполнение плана нужно путем контроля за прогрессом задач относящихся к каждому пункту. Это не обязательно бинарное отношение "открыто/закрыто", это может быть оценка времени: потрачено 10 часов, осталось еще 2. Если в процессе реализации плана возникают новые задачи, их тем более нужно контролировать, так как они обязательно повлияют на срок исполнения плана. Причем в идеале на эти задачи нужно реагировать в тот момент когда они возникают, а не когда становится очевидно что сроки уже сорваны.

_>Не говоря уже о задачах на исправление багов. )

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

_>В общем я не вижу каким образом система управления задачами может на автоматическом уровне (а не на визуальном для оценки руководителем) помочь в отслеживание выполнения пунктов плана. А так я вообще за автоматизация всего и вся, так что если кто-то подскажет варианты, то буду только рад. Но что-то сомневаюсь, т.к. вижу тут не техническую проблему.

Ну насчет автоматизации всего и вся я бы сам послушал

Почему-то среди менеджеров тема интеграции управления задачами и управления проектами как-то непопулярна.

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

M>Уже не в первый раз встречаю среди менеджеров какую-то странную любовь к иерархическим задачам. Зачем? У тебя есть в плане цель сделать X. Ты разбиваешь эту цель на задачи A, B и C. Критерий достижения цели это закрытие всех трех задач A, B, C. Зачем здесь иерархия? Достаточно майлстоунов и версий.

M>Контролировать выполнение плана нужно путем контроля за прогрессом задач относящихся к каждому пункту.

Иерархические задачи позволяют решить две проблемы:
1. Разбить крупную задачу на более мелкие — для планирования
2. Объединять мелкие задачи в более крупные — для контроля

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

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

S>Попробую поработать телепатом.
S>Есть план (или даже ПЛАН). Он разбит на этапы, каждый этап — это совокупнсоть взаимосвязанных задач. И даже нам удалось задачи сформировать в виде дерева и загнать их в диаграмму Ганта.
S>И теперь есть желание знать — в каком состоянии _задачи_, т.к. задержка по какой-либо задаче может привести к задержке этапа и придется план (а это не просто план, а ПЛАН) переформатировать — этапы двигать, задачи перераскидывать (сроки поехали). А тут еще у сотрудниках есть задачи по другим проектам и надо согласовывать либо сдвижку задач по другим проектам либо выделение новых ресурсов...

Так я же говорю, что задачки в диаграмме Ганта — это совсем не тоже самое, что нормальные задачке в трекере (эти намного меньше). Просто потому, что подобная детализация не нужна (а иногда и невозможна) на этапе планирования (для которого в основном и нужны инструменты управления проектами).

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

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

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

M>А как иначе этот план исполнять? Только конвертировав цели плана в задачи и назначив задачи на конкретных исполнителей.

Это понято. Но в нормальном трекере принято работать немного на другом уровне детализации. Грубо говоря по задачке на каждый мелкий баг.

M>Уже не в первый раз встречаю среди менеджеров какую-то странную любовь к иерархическим задачам. Зачем? У тебя есть в плане цель сделать X. Ты разбиваешь эту цель на задачи A, B и C. Критерий достижения цели это закрытие всех трех задач A, B, C. Зачем здесь иерархия? Достаточно майлстоунов и версий.

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

M>Контролировать выполнение плана нужно путем контроля за прогрессом задач относящихся к каждому пункту. Это не обязательно бинарное отношение "открыто/закрыто", это может быть оценка времени: потрачено 10 часов, осталось еще 2. Если в процессе реализации плана возникают новые задачи, их тем более нужно контролировать, так как они обязательно повлияют на срок исполнения плана. Причем в идеале на эти задачи нужно реагировать в тот момент когда они возникают, а не когда становится очевидно что сроки уже сорваны.

Так а в какую сущность то отображаются пункты плана в трекере?

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

Вот вот. В задаче из описания проекта исправление багов к задачке грубо говоря входит в неё саму. А в трекере каждый баг является отдельной сущностью. И как это совмещать между собой? У меня пока есть только один ответ — трекер с иерархическим устройством. Но я не особо уверен в удобстве подобного. Во всяком случаем сам ничем подобным не пользовался.

M>Ну насчет автоматизации всего и вся я бы сам послушал
M>Почему-то среди менеджеров тема интеграции управления задачами и управления проектами как-то непопулярна.

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

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

_>Так я же говорю, что задачки в диаграмме Ганта — это совсем не тоже самое, что нормальные задачке в трекере (эти намного меньше). Просто потому, что подобная детализация не нужна (а иногда и невозможна) на этапе планирования (для которого в основном и нужны инструменты управления проектами).

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

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

M>>Контролировать выполнение плана нужно путем контроля за прогрессом задач относящихся к каждому пункту. Это не обязательно бинарное отношение "открыто/закрыто", это может быть оценка времени: потрачено 10 часов, осталось еще 2. Если в процессе реализации плана возникают новые задачи, их тем более нужно контролировать, так как они обязательно повлияют на срок исполнения плана. Причем в идеале на эти задачи нужно реагировать в тот момент когда они возникают, а не когда становится очевидно что сроки уже сорваны.

_>Так а в какую сущность то отображаются пункты плана в трекере?

В версии/майлстоуны, например. Если по плану тебе требуется чтобы задачи A, B и C были готовы к определенной дате, ты создаешь майлстоун и привязываешь к нему эти задачи. Если появляется говая задача, ты должен привязать ее либо к этому, либо к следующему майлстоуну. В любой момент по таймтрекингу будет видно, успеваете вы к майлстоуну за оставшееся время или нет.

_>Вот вот. В задаче из описания проекта исправление багов к задачке грубо говоря входит в неё саму. А в трекере каждый баг является отдельной сущностью.

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

_>И как это совмещать между собой? У меня пока есть только один ответ — трекер с иерархическим устройством. Но я не особо уверен в удобстве подобного. Во всяком случаем сам ничем подобным не пользовался.

Майлстоуны + зависимые задачи + оценки времени заменяют иерархию.

_>Вообще говоря, т.к. эти две системы всё же предназначены для разных пользователей (точнее одна для всех, а другая только для руководителей), то не факт что правильно их совмещать в одну сущность. А вот сделать какую-то автоматическую интеграцию наверное правильно. Что-то вроде экспорта задач в трекер и импорт статусов задач из него же.

Вроде есть сторонние плагины для интеграции MS Project и Jira, но я ими не пользовался.

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

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

А с помощью чего начальные расчёты делаются? ) Ну чтобы банально сказать что-то вроде "нам надо N месяцев и M денег на проект". )