Удобны ли диаграммы Гантта в разработке ПО?

    Как известно, разработка программного обеспечения является длительным процессом, в котором в основном участвуют люди в разных частях этого процесса.

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

    По причине широкого распространения и относительно удобной визуализации описываемого процесса, эти диаграммы часто используются на стадии планирования при разработке программного обеспечения. Но так ли удобны и необходимы эти диаграммы в разработке ПО?


    Основная цель в построении диаграммы понять: сколько ресурсов потребуется, какие задачи необходимо выполнить, спрогнозировать срок, к которому будут выполнены эти задачи, и понять стоимость работ. Цель достигается путем определения перечня задач, требуемых ресурсов, определением зависимостями между задачами, выравниванием использования ресурсов для эффективного их использования, с учетом рисков.

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

    Я всегда завожусь, когда люди несведущие в разработке часто используют аналогию со строительством дома, для них не видно и части проблем, однако, они есть и существенные. Чем же так сильно отличается процесс разработки ПО от процесса строительства дома?

    Ресурсы

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

    Скоуп проекта

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

    Сроки

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

    Зависимости

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

    Итеративность

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

    Выводы

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

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

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

    Продожение
    DEVPROM
    Company
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 26

      0
      Каждый пункт достаточно спорный.
      Хотелось бы узнать о практиках, к которым вы перешли или собираетесь перейти
        0
        Если было бы не так, то этими диаграммами давно бы никто уже не пользовался. Какие пункты вы считаете спорными?
          0
          Имхо, все зависит от того как вы проектируете/планируете, адекватности заказчика, квалифицированности сотрудников и только в малой степени от средств планирования. Можно и лобзиком по фанерке лишь бы всем было понятно что делать сейчас и когда проект закончится.

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

          Скоуп проекта
          Как правило, диаграмма Гантта с более менее аргументированным разделением задачи и является весьма убедительным основанием для заказчика. Да требования могут меняться, но вам необходимо показать заказчику, что с изменением требований и сроки могут меняться и почему.

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

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

          Все это естественно ИМХО. Мне тоже многое не нравится в имеющихся средствах планированияи мне действительно интересно к какой альтернативе пришли Вы.

            0
            Статья написана исходя из потребности составить детальный план работ, понять кто чем будет заниматься, в каком порядке и каких сроков это потребует.

            Скоуп проекта.
            Диаграмма Гантта и WBS (work breakdown structure) несколько разные понятия. Да WBS нужен для понимания декомпозиции работ и предоставления этого заказчику, чтобы он понимал на что расходуются средства. Моих заказчиков редко волнует что некоторая задача стоит на критическом пути, поэтому изменение условий (требований, сроков, ресурсов и т.п.) влечет изменение самого плана. Его больше интересует как добиться результата исходя из его требований, так что диаграмму вам перерисовывать по-любому.

            Зависимости.
            Вы правы, есть инструменты, выполняющие автоматический resource leveling, так что зависимости между задачами на одном ресурсе можно и не ставить. Но это только маленькая часть проблемы: есть логические и технологические зависимости. Копали: Primavera, MS Project, ужас как вспомню…

            Итеративность.
            Все верно, можно и на календаре колбаски нарисовать и громко заявить: «мы сделаем это!», вот только внутренний страх не точит непоколебимую уверенность? :)
              0
              Вобщем, думаю, вы тоже в какой-то степени правы. И кажется вы уже нашли идеальное средство планирования :)
                0
                Наверно идеальным средством планирования является опыт :) но где же его взять, не загубив полсотни проектов…
        0
        Статья верная. Но по-моему закончилась на самом интересном — какие же практики лучше всего заменяют традиционное планирование в разработке ПО? Scrum? Есть ли еще какие альтернативы?
          0
          Я хотел заинтриговать публику, посмотреть насколько интересная тема. У меня есть ответ на Ваш вопрос, но интересно было бы сначала услышать мнение других участников.

          Альтернатив море, но каждая со своими особенностями. Вот если Вы считаете, что статья верная, то как выкручиваетесь?
            0
            Напишите про альтернативу. Будет интересно, т.к. сам сталкивался и до сих пор ничего более разумного чем подход Мила не нашел. :)
              0
              Вот если Вы считаете, что статья верная, то как выкручиваетесь?

              Честно говоря, не знаю. Scrum подходит для написания ПО, но все другие действия (вокруг) не вписываются (или не должны вписываться): проверка качества, написание документации, закупка доменов, настройка серверов, раскрутка, продажа, обучение пользователей и т.п. Но если тот же Scrum дает планируемые результаты в предскауемые сроки, то значит их можно и на Гантт-чарте расположить. Я уже сомневаюсь в своем выводе выше ;)
                0
                В разработке ПО основным мерилом являются трудозатраты, измеряемые в часах. Раскрутка, продажа и вообще маркетинг измеряются другими показателями, например, количеством холодных звонков, привлеченных клиентов, величиной какого-нить индекса цитируемости и т.п.

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

                Конечно, диаграмма Гантта позволяет описать то, для чего предназначена и Scrum тут не панацея, вопрос поднят относительно адекватности применения этой диаграммы для планирования разработки ПО.
                  0
                  ИМХО сравнивать вполне корректно.
                  Я считаю, что маркетинг в проекте нужно мерять не «количеством холодных звонков», а какими-то поставка проекта. Т.е. маркетинг в проект может поставить медиа-план. Ресурсы на разработку и исполнение медиа-плана вполне можно померять в человеках, деньгах и часах. Потому эти работы можно положить на диаграмму Гантта.

                  А «холодные звонки» будет мерять клиент и отзываться о Вас в хорошом или плохом смысле, в зависимости от количества «холодных звонков».

                  P.S. тема очень интересна и интересно к чему же Вы пришли. Ждем продолжения :)
          • UFO just landed and posted this here
              –3
              а зачем Вам диаграммы?
              • UFO just landed and posted this here
                  –6
                  А, вы никогда не использовали диаграммы Гантта? То есть не представляете себе их визуально что-ли?
                  • UFO just landed and posted this here
              0
              Скоуп — это сильно сказано.
                0
                лично для меня диаграмма Гантта сегодня актуальна как никогда:
                today преподаватель дал на практике задачу «Утро на даче». И решается она как раз таки диаграммой Гантта… Вечером, придя домой немного погуглил и нашел это.
                Лично у меня, на паре, все решение укладывалось за 108 минут… а преподаватель требовал 97-102… немного не укладывался в норматив… (:
                по ссылке найдете условия задачи — может кому то будет интересно себя тоже попробовать в составлении сией диаграммы… (:

                P.S.: прошу прощения за то, что мой комментарий не имеет ничего общего с разработкой ПО, но все же, надеюсь, пример задачи по диаграмме Гантта спасет меня от «заминусовки»… (:
                  +2
                  По моему опыту эти диаграмы, Project-ы и пр. делается только для того чтобы удволетворить заказчика или руководство, и только теми кто не хочет объяснить им, что все это мало имеет отношения к реалям современной разработки.
                    +1
                    Пробовал приспособить диаграмму Ганна к проекту. Не получилось. Диаграмма предполагает, что все этапы уже известны. Увы это не так.

                    Сделал этап по плану — вроде все ок. Теперь начальник говорит — надо сделать вот еще что. Или «а мы это делать не будем», или «сделаем по другому», то есть налицо итерация.

                    Неплохо работает список глобальных целей и туду лист по ним.
                      0
                      Диаграммы Ганта, по-моему, предназначены для удовлетворения низменных желаний неквалифицированного менеджера. Многие считают MS Project чуть ли не панацеей, пока не воспользуются им в программерском проекте… После чего уже не считают. На моей практике подобные диаграммы работают только на короткие сроки, а на длинных же получается слишком высокая погрешность. Но для примерной оценки времени они вполне годятся, не нужно только их ставить во главу угла.

                      П.С.
                      Аналогии со строительством тоже бесят.
                        0
                        В разработке основным… ресурсом является человек.… НО он не является в чистом виде ресурсом, потому что… человек крайне нелинейный элемент всей этой цепочки, а значит, вы не можете 100% рассчитывать на его заинтересованность, лояльность и доступность.


                        Автор оч. хорошо написал! Подправил карму )

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

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

                        Для меня пилюля следующая:
                        Опыт, полное понимание проекта, доверительные отношения и чувство возможностей каждого разработчика!
                          0
                          Добавлено продолжение: habrahabr.ru/company/devprom/blog/51569/
                            0
                            Я сейчас потихоньку курю ПЕРТ-диаграммы. На мой взгляд они являются логичным эволюционным развитием диаграмм Ганта. При этом они проигрывают в простоте восприятия и построения. Также для них достаточно мало автоматизированных средств, взамен предоставляя большую гибкость.

                            Касаемо всех сетевых моделей для оценки продолжительности проекта — не стоит забывать, что они дают только прогноз, исходя из текущего состояния дел по проекту. При этом исходя из общей производительности команды вполне будет разумно корректировать план, отодвигая сроки завершения, дабы уложиться в них :)
                              0
                              Сейчас я использую минимальную единицу длительности — 1 неделя. И кажется я снова полюбил диаграммы Ганта. Когда в ней были задачи длительностью час, поддерживать ее в актуальном состоянии было просто не реально.

                              А причиной тому стал переход на скрам с двух-недельной итерацией. Теперь мне нужно только понимать что в какой спринт войдет. А весь микроменеджмент уже внутри команды происходит.

                              Only users with full accounts can post comments. Log in, please.