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

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

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

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

Системы управления задачами (Мегаплан, Basecamp и тд) больше заточены на операционную деятельность, чтобы дать поручение сотруднику и если он не сделал в срок, то вкатить ему штраф. Поэтому там больше инструментов для контроля сроков задач.

Системы управления проектом (Адванта, Spider Project, MS Project) фокусируются на разбивке проекта на пакеты работ, формирование иерархической структуры работ, построение календарного план-графика , управление реестром рисков проекта. Но большая часть таких систем только показывает текущее состояние но не выполняет никаких прогнозов. Часто такая система не предусматривает взаимодействие команды, так как вся деятельность по построению планов лежит в ответственности руководителя проектов. Но есть и сетевые решения, но они часто оптимизированы под большие компании для проектов внедрения и имеют встроенную систему документооборота (СЭД).
Большая часть таких систем не учитывают особенностей ИТ проектов, и то что оценки в ИТ проектах ВСЕГДА неверные, а значит и отклонение от базового плана всегда будет и нужно выполнять прогнозирование на основе скорость выполнения объема.


E>2) существуют ли системы совмещающие в себе и систему управления задачами и систему управления проектами?

Да. Но хороших мало, из за того что рядовому исполнителю, для ИТ это разработчикам, тестировщикам нужны задачи в виде потока "к исполнению", и удобная интеграция с VCS, а проектному менеджеру нужны проектные метрики, и представления которые не нужны разработчику.

Часто это делается плагинами в багтрегинг системам, или системами отчетов, который "должны помогать РП принимать решения".

Мы в Инструменте планирования проектов BiPulse (http://bipulse.ru) постарались совместить несовместимое. С одной стороны исполнитель работает задачами по проекту, а с другой стороны, руководитель проекта получает метрики проекта и прогнозы по завершению этапа работ. Кроме того система подсказывает что нужно делать в текущий момент.

Однако, столь любимой всеми диаграммы Гантта у нас еще нет. Потому, что для программных проектов, диаграмма Гантта в статичном виде бесполезна, и даже вредна, так как дает ложное представление о выполнимости проекта в срок. Но с другой стороны она полезна при стыковке стыковки разных продуктов на уровне этапов работ или пакетов работ необходимых для выполнения сложного проекта.
Я считаю, что для ИТ проектов диаграмма Гантта, может быть полезна только в варианте автоматической актуализации и визуализации "критической цепи" для того чтобы понимать когда примерно будет занят сотрудник и чем. В этом качестве мы скоро её сделаем в ближайшей версии BiPulse.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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: ты бы почитал на эту тему что-нибудь. Все вопросы сами отпадут.
посоветуй что-нибудь,
что почитать

Здравствуйте, 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 денег на проект". )

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

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

Tоже вариант. ) Хотя опять же всё руками, без всякой автоматизации...

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

Pо сути это и есть иерархия, только такая, гетерогенная... )

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

Ну так мы вот даже не может точно сформулировать в каком виде хотим экспорт плана в задачки — куда уж тут ждать нормальные реализации. )

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

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

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

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

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

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

Планирование задач — это лишь одна из задач при управлении проектом. Есть еще управление бюджетом, ресурсами, рисками, ожиданиями клиентов. If-else анализ и т.д. Да, при большом желании можно все это запихать в джиру, как можно и с помощью напильника из болванки паровоз выточить.

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

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

что такое майлстоуны — понятно,
а что такое версии?
и, говоря о создании майлстоуна и привязке к нему задач, ты имеешь ввиду где это делать: в системе управления проектами?
как в MS Project-е к майлстоуну можно "привязать" задачу?

M>В любой момент по таймтрекингу будет видно, успеваете вы к майлстоуну за оставшееся время или нет.

в какой системе и как выполняется таймтрекинг с помощью майлстоунов?

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

E>что такое майлстоуны — понятно,
E>а что такое версии?

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

E>и, говоря о создании майлстоуна и привязке к нему задач, ты имеешь ввиду где это делать: в системе управления проектами?
E>в какой системе и как выполняется таймтрекинг с помощью майлстоунов?

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

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

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

E>>что такое майлстоуны — понятно,
E>>а что такое версии?

M>С точки зрения управления то же самое только вид сбоку.

E>>и, говоря о создании майлстоуна и привязке к нему задач, ты имеешь ввиду где это делать: в системе управления проектами?
E>>в какой системе и как выполняется таймтрекинг с помощью майлстоунов?

M>В системе управления задачами. Смотришь на задачи привязанные к майлстоуну, суммируешь ET и ST, вычитаешь одно из другого и получаешь сколько еще часов необходимо потратить чтобы достичь майлстоуна.

а разве в системе управления задачами можно создавать майлстоуны?

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

Из предыдущих ответов вроде как понятно, что это две разные системы.
Но они должны быть между собой взаимосвязаны.
Мы сейчас пытаемся начать работу в MS Project и Jira.

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

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

спасибо, посмотрю

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

что такое "системы распределения"?

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

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

E>что такое "системы распределения"?

Система распределения задач между участниками проекта, в топике она же система управления задачами или попросту трекер. Опять же система управления проектом это не просто распределение задач, но нечто другое или нечто большее.

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

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

E>Из предыдущих ответов вроде как понятно, что это две разные системы.
E>Но они должны быть между собой взаимосвязаны.
E>Мы сейчас пытаемся начать работу в MS Project и Jira.

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


А почему вы не хотите рассмотреть более простые варианты? Например, есть же система управления задачами Workdoer. Попробуйте, вам должно понравиться.

V>Тема называется "Программная инженерия".
V>SWEBOK (главы в pdf на русском)
404

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

E>Кто имеет большой опыт работы с ними, разъясните, пожалуйста:
E>1) в чем у них сходства и отличия?
Управление проектами включает в себя управление задачами, но им не ограничивается. Если посмотреть на активности, связанные с управлением проектами, и описанные в PMBoK, то там есть еще и задачи, связанные с коммуникациями, бюджетированием, распределением ресурсов и т.д. Тот же MS Project не закрывает весь спектр задач, т.к., например, не управляет проектной документацией.

E>2) существуют ли системы совмещающие в себе и систему управления задачами и систему управления проектами?
Чтобы делали вообще всё — таких не знаю. Многое, но не все — например, Intland CodeBeamer.

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


C>Однако, столь любимой всеми диаграммы Гантта у нас еще нет. Потому, что для программных проектов, диаграмма Гантта в статичном виде бесполезна, и даже вредна, так как дает ложное представление о выполнимости проекта в срок. Но с другой стороны она полезна при стыковке стыковки разных продуктов на уровне этапов работ или пакетов работ необходимых для выполнения сложного проекта.
C>Я считаю, что для ИТ проектов диаграмма Гантта, может быть полезна только в варианте автоматической актуализации и визуализации "критической цепи" для того чтобы понимать когда примерно будет занят сотрудник и чем. В этом качестве мы скоро её сделаем в ближайшей версии BiPulse.

Если говорить о диаграмме Ганта в статичном виде — в том когда проект был сделан и без дальнейшего его ведения, то такая диаграмма ненужна ни в одной системе управления проектами (это тот вид, когда в MS Project задали базовый план и больше не отмечается факт). Естественно, диаграмма Ганта должна отображать изменения в ходе движения по проекту. (Дальше про MS Project) Это различные варианты отображения — на одной диаграмме вместе базовый план и прогноз, там же показывать временной резерв, названия ресурсов, вехи и др. Но одна диаграмма для контроля тоже не удобна, она должна сопровождаться настроенной таблицей с полями — числовые расчеты по резерву, индикаторное обозначение критических задач, опозданий, опережений и т.п.

Визуализация критической цепи (если мы говорим именно о цепи, а не о пути) в проджекте более удобна в визуальном оптимизаторе ресурсов (версия 2013). Вот там как раз и видно, кто когда чем занимается, у кого планируется перегруз и т.п.

V>Визуализация критической цепи (если мы говорим именно о цепи, а не о пути) в проджекте более удобна в визуальном оптимизаторе ресурсов (версия 2013). Вот там как раз и видно, кто когда чем занимается, у кого планируется перегруз и т.п.

можешь скриншот выложить где это видно?

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


E>можешь скриншот выложить где это видно?

Скриншот своего портфеля проектов я выкладывать не буду, уж простите, но принципиально выглядит он примерно так, как на первом скриншоте на странице по ссылке

ссылка

По шкале Х — календарь, по шкале Y — ресурсы. В красных скобках — перегруз по ресурсу.