Несколько запоздало влезаю в дискуссию :-) Но уж очень интересна показалась тема.
Прошло уже 2 года с поста, скажите, были ли реализованы какие-то интересные решения по скрещиванию ганта со скрамом?
Я сейчас работаю над близкой тематикой, интересуюсь, кто что придумал.
В качестве комментария хочу добавить, что, на мой взгляд, неправильно относиться к диаграмме ганта как к чему-то статическому и неизменному. Это лишь способ показать на шкале времени информацию о фактически выполненных и запланированных задачах. В начале итерации это только планируемые задачи, в конце итерации — все должно быть выполнено. И это логично приводит нас к утвверждению, что да, действительно, диаграмма Ганта каждый день должна быть новой. В идеальном случае (когда все идет по плану) она отличается от исходной только процентами выполнения задач. Но в реальности все не так и я не вижу смысле так цепляться за неизменность диаграммы Ганта. Это же не какая-то священная корова, а всего лишь инструмент визуализации.
я уверен, что они неочевидны и даже после этого. Но это не говорит о том, что методология бесполезна.
Она полезна, поскольку несет в себе бесценный опыт людей, которые её придумали. Очень важно понимать ПОЧЕМУ и ЗАЧЕМ создана эта методология. Но это совершенно не означает, что она всем поможет и всех спасет.
Автор сделал очень верное наблюдение — методологии (управления, проектирования, разработки — можете продолжить список) не приносят ожидаемой от них пользы. Но при этом он делает совершенно неправильный вывод — что эти методологии не нужны. Да, бесспорно, люди важны. Опыт бесценен и незаменим. Но нельзя же строить опыт на пустом месте?
Все эти методологии — результат набитых шишек множества людей. Многим они реально помогли. Просто не надо забывать, что одни и те же слова разными людьми понимаются по разному. Да что там говорить — один и тот же человек в разные периоды своей жизни совершенно по разному относится к одним и тем же идеям.
От любой методологии есть реальная польза, когда она применяется в соответствии с допущениями, для которых была создана. И не всякая команда сможет сразу воспользоваться методологией, поскольку многие допущения могут лишь подразумеваться и их понимание приходит только с опытом, причем не всегда удачным.
Методологии необходимо изучать, чтобы понимать в чем их сильные и слабые стороны, какие вопросы они решают и за счет чего. Это нужно делать по тем же причинам, по каким программисту следует изучать новые языки программирования — это расширяет пространство понятий, которыми мы можем оперировать.
А вот кого стоит реально побить палкой — так это армию маркетологов, которые используют хорошие начинания вроде Agile для банального сбора денег. По факту на флаг выносится идея — «Вот мы вас щас научим и у вас наступит счастье». Грамотный маркетинг приводит к тому, что куча организаций под барабану несет свои деньги консультантам. И методологии становятся просто товаром. Очень многие покупают методологию, поскольку продавцы говорят, что успех прилагается бесплатно.
Люди — это очень важно. Хороший специалист должен быть образован. Он должен иметь большой опыт. Все обруганные в статье методологии — это чей-то опыт. Было бы глупо им разбрасываться. Поэтому я добавлю, что хороший специалист получает опыт не только за счет своих шишек, но и умеет воспользоваться чужим, как положительным, так и отрицательным.
А нужен именно Project? или аналогичная программа, которая помогает решать какие-то задачи?
Если верно второе, то мне было бы интересны Ваши ожидания от такой программы.
Вы то мне и нужны!
Я в последнее время работаю как раз в области управления проектами. И как раз сейчас стартую проект по разведыванию местности для создания планировщика проектов для разработчиков. Потому как у меня устойчивое ощущение, что его не хватает. Project, действительно, изрядно неудобен, а реальных альтернатив не видно :-( Вот хочется сделать в этом месте что-то хорошее, полезное и, по возможности, бесплатное. Мне очень не хватает аудитории, с которой можно было бы обсудить пожелания, потребности к подобной программе.
Можно будет через какое-то время обратиться с вопросами?
И такое случается. Не скажу, что часто, но бывает.
На мой взгляд, основная причина такого явления — недостаточное внимание постановке задачи. Утверждение, что это займет «неизвестно сколько времени» говорит, в первую очередь, о недостаточно проработанной постановке задачи — ровно то, о чем я писал в самом конце. Т.е. в постановке задачи осталось много недосказанностей. Недосказанность может возникать из-за того, что постановка недостаточно детальна (сочли, что все просто и так ясно), или из-за большого количества неизвестных величин (какие-то факторы, которые заранее неизвестны и их влияние непредсказуемо). Неучтенные факторы — это может быть и недостаточно налаженная инфраструктура, недостаточная квалификация разработчиков в новой для них области, ненадежная технология и т.п. Все это — риски. В промышленной разработке принято уделять внимание уменьшению влияния рисков. Для этого есть отдельный отдел, занимающийся инфраструктурой, новые технологии используются только после того, как кто-то набьет на них шишки и опишет их на stackoverflow и т.п.
С опытом приходит способность смотреть на задачи пытливым взором и отмечать те, в которых нас ждут грабли. На такие задачи обычно закладывают дополнительные буфера времени, «на всякий случай». На самом деле, их обычно не так уже много. Гораздо опаснее те задачи, где за внешне простой формулировкой кроется большая работа. Вот определять их гораздо сложнее. Последний раз я капитально влетел на пару месяцев с задачей, которая оценивалась в три недели :-)
У меня обычно вариант промежуточный. Есть некоторый базовый продукт и на его основе делаются прикладные решения под некоторые частные задачи. Начиналось все как раз с проекта по созданию этого продукта. Не сказать, что задачи совсем разноплановые, но и не скажешь, что под копирку.
В общем, несмотря на преимущества, я для себя решил избегать суммарных задач для декомпозиции.
Связано это с тем, что функциональная декомпозиция и зависимости для распределения по календарю — это вещи существенно разные. Поскольку суммарные задачи — единственное средство управления последовательностью выполнения для наборов задач, то я их использую для разделения на этапы. А для декомпозиции приходится использовать другие средства, хорошо, что они есть :)
Пока народу немного (в пределах 10 человек), хватает еженедельных совещаний :-)
Т.е. задачи в TFS у человека висят для справки, что-то срочное — можно и сразу сказать, а несрочное — терпит до совещания.
Про суммарные задачи.
Сложности возникают, когда реализация этого самого функционала размазывается на несколько этапов. Причем сначала кажется, что все ок, а потом одну задачку добавили, потому вторую — и привет. Когда анализируешь загрузку человека (группируя по исполнителям), видишь, что его первая задача начинается через полгода, а почему — не видно. Потому как суммарные задачи по умолчанию не попадают в просмотр по группировкам. А если их включить — такая каша образуется… В общем, я не рекомендую :-) Если очень хочется такие цепочки сделать то вместо суммарной — добавить milestone после всех задач данной функциональности и все остальное отстраивать от негою
Это вопрос сложный и даже в чем-то философский. Если начать издалека — то есть два подхода: проектный и процессный. Проектный — это когда вы должны за конечное время создать некоторый продукт. Процессный — это когда вы организуете процесс таким образом, чтобы двигаться к некоторой цели.
То что я описываю — это проектный подход. Релиз (продукт) образуется в конце проекта. Этап — это не обязательно релиз, это просто некоторый промежуточный результат. Обычно в конце этапа можно оценить как движется проект и скорректировать дальнейшие планы. Говорить о версии в начале и в конце тут сложно, потому как на старте может быть некоторый продукт, а в конце — этот же продукт, но «допиленный» под конкретного заказчика, его нужды.
В такой ситуации исправление ошибок — это либо известные работы, либо фоновые. Например, мы знаем, что в среднем 10% времени у нас уходит на исправление ошибок, и это надо учесть. Можем включить их в «прочие работы» или удлинить на 10% оценки по срокам для остальных задач. Для получения оценок — это неважно. Но если говорить об управлении проектом — то наука рекомендует такие запасы времени вкладывать именно в конечный буфер (прочие работы).
Другое дело, что вы в начале этапа можете заранее знать, какие ошибки есть и сколько времени у вас займет их исправление. Т.е. это уже не некоторая непредсказуемая фоновая деятельность — а конкретные задачи. Вот и оформлять их надо как задачи.
Redmine (как и куча других подобных систем — Jira, Trac, TFS и т.п.) ориентирован, в первую очередь, на процесс. Он позволяет организовать командную работу, показывает кому какие задачи назначены, что сделано, а что нет. С его помощью можно оценить что происходит прямо сейчас. Но он совершенно не помогает управлять проектом — т.е. он не помогает обнаружить узкие места проекта, оценить сроки и т.п.
На мой взгляд, это вообще большая дыра гибких методологий. Понятно, что управление проектом дело непростое, но Agile подход не предлагает решения этой проблемы, а делает вид что её нет. Мягко и незатейливо происходит подмена проектной деятельности процессной, а все остальное — чистый маркетинг, призванный убедить нас, что так и надо.
P.S. Это не значит, что я против гибких методологий разработки, просто всегда надо понимать за чей счет банкет.
Правильнее будет сказать — «управление планом». Да, управление планом — не распределенное. Это мой инструмент, как руководителя проекта. Я могу поделиться им с окружающими в ознакомительных целях, но всю работу с ним веду я один.
Элементы «распределенности» я как-то использовал — выгружал задачи в TFS и подтягивал оттуда статусы по мере их изменения. Но меня это не сильно понравилось. Связка TFS — Project работает как-то топорно и неудобно, они явно сделали её «для галочки», реально пользоваться этим невозможно. Более того, на одном из семинаров посвященному TFS докладчик явно сказал, что этим функционалом можно пользоваться только в одну сторону: из Project в TFS.
Так моделирование — это есть планирование. Модель проекта (читай — план) в MS Project позволяет руководителю видеть что происходит в проекте и что (теоретически) будет происходить.
MS Project — ужасно неудобный инструмент. Чтобы его успешно использовать — нужно быть чертовски аккуратным. НО! к сожалению, это единственный известный мне доступный инструмент с подобной функциональностью. Другие инструменты, которые более простые в использовании, не обладают аналогичной функциональностью. Собственно, про это автор также пишет.
Для себя я выработал ряд достаточно механистичных правил, которые позволяют получать от MS Project реальную пользу и по минимуму сталкиваться с его недостатками. Я планирую написать пост про это в ближайшее время.
Мне очень интересно, какое решение порекомендует автор в последующих постах, буду ждать.
Я считаю ошибкой думать, что MS Project должен что-то делать за нас. Это — просто инструмент. Он работает по определенным правилам. Если понимать и использовать эти правила, то есть возможность получать от этого инструмента немалую пользу, а именно — разгрузить мозг, составив модель проекта в виде плана в MS Project, внося изменения в модель понимать, как они скажутся на проекте в целом. MS Project окажется очень плохим инструментом, если целиком полагаться на его встроенную «автоматику» — она, действительно, не всегда очевидна. Также не всегда удобно пользоваться некоторыми очевидными возможностями, например, вложенные задачи — это просто кошмар! :-)
Прошло уже 2 года с поста, скажите, были ли реализованы какие-то интересные решения по скрещиванию ганта со скрамом?
Я сейчас работаю над близкой тематикой, интересуюсь, кто что придумал.
В качестве комментария хочу добавить, что, на мой взгляд, неправильно относиться к диаграмме ганта как к чему-то статическому и неизменному. Это лишь способ показать на шкале времени информацию о фактически выполненных и запланированных задачах. В начале итерации это только планируемые задачи, в конце итерации — все должно быть выполнено. И это логично приводит нас к утвверждению, что да, действительно, диаграмма Ганта каждый день должна быть новой. В идеальном случае (когда все идет по плану) она отличается от исходной только процентами выполнения задач. Но в реальности все не так и я не вижу смысле так цепляться за неизменность диаграммы Ганта. Это же не какая-то священная корова, а всего лишь инструмент визуализации.
Она полезна, поскольку несет в себе бесценный опыт людей, которые её придумали. Очень важно понимать ПОЧЕМУ и ЗАЧЕМ создана эта методология. Но это совершенно не означает, что она всем поможет и всех спасет.
Все эти методологии — результат набитых шишек множества людей. Многим они реально помогли. Просто не надо забывать, что одни и те же слова разными людьми понимаются по разному. Да что там говорить — один и тот же человек в разные периоды своей жизни совершенно по разному относится к одним и тем же идеям.
От любой методологии есть реальная польза, когда она применяется в соответствии с допущениями, для которых была создана. И не всякая команда сможет сразу воспользоваться методологией, поскольку многие допущения могут лишь подразумеваться и их понимание приходит только с опытом, причем не всегда удачным.
Методологии необходимо изучать, чтобы понимать в чем их сильные и слабые стороны, какие вопросы они решают и за счет чего. Это нужно делать по тем же причинам, по каким программисту следует изучать новые языки программирования — это расширяет пространство понятий, которыми мы можем оперировать.
А вот кого стоит реально побить палкой — так это армию маркетологов, которые используют хорошие начинания вроде Agile для банального сбора денег. По факту на флаг выносится идея — «Вот мы вас щас научим и у вас наступит счастье». Грамотный маркетинг приводит к тому, что куча организаций под барабану несет свои деньги консультантам. И методологии становятся просто товаром. Очень многие покупают методологию, поскольку продавцы говорят, что успех прилагается бесплатно.
Люди — это очень важно. Хороший специалист должен быть образован. Он должен иметь большой опыт. Все обруганные в статье методологии — это чей-то опыт. Было бы глупо им разбрасываться. Поэтому я добавлю, что хороший специалист получает опыт не только за счет своих шишек, но и умеет воспользоваться чужим, как положительным, так и отрицательным.
В двух словах, как это делается.
Если верно второе, то мне было бы интересны Ваши ожидания от такой программы.
Я в последнее время работаю как раз в области управления проектами. И как раз сейчас стартую проект по разведыванию местности для создания планировщика проектов для разработчиков. Потому как у меня устойчивое ощущение, что его не хватает. Project, действительно, изрядно неудобен, а реальных альтернатив не видно :-( Вот хочется сделать в этом месте что-то хорошее, полезное и, по возможности, бесплатное. Мне очень не хватает аудитории, с которой можно было бы обсудить пожелания, потребности к подобной программе.
Можно будет через какое-то время обратиться с вопросами?
На мой взгляд, основная причина такого явления — недостаточное внимание постановке задачи. Утверждение, что это займет «неизвестно сколько времени» говорит, в первую очередь, о недостаточно проработанной постановке задачи — ровно то, о чем я писал в самом конце. Т.е. в постановке задачи осталось много недосказанностей. Недосказанность может возникать из-за того, что постановка недостаточно детальна (сочли, что все просто и так ясно), или из-за большого количества неизвестных величин (какие-то факторы, которые заранее неизвестны и их влияние непредсказуемо). Неучтенные факторы — это может быть и недостаточно налаженная инфраструктура, недостаточная квалификация разработчиков в новой для них области, ненадежная технология и т.п. Все это — риски. В промышленной разработке принято уделять внимание уменьшению влияния рисков. Для этого есть отдельный отдел, занимающийся инфраструктурой, новые технологии используются только после того, как кто-то набьет на них шишки и опишет их на stackoverflow и т.п.
С опытом приходит способность смотреть на задачи пытливым взором и отмечать те, в которых нас ждут грабли. На такие задачи обычно закладывают дополнительные буфера времени, «на всякий случай». На самом деле, их обычно не так уже много. Гораздо опаснее те задачи, где за внешне простой формулировкой кроется большая работа. Вот определять их гораздо сложнее. Последний раз я капитально влетел на пару месяцев с задачей, которая оценивалась в три недели :-)
Связано это с тем, что функциональная декомпозиция и зависимости для распределения по календарю — это вещи существенно разные. Поскольку суммарные задачи — единственное средство управления последовательностью выполнения для наборов задач, то я их использую для разделения на этапы. А для декомпозиции приходится использовать другие средства, хорошо, что они есть :)
Т.е. задачи в TFS у человека висят для справки, что-то срочное — можно и сразу сказать, а несрочное — терпит до совещания.
Сложности возникают, когда реализация этого самого функционала размазывается на несколько этапов. Причем сначала кажется, что все ок, а потом одну задачку добавили, потому вторую — и привет. Когда анализируешь загрузку человека (группируя по исполнителям), видишь, что его первая задача начинается через полгода, а почему — не видно. Потому как суммарные задачи по умолчанию не попадают в просмотр по группировкам. А если их включить — такая каша образуется… В общем, я не рекомендую :-) Если очень хочется такие цепочки сделать то вместо суммарной — добавить milestone после всех задач данной функциональности и все остальное отстраивать от негою
Проектный — это когда вы должны за конечное время создать некоторый продукт. Процессный — это когда вы организуете процесс таким образом, чтобы двигаться к некоторой цели.
То что я описываю — это проектный подход. Релиз (продукт) образуется в конце проекта. Этап — это не обязательно релиз, это просто некоторый промежуточный результат. Обычно в конце этапа можно оценить как движется проект и скорректировать дальнейшие планы. Говорить о версии в начале и в конце тут сложно, потому как на старте может быть некоторый продукт, а в конце — этот же продукт, но «допиленный» под конкретного заказчика, его нужды.
В такой ситуации исправление ошибок — это либо известные работы, либо фоновые. Например, мы знаем, что в среднем 10% времени у нас уходит на исправление ошибок, и это надо учесть. Можем включить их в «прочие работы» или удлинить на 10% оценки по срокам для остальных задач. Для получения оценок — это неважно. Но если говорить об управлении проектом — то наука рекомендует такие запасы времени вкладывать именно в конечный буфер (прочие работы).
Другое дело, что вы в начале этапа можете заранее знать, какие ошибки есть и сколько времени у вас займет их исправление. Т.е. это уже не некоторая непредсказуемая фоновая деятельность — а конкретные задачи. Вот и оформлять их надо как задачи.
Redmine (как и куча других подобных систем — Jira, Trac, TFS и т.п.) ориентирован, в первую очередь, на процесс. Он позволяет организовать командную работу, показывает кому какие задачи назначены, что сделано, а что нет. С его помощью можно оценить что происходит прямо сейчас. Но он совершенно не помогает управлять проектом — т.е. он не помогает обнаружить узкие места проекта, оценить сроки и т.п.
На мой взгляд, это вообще большая дыра гибких методологий. Понятно, что управление проектом дело непростое, но Agile подход не предлагает решения этой проблемы, а делает вид что её нет. Мягко и незатейливо происходит подмена проектной деятельности процессной, а все остальное — чистый маркетинг, призванный убедить нас, что так и надо.
P.S. Это не значит, что я против гибких методологий разработки, просто всегда надо понимать за чей счет банкет.
Элементы «распределенности» я как-то использовал — выгружал задачи в TFS и подтягивал оттуда статусы по мере их изменения. Но меня это не сильно понравилось. Связка TFS — Project работает как-то топорно и неудобно, они явно сделали её «для галочки», реально пользоваться этим невозможно. Более того, на одном из семинаров посвященному TFS докладчик явно сказал, что этим функционалом можно пользоваться только в одну сторону: из Project в TFS.
habrahabr.ru/post/151593/
MS Project — ужасно неудобный инструмент. Чтобы его успешно использовать — нужно быть чертовски аккуратным. НО! к сожалению, это единственный известный мне доступный инструмент с подобной функциональностью. Другие инструменты, которые более простые в использовании, не обладают аналогичной функциональностью. Собственно, про это автор также пишет.
Для себя я выработал ряд достаточно механистичных правил, которые позволяют получать от MS Project реальную пользу и по минимуму сталкиваться с его недостатками. Я планирую написать пост про это в ближайшее время.
Мне очень интересно, какое решение порекомендует автор в последующих постах, буду ждать.