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

• Блог компании DEVPROM

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

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

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

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

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

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

Ресурсы

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

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

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

Сроки

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

Зависимости

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

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

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

Выводы

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

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

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

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

На первом рисунке представлена общая схема процессов управления содержанием проекта, которые включают в себя следующее:

• Сбор требований – процесс определения и документирования потребностей заинтересованных сторон проекта для достижения целей проекта. На успех проекта напрямую влияет тщательность сбора и управления требованиями к проекту и продукту. Требования включают в себя количественно определенные и задокументированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон проекта. Данные требования должны быть выявлены, проанализированы и зарегистрированы с достаточной степенью детализации так, чтобы их можно было измерить после начала исполнения проекта. Сбор требований представляет собой определение ожиданий заказчика и управление ими. Требования становятся базой для ИСР. Планирование стоимости, расписания и качества строится на основе этих требований. Разработка требований начинается с анализа информации, содержащейся в Уставе проекта и в Реестре заинтересованных сторон проекта.
• Определение содержания – процесс разработки подробного описания проекта и продукта. Подготовка подробного описания содержания проекта чрезвычайно важна для успеха проекта и основывается на основных результатах, допущениях и ограничениях, задокументированных во время инициации проекта. Содержание проекта определяется во время планирования и описывается более подробно по мере поступления информации о проекте. Существующие риски, допущения и ограничения анализируются на предмет полноты; дополнительные риски, допущения и ограничения добавляются по мере необходимости.
• Создание иерархической структуры работ (ИСР) – это процесс разделения результатов проекта и работ по проекту на более мелкие элементы, которыми легче управлять. Иерархическая структура работ – это ориентированная на результаты иерархическая декомпозиция работ, которые должна выполнить команда проекта для достижения целей проекта и создания требуемых результатов; на каждом более низком уровне ИСР представляет все более детальное описание работ по проекту. ИСР организует и определяет общее содержание проекта и представляет работы, указанные в текущем одобренном описании содержания проекта.
• Подтверждение содержания – процесс формализованной приемки завершенных результатов проекта. Подтверждение содержания включает в себя проверку результатов вместе с заказчиком или спонсором, чтобы убедиться, что они выполнены удовлетворительно, и формальную приемку результатов заказчиком или спонсором. Подтверждение содержания отличается от контроля качества в том, что подтверждение содержания в основном связано с приемкой результатов, а контроль качества в основном ориентирован на правильность результатов и соблюдение требований к качеству, заданных для результатов. Контроль качества, как правило, проводится до подтверждения содержания, однако эти два процесса могут выполняться и параллельно.
• Управление содержанием – процесс мониторинга статуса проекта и содержания продукта, а также управления изменениями базового плана по содержанию. Управление содержанием проекта обеспечивает обработку всех запрошенных изменений и рекомендованных корректирующих и предупреждающих действий в рамках процесса осуществления общего управления изменениями. Управление содержанием проекта используется также для управления фактическими изменениями по мере их появления; оно интегрировано в остальные процессы управления. Неуправляемые изменения часто называют «сдвигом содержания проекта». Изменения в любом случае неизбежны, и поэтому необходим процесс управления изменениями.

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

Краткий глоссарий

Проект (Project) - уникальный комплекс взаимосвязанных мероприятий для достижения заранее поставленных целей при определенных требованиях к срокам, бюджету и характеристикам ожидаемых результатов.

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

Проект – целенаправленная деятельность временного характера, предназначенная для создания уникального продукта или услуги [НТК].

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

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

План управления проектом (Project Management Plan) - основополагающий документ (baseline document), с которого должен начинаться любой проект. Содержит согласованное всеми участниками документально зафиксированное представление о проекте. В инвестиционных проектах – Мастер-план проекта (Project Master Plan) (УП).

Устав Проекта (Project Charter) - документ, разработанный вышестоящей администрацией, который предоставляет менеджеру проекта право использовать ресурсы организации для выполнения работ проекта .

Определение Проекта (Project Definition Report) - документ, определяющий проект, в том числе: каковы цели и результаты проекта; в чём его необходимость; что должно быть сделано; как, когда, и где это должно быть сделано; что для этого нужно; сколько это будет стоить; какие необходимо привлечь внешние ресурсы и организации; какие стандарты и процедуры подлежат соблюдению при осуществлении проекта [НТК].

Базис (Project Baseline) - Основополагающие параметры и фиксирующие их согласованное понимание всеми участниками документы проекта – «точка опоры» для всего последующего развития проекта.

Базовый план (Baseline) - Первоначальный план проекта с утвержденными изменениями. Базовый план бывает также и по составляющим проекта - стоимости, расписанию и т.д. [ОУП].

Предметная область (Scope) – совокупность продуктов и услуг, производство которых должно быть обеспечено в рамках осуществляемого проекта .

Цели (Scope) - совокупность продуктов и услуг, намеченных к производству в проекте [ОУП].

Ключевые вехи проекта (Project Milestones) - ключевые события проекта, свершение которых является необходимым и достаточным условием, определяющим достижение результатов проекта. Обычно представляются в виде схемы или таблицы с взаимосвязями и сроками свершения, образуя План по Вехам (Milestone Plan, Milestone Schedule, Master Schedule).

Контрольное событие - важное событие проекта, обычно связанное с достижением важнейших результатов [ОУП].

Другие варианты – ключевое событие [УП], контрольная точка [УП].

Структура декомпозиции работ (Work Breakdown Structure), СДР (WBS) - представление проекта, в виде иерархической структуры работ, полученной путем последовательной декомпозиции. СДР предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей.

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

Иерархическая структура работ - структуризация работ проекта, отражающая его основные результаты. Каждый следующий уровень иерархии отражает более детальное определение компонентов проекта [ОУП].

Структура разбиения работ – иерархическая структура последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня пакеты детальных работ [УП],

Проектные отклонения (Project Exceptions) - несовпадения фактических и плановых результатов проекта, причины таких несовпадений, методы и технологии, позволяющие справляться с такими ситуациями в проекте. Включают в себя риски, проблемы и изменения.

Отклонение (Deviation) – выход за пределы установленных требований. К отклонениям относятся случаи, когда результат работы не удовлетворяет требованиям или необоснованно их превышает.

Проектные риски (Project Risks) – Возможность возникновения непредвиденных ситуаций или рисковых событий в проекте, которые могут негативно или позитивно воздействовать на достижение целей проекта. Риск проекта характеризуется следующими факторами: источниками и характеристиками событий, которые могут оказать, вероятностями появления таких событий; возможным ущербом проекту и оценкой его влияния на проект.

Риск – потенциальная, численно измеримая возможность неблагоприятных ситуаций связанных с ними последствий в виде потерь, ущерба, убытков [УП].

Проектный риск в самом общем понимании – это опасность нежелательных отклонений от ожидаемых состояний в будущем, из расчета которых принимаются решения в настоящем [УПП].

Проблемы проекта (Project Problems) - любой функциональный, технический или связанный с бизнесом вопрос, который возник в процессе осуществления проекта и требует изучения и решения для того, чтобы проект мог идти так, как запланировано.

Проблемные ситуации (Problem situations) – возникающие при осуществлении проекта ситуации, для выхода из которых необходимо находить оптимальные решения [НТК].

Решение проблем (Problem Solving) – определение последовательных систематических процедур, с помощью которых анализируются и решаются проблемные ситуации [НТК].

Изменения проекта (Project Changes) - модификация ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, используемых ресурсов, управленческих и технологических процессов и т.п.

Изменения – Увеличение или уменьшение характеристик элементов проекта. Пересмотр базового плана проекта. Подразумевает документально оформленные и утвержденные изменения [УП].

Календарный план проекта (Project Schedule) - перечень планируемых работ проекта со сроками исполнения и ответственными лицами, подготовленный в соответствующей форме, определенной планом управления проектом.

Расписание проекта - плановые даты для выполнения работ и плановые даты для наступления контрольных (ключевых) событий («вех») проекта [НТК].

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

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

Суть проекта в терминах повышения потребительской ценности продуктов, бизнес функций, бизнес процессов и задач … Толковый словарь по информационному обществу и новой экономике

Scope Statement - Scope statements may take many forms depending on the type of project being implemented and the nature of the organization. The scope statement details the project deliverables and describes the major objectives. The objectives should include… … Wikipedia

Project planning - is part of project management, which relates to the use of schedules such as Gantt charts to plan and subsequently report progress within the project environment. }