Как известно, разработка программного обеспечения является длительным процессом, в котором в основном участвуют люди в разных частях этого процесса.
Люди уже давно научились планировать и описывать процессы при помощи практик календарно-сетевого планирования, ярким представителем которых является диаграмма Гантта. Разработано и обкатано множество программных инструментов, легко доступных любому желающему.
По причине широкого распространения и относительно удобной визуализации описываемого процесса, эти диаграммы часто используются на стадии планирования при разработке программного обеспечения. Но так ли удобны и необходимы эти диаграммы в разработке ПО?
Основная цель в построении диаграммы понять: сколько ресурсов потребуется, какие задачи необходимо выполнить, спрогнозировать срок, к которому будут выполнены эти задачи, и понять стоимость работ. Цель достигается путем определения перечня задач, требуемых ресурсов, определением зависимостями между задачами, выравниванием использования ресурсов для эффективного их использования, с учетом рисков.
Воспользуемся классической аналогией разработки ПО — строительство дома. В данном контексте она наиболее уместна. Чтобы построить дом, затратить при этом минимум средств и уложиться в требуемые сроки необходимо понять: сколько ресурсов нам потребуется (кирпич, цемент, бетон, рабочие и т.д.), когда они потребуются, в какой последовательности выполнять работы, а также выдержать технологические нормы на выполнение хорошо известного и довольно прозрачного процесса строительства дома. Использование диаграммы Гантта в данном случае органично вписывается в решение данной задачи.
Я всегда завожусь, когда люди несведущие в разработке часто используют аналогию со строительством дома, для них не видно и части проблем, однако, они есть и существенные. Чем же так сильно отличается процесс разработки ПО от процесса строительства дома?
Ресурсы
В разработке основным и практически единственным ресурсом является человек, отчего он часто обижается на цинизм, заложенный в сути календарного планирования: человек не ресурс, он хочет, чтобы его любили и уважали. На составление плана и поддержание его в актуальном состоянии приходится тратить массу времени, которое можно было бы пустить на достижение конечной цели. Конкретный разработчик, тестировщик или аналитик не является в чистом виде ресурсом, потому что конкретного исполнителя трудно и дорого заменить, ведь только он хорошо знает некоторую часть системы, обладает специфическим опытом и навыками. Человек крайне нелинейный элемент всей этой цепочки, а значит, вы не можете 100% рассчитывать на его заинтересованность, лояльность и доступность.
Скоуп проекта
Перечень задач, которые необходимо выполнить разработчику, далеко не так очевиден даже при хорошем понимании сути будущего продукта. Можно использовать автоматические тесты, а можно не использовать, можно пропустить некоторые этапы на фазе анализа, тестирования или документирования, а на некоторых участках наоборот потребуется уделить чему-то больше внимания. Сверхвысокая сложность всех тонкостей процесса позволяет охватить перечень задач лишь поверхностно, многие из них вылезут на более поздних стадиях проекта. Наконец длительность процесса противоречит скорости, с которой изменяются требования заказчика или пользователей к продукту.
Сроки
Процесс разработки куда более гибкая вещь, что позволяет заказчику свободнее манипулировать скоупом проекта, привлекаемыми ресурсами, стоимостью работ. То, что бетонная стяжка должна сохнуть 3 дня и никак не меньше заказчику понятно, но то, что подсистема разграничения прав доступа пишется месяц, находит понимание куда сложнее. Любое изменение в нашем треугольнике влечет за собой существенную переработку плана, что отнимает массу времени и требует наличия выделенного человека, например, менеджера проекта.
Зависимости
Понять и осознать весь тот клубок из задач, которые предстоит выполнить при реализации относительно сложной системы практически не возможно, а, следовательно, и определить зависимости между задачами. Составить эффективный план и минимизировать стоимость практически не представляется возможным, поскольку любое изменение в процессе влечет за собой повторное перепланирование использования ресурсов.
Итеративность
Подавляющее большинство проектов используют итерационную модель процесса, однако линейный календарный график совершенно не учитывает данную специфику. Жизненный цикл продукта состоит из нескольких этапов (релизов), в каждом из которых есть повторяющиеся части. Жизненный цикл реализуемой функции состоит из хорошо известных фаз анализа, проектирования, разработки, тестирования и т.п. У любой функции такой жизненный цикл. На диаграмме Гантта вам приходится для каждой функции расписывать задачи для конкретной фазы, а это крайне утомительное занятие, но если этого не делать, то ваш план никуда не годится.
Выводы
Диаграмму Гантта хорошо применять для описания детерминированных и почти статических процессов, в которых используется подавляющее большинство линейных ресурсов, технологические циклы которых хорошо известны и отработаны.
Я для себя решил, что нет никакого смысла тратить время на составление и поддержание этих диаграмм, это время и силы лучше потратить на коммуникацию между участниками, реальную помощь проекту и повышение лояльности участников.
Однако, это не означает, что скоуп, сроки, стоимость и ресурсы не нужно учитывать и планировать, нужно, но только используя другие практики.
Продожение
Люди уже давно научились планировать и описывать процессы при помощи практик календарно-сетевого планирования, ярким представителем которых является диаграмма Гантта. Разработано и обкатано множество программных инструментов, легко доступных любому желающему.
По причине широкого распространения и относительно удобной визуализации описываемого процесса, эти диаграммы часто используются на стадии планирования при разработке программного обеспечения. Но так ли удобны и необходимы эти диаграммы в разработке ПО?
Основная цель в построении диаграммы понять: сколько ресурсов потребуется, какие задачи необходимо выполнить, спрогнозировать срок, к которому будут выполнены эти задачи, и понять стоимость работ. Цель достигается путем определения перечня задач, требуемых ресурсов, определением зависимостями между задачами, выравниванием использования ресурсов для эффективного их использования, с учетом рисков.
Воспользуемся классической аналогией разработки ПО — строительство дома. В данном контексте она наиболее уместна. Чтобы построить дом, затратить при этом минимум средств и уложиться в требуемые сроки необходимо понять: сколько ресурсов нам потребуется (кирпич, цемент, бетон, рабочие и т.д.), когда они потребуются, в какой последовательности выполнять работы, а также выдержать технологические нормы на выполнение хорошо известного и довольно прозрачного процесса строительства дома. Использование диаграммы Гантта в данном случае органично вписывается в решение данной задачи.
Я всегда завожусь, когда люди несведущие в разработке часто используют аналогию со строительством дома, для них не видно и части проблем, однако, они есть и существенные. Чем же так сильно отличается процесс разработки ПО от процесса строительства дома?
Ресурсы
В разработке основным и практически единственным ресурсом является человек, отчего он часто обижается на цинизм, заложенный в сути календарного планирования: человек не ресурс, он хочет, чтобы его любили и уважали. На составление плана и поддержание его в актуальном состоянии приходится тратить массу времени, которое можно было бы пустить на достижение конечной цели. Конкретный разработчик, тестировщик или аналитик не является в чистом виде ресурсом, потому что конкретного исполнителя трудно и дорого заменить, ведь только он хорошо знает некоторую часть системы, обладает специфическим опытом и навыками. Человек крайне нелинейный элемент всей этой цепочки, а значит, вы не можете 100% рассчитывать на его заинтересованность, лояльность и доступность.
Скоуп проекта
Перечень задач, которые необходимо выполнить разработчику, далеко не так очевиден даже при хорошем понимании сути будущего продукта. Можно использовать автоматические тесты, а можно не использовать, можно пропустить некоторые этапы на фазе анализа, тестирования или документирования, а на некоторых участках наоборот потребуется уделить чему-то больше внимания. Сверхвысокая сложность всех тонкостей процесса позволяет охватить перечень задач лишь поверхностно, многие из них вылезут на более поздних стадиях проекта. Наконец длительность процесса противоречит скорости, с которой изменяются требования заказчика или пользователей к продукту.
Сроки
Процесс разработки куда более гибкая вещь, что позволяет заказчику свободнее манипулировать скоупом проекта, привлекаемыми ресурсами, стоимостью работ. То, что бетонная стяжка должна сохнуть 3 дня и никак не меньше заказчику понятно, но то, что подсистема разграничения прав доступа пишется месяц, находит понимание куда сложнее. Любое изменение в нашем треугольнике влечет за собой существенную переработку плана, что отнимает массу времени и требует наличия выделенного человека, например, менеджера проекта.
Зависимости
Понять и осознать весь тот клубок из задач, которые предстоит выполнить при реализации относительно сложной системы практически не возможно, а, следовательно, и определить зависимости между задачами. Составить эффективный план и минимизировать стоимость практически не представляется возможным, поскольку любое изменение в процессе влечет за собой повторное перепланирование использования ресурсов.
Итеративность
Подавляющее большинство проектов используют итерационную модель процесса, однако линейный календарный график совершенно не учитывает данную специфику. Жизненный цикл продукта состоит из нескольких этапов (релизов), в каждом из которых есть повторяющиеся части. Жизненный цикл реализуемой функции состоит из хорошо известных фаз анализа, проектирования, разработки, тестирования и т.п. У любой функции такой жизненный цикл. На диаграмме Гантта вам приходится для каждой функции расписывать задачи для конкретной фазы, а это крайне утомительное занятие, но если этого не делать, то ваш план никуда не годится.
Выводы
Диаграмму Гантта хорошо применять для описания детерминированных и почти статических процессов, в которых используется подавляющее большинство линейных ресурсов, технологические циклы которых хорошо известны и отработаны.
Я для себя решил, что нет никакого смысла тратить время на составление и поддержание этих диаграмм, это время и силы лучше потратить на коммуникацию между участниками, реальную помощь проекту и повышение лояльности участников.
Однако, это не означает, что скоуп, сроки, стоимость и ресурсы не нужно учитывать и планировать, нужно, но только используя другие практики.
Продожение
