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

Здравствуйте, 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). Поэтому выбор программной платформы для ведения проектов и задач всегда сугубо индивидуальный для РП.

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


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

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

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

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

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

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


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

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

ссылка

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