Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Ну да, сложить и разделить. Я же не против прожекта совсем, просто мне кажется, что при Вашей нагрузке, все можно делать и без него. Если Вы считаете, что не сможете без него обойтись, то что же делать — используйте его.
А есть какие-нибудь плагины для JIRA, упрощающие планирование? Понятно, что могу поискать и найти. Подозреваю, их будет много. Может, у кого-нить есть позитивный опыт работы с каким-нибудь плагином?
Re[10]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там
Здравствуйте, stranger_v, Вы писали:
_>>>Да, и еще... Проджект дает мне возможность при смене сроков текущей задачи автоматически сдвигать даты начала/конца следующих задач, которые зависят от этой, либо сдвигать аналогично даты по выравниваю. Может ли это сделать JIRA?
G>>TheConnector попробуй, ссылку на который я дал. И JIRA все сможет.
_>500$ за одного пользователя!!! Это ж нифига себе!! Можно ли как-то с более доступными технологиями все порешать? Возможно, самой JIRA или какими-то плагинами к ней?
Здравствуйте, Gaperton, Вы писали:
G>Ее надо "вбить" ровно столько, сколько в принципе необходимо для того, чтобы рассчитать сроки.
Это трюизм. S>>И как поддерживать эту информацию актуальной — непонятно. О чём я и написал в своём посте. G>А вот кэп мне шепчет, что должно быть как минимум два варианта — либо руками, либо автоматом.
Это тоже.
S>>Я, судя по всему, так и не понял, как это правильно использовать. G>Ты меня поражаешь.
Может, вместо того, чтобы поражаться, вы объясните подробный алгоритм использования проджекта? В вашей статье, простите, написаны только настройки, которые надо сделать в проджекте, и то, какие View важнее, чем другие.
Как-то не раскрыты темы
1. Как именно определить длительность проекта, исходя из входящих в него задач
2. Как определить, сколько нужно людей, чтобы выполнить этот проект
3. Как вносить изменения в Project по ходу выполнения проекта
4. Как определить причины изменений сроков и стоимости по сравнению с изначальным планом
Понятное дело, с учётом того, что этап первоначального планирования должен занимать приемлемое время. Когда тим лидера просят спланировать разработку на следующие полгода для команды в 8 человек, он не может себе позволить забить и оценить ~2000 задач. Тем более что гантт с такими объёмами будет абсолютно не наглядным. И вообще я не нашёл в проджекте ни одного способа приемлемо визуализировать такие объёмы информации.
А то, как переключить левелинг по приоритету на левелинг по ID, это не очень интересно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там
Здравствуйте, Sinclair, Вы писали:
S>>>И как поддерживать эту информацию актуальной — непонятно. О чём я и написал в своём посте. G>>А вот кэп мне шепчет, что должно быть как минимум два варианта — либо руками, либо автоматом. S>Это тоже.
Странно, строкой выше ты написал, что тебе это непонятно (см. выделенное).
S>>>Я, судя по всему, так и не понял, как это правильно использовать. G>>Ты меня поражаешь.
S>Может, вместо того, чтобы поражаться, вы объясните подробный алгоритм использования проджекта? В вашей статье, простите, написаны только настройки, которые надо сделать в проджекте, и то, какие View важнее, чем другие.
Пошаговый алгоритм его использования содержится в туториале, который встроен в MS Project. Я — читал.
Ты хочешь, чтобы я его тебе в деталях, подробно, и по шагам воспроизвел в форуме? Зачем? Тебе что-то мешает самому нажать кнопку Help?
S>1. Как именно определить длительность проекта, исходя из входящих в него задач
Посмотреть на график справа[/b], там будет это будет прекрасно видно. Не ошибешься.
S>2. Как определить, сколько нужно людей, чтобы выполнить этот проект
Выходит за рамки вопросов использования MS Project.
S>3. Как вносить изменения в Project по ходу выполнения проекта
Пункт (8) заметки в ЖЖ. С подробностями в Help MS Project.
Веб-интерфейс MS Project. С подробностями в Help к MS Project Server.
Выходит за рамки вопросов использования MS Project.
S>Понятное дело, с учётом того, что этап первоначального планирования должен занимать приемлемое время.
Не важно. К вопросам работы с MS Project не относится.
S>Когда тим лидера просят спланировать разработку на следующие полгода для команды в 8 человек, он не может себе позволить забить и оценить ~2000 задач.
Когда какого-то твоего знакомого тим-лида просят спланировать, он не может себе позволить все бросить, и оценить. Понятно.
Какое отношение проблемы твоего тимлида имеют к вопросам использования MS Project? Непонятно.
S> Тем более что гантт с такими объёмами будет абсолютно не наглядным. И вообще я не нашёл в проджекте ни одного способа приемлемо визуализировать такие объёмы информации.
Вложенные задачи. Внешние проекты. Что такое? Читай мануал.
S>А то, как переключить левелинг по приоритету на левелинг по ID, это не очень интересно.
Если честно, мне вообще не очень интересно тебе отвечать. Мне не очень понятно, когда непонимание базовых вещей облекается в форму претензии.
Re[3]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там и
_>Ой, а без TFS можно? Я уже ориентируюсь на JIRA. Нашел дешевый JIRA-хостинг. Можно ли как-то обойтись только JIRA, без Project?
Первая ссылка в гугле http://www.the-connector.com/index.aspx
Народная мудрось
всем все никому ничего(с).
Re[4]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там и
Здравствуйте, Tom, Вы писали:
_>>Ой, а без TFS можно? Я уже ориентируюсь на JIRA. Нашел дешевый JIRA-хостинг. Можно ли как-то обойтись только JIRA, без Project? Tom>Первая ссылка в гугле Tom>http://www.the-connector.com/index.aspx
Так это же плагин для MS Project. Который к тому же и стоит 500$ за однопользовательскую лицензию...
Re[4]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там и
Здравствуйте, stranger_v, Вы писали:
_>Аноним, поделитесь опытом, пожалуйста, как у вас получается контролировать и рассчитывать сроки, используя JIRA?
Я не Аноним, но у меня как-то получается.
_>Неужели Вы полностью все работы учитываете и покрываете тасками? Без исключения?
Конечно. Невозможно планировать то что не оценено и оценивать то, что не записано.
_>Как тогда оценить общий срок проекта?
Сложить оценки всех задач, добавить фиксированный гэп между задачами, разделить на количество людей и перевести часы в календарную дату.
_>Ведь тасками занимается разное количество людей, где-то эти таски можно распараллелить, где-то одни зависят от других. Как высчитать конечный срок?
По моему опыту то совершенно не важно. Зависимые здачи встречаются настолько редко, что никакого измеримого влияния на ход проекта не оказывают. Для оценки сроков достаточно допущения что при достаточно хорошем оперативном управлении все задачи могут выполняться параллельно.
Re[11]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там
Здравствуйте, Gaperton, Вы писали:
G>Дык и Project сам по себе недешевый, не?
Дык я не хочу Project уже, я нашел бесплатный вариант — Gantter. Он может ставиться в гугл докс еще. Он вполне устраивает меня для планнига. Но это все равно получается два инструмента.
G>Ну вот сейчас у меня стоит вот эта штука: G>https://plugins.atlassian.com/plugins/com.soyatec.jira.plugins.jira-ganttchart-project
G>Попробуй ее, может подойдет. Вроде по описанию все должна уметь.
По описанию все выглядит круто, спасибо за ссылку. По отзывам на той страничке выходит, что сыровата. Попробую на днях — отпишусь. Знает кто проверенные плагины?
Re[5]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там и
Здравствуйте, Miroff, Вы писали:
_>>Как тогда оценить общий срок проекта?
M>Сложить оценки всех задач, добавить фиксированный гэп между задачами, разделить на количество людей и перевести часы в календарную дату.
_>>Ведь тасками занимается разное количество людей, где-то эти таски можно распараллелить, где-то одни зависят от других. Как высчитать конечный срок?
M>По моему опыту то совершенно не важно. Зависимые здачи встречаются настолько редко, что никакого измеримого влияния на ход проекта не оказывают. Для оценки сроков достаточно допущения что при достаточно хорошем оперативном управлении все задачи могут выполняться параллельно.
Хм, интересно... Спасибо за Вашу методологию... Есть о чем подумать...
Единственное что, сразу дополню, что у меня есть разные люди, которые могут делать только свою часть работы. Поэтому, выходит, нужно брать по самому загруженному, вот и будет конечный срок.
Кстати, а сколько гэпа между задачами Вы обычно закладываете и как Вы его рассчитываете? Можете поделиться опытом?
Re[11]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там
Здравствуйте, Sinclair, Вы писали:
S>Понятное дело, с учётом того, что этап первоначального планирования должен занимать приемлемое время. Когда тим лидера просят спланировать разработку на следующие полгода для команды в 8 человек, он не может себе позволить забить и оценить ~2000 задач.
MS Project вообще не предназначен для того, чтобы в нем "тимлиды планировали разработку на следующие полгода".
Он предназначен для шедулинга и отслеживания ходя выполнения проекта. То есть, осмысленной деятельности с конкретной конечной целью, определенным уникальным финальным результатом, имеющей начало, и конец. А не для того, чтобы как-то спланировать процесс копания от забора до обеда.
Наличие целенаправленной (проектной) деятельности (то есть, первичности цели, которую надо достичь, а не двух тысяч мелких слабосвязанных друг с другом задач, и срока взятого от балды) здесь принципиально — только в этом случае тебе интересны разнообразные "критические пути" и прочее.
В случае же тимлида с кучей задач контекст другой, и надо применять другие подходы.
И Project в этом совершенно не виноват. Этот факт, видишь-ли, не делает Project ни лучше, ни хуже. И, по идее, не должен мешать тебе понять, для каких ситуаций предназначен Project.
Re[12]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там
22.05.2012 16:18, Gaperton написал:
> MS Project вообще не предназначен для того, чтобы в нем "тимлиды > планировали разработку на следующие полгода".
Мало-ли для чего он не предназначен. Именно для этого его чаще всего и
используют. Особенно прикольно, когда в нем планируют с детализацией 3
дня на год вперед все что можно и нельзя.
Posted via RSDN NNTP Server 2.1 beta
Re[5]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там и
22.05.2012 15:30, Miroff написал:
> По моему опыту то совершенно не важно. Зависимые здачи встречаются > настолько редко, что никакого измеримого влияния на ход проекта не > оказывают. Для оценки сроков достаточно допущения что при достаточно > хорошем оперативном управлении все задачи могут выполняться параллельно.
Очень интересно. У меня совершенно противоположный опыт.
Кстати, когда некто предполагал, что все задачи можно распараллелить,
обычно выходил провал проекта.
Posted via RSDN NNTP Server 2.1 beta
Re: MS Project + JIRA - как не дублировать работу (одни и те же таски и там и та
Здравствуйте, stranger_v, Вы писали:
_>Всем привет!
_>Вот, запустил свой бизнес по созданию интернет порталов. Не могу понять, как эффективно построить управление проектом.
_>В частности, нужен проектный план. Классический, где большие куски работы, связи между ними, назначенные работники и т.д. Чтобы можно было увидеть, когда что примерно будет готово, и успеваем мы или нет. Для этого хорошо подходит MS Project или OpenProj.
_>С другой стороны с этим сложно работать обычным разработчикам. Им нужно назначать уже конкретные задачи (иногда небольшие, являющиеся частью большого куска работы) с детальным описанием, что нужно сделать. Поэтому здесь поможет система типа JIRA или Redmine. Где можно назначать тикеты на разработку некоего конкретного функционала с подробным описанием.
_>Неужели нельзя избежать дублирования работы???
Добавлю свои пять копеек.
Мы используем MS Project в связке с http://www.criticaltools.com/ на начальном этапе для построения WBS и грубого планирования на задачах без сильной детализации, но с оценкой трудоемкости.
В результате получаем список контрольных точек (вехи) с датами. Контрольные точки достаточно часто 2-3 недели макс. Этого достаточно для разговоров с Заказчиком.
Далее это в JIRA, возможно с дроблением задач под программистов и, самое главное, с привязкой к контрольным точкам. В JIRA даты только у контрольных точек. У задач дат нет.
Для очень небольшого количества задач вешаем зависимости средствами JIRA.
Проверяем что получилось с учетом загрузки программеров по другим проектам.
К MS Project'у по данному проекту никогда больше не возвращаемся.
Контроль и коррекция планов строго по контрольным точкам в JIRA.
Поскольку задач даже в большом проекте за 2-3 недели будет немного, никаких проблем с перепланированием и с контролем выполнения нет.
Большие проекты разделены на компоненты, что еще больше упрощает планирование и управление.
Re[12]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там
Здравствуйте, Gaperton, Вы писали:
G>Пошаговый алгоритм его использования содержится в туториале, который встроен в MS Project. Я — читал.
Я — тоже. G>Ты хочешь, чтобы я его тебе в деталях, подробно, и по шагам воспроизвел в форуме? Зачем? Тебе что-то мешает самому нажать кнопку Help?
S>>1. Как именно определить длительность проекта, исходя из входящих в него задач G>Посмотреть на график справа[/b], там будет это будет прекрасно видно. Не ошибешься.
Конечно же ошибусь.
G>Выходит за рамки вопросов использования MS Project.
S>>3. Как вносить изменения в Project по ходу выполнения проекта G>Пункт (8) заметки в ЖЖ. С подробностями в Help MS Project.
Не раскрыта тема отказа от ненужных более задач; не раскрыта тема разбиения задач на подзадачи "на ходу", при уточнении проекта.
G>Выходит за рамки вопросов использования MS Project. G>Не важно. К вопросам работы с MS Project не относится. G>Какое отношение проблемы твоего тимлида имеют к вопросам использования MS Project? Непонятно.
Вот поэтому я и говорю, что в функции MS Project входит только рисование гантт-чарта. Всё остальное — "выходит за рамки вопросов использования MS Project", а это как раз ежедневная деятельность тим лида.
Получается этакая каша из топора.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там
Здравствуйте, Gaperton, Вы писали:
G>Он предназначен для шедулинга и отслеживания ходя выполнения проекта. То есть, осмысленной деятельности с конкретной конечной целью, определенным уникальным финальным результатом, имеющей начало, и конец. А не для того, чтобы как-то спланировать процесс копания от забора до обеда.
Ещё раз: размер приведён просто для сопоставления масштабов. В нормальном софтостроении не бывает релизов раз в неделю. Вот, скажем, у микрософта цикл длиной в три года; у нас — примерно в год.
Когда мы готовим релиз, у которого есть конечная цель, определённый уникальный финальный результат, начало, и конец, нам надо его спланировать.
Основные вопросы, на которые должен отвечать тим лид, это "когда будет готово", "что именно будет готово", "почему изменились результаты", и "как скорректировать план в соответствии с новой ситуацией".
Для этого и нужен инструмент. Инструмент для рисования гантт-чартов — не нужен. Гантт чарт шириной в 12 месяцев и высотой в 4000 задач абсолютно неинформативен.
G>Наличие целенаправленной (проектной) деятельности (то есть, первичности цели, которую надо достичь, а не двух тысяч мелких слабосвязанных друг с другом задач, и срока взятого от балды) здесь принципиально — только в этом случае тебе интересны разнообразные "критические пути" и прочее.
Давайте разберёмся. Ведущие собаководы рекомендуют при оценках не делать задачи длиннее 4х часов. Иначе вы рискуете ошибиться в оценке на порядок.
Я вам привёл пример на пальцах про копание канавы, который вы проигнорировали. Чтобы корректно получить длительность проекта, нам нужно одно из двух:
а) сделать зависимость для прокладки трубы не finish-to-start, а start-to-start с задержкой в неделю (есть риск ошибиться, т.к. эта неделя взята более-менее с потолка)
б) поделить задачи копания канавы и укладки трубы на мелкие поздадачи, в которых уже будут честные finish-to-start зависимости.
Второй способ точнее, и он автоматически адаптируется к реальному прогрессу. Потому, что если в первом способе мы за первую неделю прокопали вдвое меньше, чем планировали, проджект по-прежнему будет оптимистично рапортовать, что укладку можно начинать.
Отсюда мы и получаем порядка 2000 задач, из которых состоит проект для маленькой команды, занимающий примерно шесть месяцев.
При этом для согласования проекта нужно оценить не 2000 задач, а примерно 6000, потому что две трети в итоге будут выкинуты в результате многочисленных болезненных обсуждений. Т.к. хотят все сразу всего, а ресурсов есть только для 30%.
Что вы предлагаете с этим делать? Или это тоже "выходит за рамки использования MS Project"?
G>И Project в этом совершенно не виноват. Этот факт, видишь-ли, не делает Project ни лучше, ни хуже. И, по идее, не должен мешать тебе понять, для каких ситуаций предназначен Project.
Простите, а что мне поможет понять, для каких ситуаций он предназначен? Пока что я видел на практике только одно предназначение — один раз в начале проекта нарисовать красивый водопадный план, состоящий из псевдозадач типа "закодить всё, протестировать всё", получить аппрувал, а потом выбросить его и больше никогда не возвращаться.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там
Здравствуйте, Sinclair, Вы писали:
S>>>1. Как именно определить длительность проекта, исходя из входящих в него задач G>>Посмотреть на график справа[/b], там будет это будет прекрасно видно. Не ошибешься. S>Конечно же ошибусь.
Оснований не верить тебе (что лично ты можешь ошибиться) у меня нет — но я ничем не могу помочь.
Ибо я искренне не понимаю, как тут можно ошибиться.
S>>>3. Как вносить изменения в Project по ходу выполнения проекта G>>Пункт (8) заметки в ЖЖ. С подробностями в Help MS Project. S>Не раскрыта тема отказа от ненужных более задач; не раскрыта тема разбиения задач на подзадачи "на ходу", при уточнении проекта.
В сравнении с типичным учебником по MS Project, у меня там, вообще, очень много тем "не раскрыто". Намекать не надо. Если ты считаешь нужным — почему бы тебе не сказать прямо и не обозначить проблему явно. Догадываться, какие из них ты считаешь необходимым раскрыть, и почему (т.е. "продумывать ходы за тебя") — я не буду.
В чем у тебя проблема с удалением задач и добавлением новых, и откуда они берутся — я не понимаю. У меня это никогда проблем не вызывало.
G>>Выходит за рамки вопросов использования MS Project. G>>Не важно. К вопросам работы с MS Project не относится. G>>Какое отношение проблемы твоего тимлида имеют к вопросам использования MS Project? Непонятно.
S>Вот поэтому я и говорю, что в функции MS Project входит только рисование гантт-чарта. Всё остальное — "выходит за рамки вопросов использования MS Project", а это как раз ежедневная деятельность тим лида.
"Поэтому" подразумевает наличие причинно-следственной связи.
Я, во-первых, ее в твоем рассуждении не вижу (ну не понимаю я, каким образом из личных проблем одного тимлида в принципе могут следовать какие-либо утверждения о функциональности Project).
А во-вторых, вывод твой объективно неверен, ибо в функции project входит как минимум resource leveling. И еще много чего.
Принимая это во внимание — я не понимаю, что в принципе можно тебе осмысленного ответить, ибо ты ставишь меня в тупик. Ты зачем меня поражаешь?
S>Получается этакая каша из топора.
Вот с этим согласен.
Re[13]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там
On 22.05.2012 19:03, Sinclair wrote:
> Простите, а что мне поможет понять, для каких ситуаций он предназначен? > Пока что я видел /на практике/ только одно предназначение — один раз в > начале проекта нарисовать красивый водопадный план, состоящий из > псевдозадач типа "закодить всё, протестировать всё", получить аппрувал, > а потом выбросить его и больше никогда не возвращаться.
Ну, вы всё верно поняли-то Конечно не "закодить всё, протестить
всё", но очень coarse-grained. И после утверждения оставить только для
ретроспективных целей.
Не, я видел конечно людей, героически скрещивающих его с багтрекером и
т.п., но их ежедневная мучительная деятельность по синхронизации этого
добра и попытки извлечь из этой интеграции какую-то пользу напоминали
старый анекдот про "я вот сегодня и на мойку успел и на заправку и
резину зимнюю на летнюю сменил и масло в двигателе! без машины столько
ни в жизнь бы не успел сделать."
--
WBR,
Serge.
Posted via RSDN NNTP Server 2.1 beta
Re[14]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там
Если вам непонятен пример из 2х задач — не стесняйтесь, спрашивайте.
G>В сравнении с типичным учебником по MS Project, у меня там, вообще, очень много тем "не раскрыто". Намекать не надо. Если ты считаешь нужным — почему бы тебе не сказать прямо и не обозначить проблему явно. Догадываться, какие из них ты считаешь необходимым раскрыть, и почему (т.е. "продумывать ходы за тебя") — я не буду.
Я сказал прямо, и проблемы обозначил. G>В чем у тебя проблема с удалением задач и добавлением новых, и откуда они берутся — я не понимаю. У меня это никогда проблем не вызывало.
Проблемы — очень простые: Невозможность сравнить план с baseline. Вместе с удаленим задачи навсегда исчезает вся информация о ней.
То есть проджект ничего не может предложить для самого основного сценария уточняющегося планирования: берём задачу размером в человеко-неделю и режем на задачи по 2-4 часа. При этом первые шесть часов на эту задачу могут быть уже отрепорчены. Нормальная, жизненная ситуация. "Выходит за рамки вопросов использования MS Project". Отож.
G>"Поэтому" подразумевает наличие причинно-следственной связи.
Ну так если из четырёх вопросов на три ответ "он не для этого", а на один — "я не понимаю, в чём проблема", то какие ещё причинно-следственные связи нужны?
G>Я, во-первых, ее в твоем рассуждении не вижу (ну не понимаю я, каким образом из личных проблем одного тимлида в принципе могут следовать какие-либо утверждения о функциональности Project).
Нет никаких личных проблем. Это вопросы, которые ставит работа перед каждым менеджером малого подразделения. Ответов на них проджект не даёт. Вопрос: а для чего он тогда?
G>А во-вторых, вывод твой объективно неверен, ибо в функции project входит как минимум resource leveling. И еще много чего.
В таких объёмах, как вы рассказали в своей заметке, ресурс левелинг входит и в MS Visio. То есть просто лепим одну задачку за другой — и всё. Понятно и наглядно.
Мне более-менее безразличны тысячи функций проджекта, пока они не помогают решать основную задачу менеджера: спланировать загрузку ресурсов в динамически изменяющемся окружении.
S>>Получается этакая каша из топора. G>Вот с этим согласен.
Поясню на отдалённом примере. Есть такой тип программно-аппаратных решений, называется "спутниковый навигатор". Он помогает водителю планировать маршрут и идти по нему.
То есть водитель ставит задачу, "попасть в точку B". Иногда — более сложную задачу "попасть в точку B, потом в C, потом в D, и между С и D нужно найти заправку".
Навигатор прокладывает ему маршрут, и напоминает о действиях, которые нужно выполнять по ходу маршрута.
Пока что всё вполне аналогично работе проджекта — мы описываем точку B в терминах шагов, которые нужны для её достижения, проджект рисует путь до неё, который не противоречит физической реальности. Мы можем играть вариантами, выбирая между рискованными или менее дорогими вариантами.
Но проджект в итоге оставляет тебя с распечатанной картой, и если ты простоял в пробке, свернул не туда, или решил заехать по пути в ашан, то проджект тебе ничем не поможет. Даже если ты заносишь в него выполненные действия с методичностью GPS-приёмника. Он не подскажет, куда свернуть, чтобы вернуться на маршрут, не скажет, сколько теперь осталось ехать.
Нет, такой "одноразовый навигатор" — тоже хорошо; потому что альтернатива — нудный ручной расчёт с картой и ручкой.
Но в 21-то веке почему-то люди ожидают от навигатора того, чтобы он не просто орал "вы ушли с маршрута", а предлагал варианты. Чтобы он учитывал изменение ситуации с пробками и предлагал альтернативы. Чтобы он хотя бы давал мне в каждый момент ответ "когда я приеду". Это почему-то кажется очевидным и понятным.
Но как только заходит речь о планировании коллективной работы, аналогичные ожидания внезапно вызывают оторопь. Да, я хочу, чтобы инструмент помогал мне в планировании проектных работ. Этап первоначальной подготовки проекта — самый короткий. В нём команда проводит минимум времени. Большая часть времени проходит во время выполнения проекта. И вопросы перепланирования встают многократно за время проекта. И про них почему-то ничего в "учебниках по MS Project" не пишут. А в жизни не бывает ни одного проекта, от которого к моменту окончания остаётся больше 50% первоначальных задач.
За годы знакомства у меня сложилось впечатление, что MS Project — он не для проектов, а для чего-то другого. ХЗ для чего. Потому что чего бы я от него ни хотел, он этого не умеет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там
H>Ну, вы всё верно поняли-то Конечно не "закодить всё, протестить H>всё", но очень coarse-grained. И после утверждения оставить только для H>ретроспективных целей.
В том-то и дело, что все, с кем я общался, имеют ровно такой же опыт. И только гапертон внезапно проник в тайну MSProject. Ну так может быть это мы все идиоты? А он знает какой-то рецепт?
Вопрос ведь не в том, знаю ли я, что там есть Resource Leveling. Вопрос в том, чтобы из проджекта извлекать пользу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: MS Project + JIRA - как не дублировать работу (одни и те же таски и там
Здравствуйте, Sinclair, Вы писали:
G>>Он предназначен для шедулинга и отслеживания ходя выполнения проекта. То есть, осмысленной деятельности с конкретной конечной целью, определенным уникальным финальным результатом, имеющей начало, и конец. А не для того, чтобы как-то спланировать процесс копания от забора до обеда. S>Ещё раз: размер приведён просто для сопоставления масштабов. В нормальном софтостроении не бывает релизов раз в неделю. Вот, скажем, у микрософта цикл длиной в три года; у нас — примерно в год.
Как много странностей в одном абзаце.
"Еще раз" подразумевает, что ты как бы повторяешься. Но это не так.
"для сопоставления масштабов" — я не понимаю, с чем предлагается сопоставлять, и с какой целью.
"В нормальном софтостроении" — не хотелось бы сводить разговор об MS Project к обсуждениям твоих или моих понятий нормы, они не имеют к теме никакого отношения. Как и длины релиз-циклов, которые ты считаешь нормальными.
S>Когда мы готовим релиз, у которого есть конечная цель, определённый уникальный финальный результат, начало, и конец, нам надо его спланировать. S>Основные вопросы, на которые должен отвечать тим лид, это "когда будет готово", "что именно будет готово", "почему изменились результаты", и "как скорректировать план в соответствии с новой ситуацией". S>Для этого и нужен инструмент. Инструмент для рисования гантт-чартов — не нужен. Гантт чарт шириной в 12 месяцев и высотой в 4000 задач абсолютно неинформативен.
Во-первых, и я могу добавить — "еще раз", потому, что до тебя это почему-то упорно не доходит, MS Project — это инструмент для ресурсного планирования, а не "рисовалка Гантт-чартов". В конце концов, предлагаю поверить мне на слово.
Во-вторых, если хоть кто-нибудь из моих тим-лидов или менеджеров проектов вот так всерьез решит, что инструментом для ответа на вопрос "как скорректировать план в соответствии с новой ситуацией" должен являться не его мозг, а какая нибудь (любая) тула — он будет уволен за профнепригодность.
Я абсолютно серьезно говорю. Ибо считаю саму постановку вопроса клинической. И, думаю, другие менеджеры со мной согласятся.
G>>Наличие целенаправленной (проектной) деятельности (то есть, первичности цели, которую надо достичь, а не двух тысяч мелких слабосвязанных друг с другом задач, и срока взятого от балды) здесь принципиально — только в этом случае тебе интересны разнообразные "критические пути" и прочее. S>Давайте разберёмся. Ведущие собаководы рекомендуют при оценках не делать задачи длиннее 4х часов. Иначе вы рискуете ошибиться в оценке на порядок.
Во-первых, ведущих собаководов чуть больше, чем одна штука, и те, которые советуют ограничить задачи 4-мя часами, в меньшинстве.
Во-вторых, для того, чтобы "не ошибиться на порядок", единиц планирования должно быть достаточное количество, и задача 4-х часовой длительности обеспечивает точность короткой, примерно недельной итерации/этапа/майлстона.
В третьих, ты элементарно не сможешь разбить на 4-часа-задачи работу длиннее месяца, так как для такой мелкой нарезки требуется очень хорошо представлять не только что, но и как ты будешь делать. А если сможешь — то с высокой вероятностью сгенерируешь бред, который потом придется выкинуть.
В четвертых, собаководам известна масса интересных способов поднять точность оценок, не прибегая к нарезке на микрозадачи.
В пятых, все перечисленное мной — это азбучные истины. Честно, я не обманываю. Поэтому, я пропущу твое утверждение про собаководов.
S>Я вам привёл пример на пальцах про копание канавы, который вы проигнорировали.
Честно говоря, я в разработке и управлении проектами куда лучше разбираюсь, чем в рытье канав. Ну ничего в канавах не смыслю. Прошу с пониманием отнестись.
S>Чтобы корректно получить длительность проекта, нам нужно одно из двух: S>а) сделать зависимость для прокладки трубы не finish-to-start, а start-to-start с задержкой в неделю (есть риск ошибиться, т.к. эта неделя взята более-менее с потолка) S>б) поделить задачи копания канавы и укладки трубы на мелкие поздадачи, в которых уже будут честные finish-to-start зависимости. S>Второй способ точнее, и он автоматически адаптируется к реальному прогрессу. Потому, что если в первом способе мы за первую неделю прокопали вдвое меньше, чем планировали, проджект по-прежнему будет оптимистично рапортовать, что укладку можно начинать.
а) Для грубого планирования "конвейерной" активности делают так. Ставится не только SS с задержкой, как у тебя, но и FF с задержкой. То есть, две связи, на каждой из них задержка. Никаких проблем на практике это не вызовет — не переживай, никто трубу укладывать без канавы не будет. При большом желании избежать описанной тобой логической трагедии, рытье траншеи бьется на две задачи, а не на две тысячи.
б) Требуемая длительность задач в плане определяется практически потребным интервалом контроля. А не математическим маразмом.
S>Отсюда мы и получаем порядка 2000 задач, из которых состоит проект для маленькой команды, занимающий примерно шесть месяцев.
2000 задач у вас получается не отсюда, а в силу каких-то совершенно иррациональных причин. К сожалению, логики в том, что вы говорите, не много, уважаемый Sinclair.
S>При этом для согласования проекта нужно оценить не 2000 задач, а примерно 6000, потому что две трети в итоге будут выкинуты в результате многочисленных болезненных обсуждений. Т.к. хотят все сразу всего, а ресурсов есть только для 30%. S>Что вы предлагаете с этим делать? Или это тоже "выходит за рамки использования MS Project"?
Да, представляете — это действие тоже выходит за рамки использования MS Project. Увольняться.
G>>И Project в этом совершенно не виноват. Этот факт, видишь-ли, не делает Project ни лучше, ни хуже. И, по идее, не должен мешать тебе понять, для каких ситуаций предназначен Project. S>Простите, а что мне поможет понять, для каких ситуаций он предназначен?
Боюсь ничего не поможет, дружище. Предлагаю бросить эту затею. Хотя нет — можно уволиться, это вполне может помочь.
