Модели разработки проекта: какой принцип управления подойдет для вашего проекта

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

Две основные, наиболее популярные методологии:

Водопад (известен больше как Waterfall) , которую правильнее было бы назвать "традиционным" подходом, и Agile: специфический тип быстрой разработки приложений и более новый, чем Waterfall. Оба они являются полезными, продуманными методологиями. В данной статье мы поговорим о сильных и слабых сторонах каждого из них.

Методология Waterfall

Водопад - это линейный подход к разработке программного обеспечения. В этой методологии последовательность событий это нечто вроде:

✔ Требования к сбору и документированию

✔ Дизайн

✔ Проверка кода и модульный тест

✔ Выполнение тестирования системы

✔ Выполнение пользовательского приемочного тестирования (UAT)

✔ Внесение правок по любым проблемам

✔ Поставка готового продукта

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

Есть как хорошие, так и плохие моменты в подходе "Водопад". С положительной стороны:

✔ Разработчики и заказчики договариваются о том, что будет поставлено на ранней стадии жизненного цикла проекта. Это делает планирование и проектирование более простым.

✔ Прогресс легче измерить, так как полный объем работ известен заранее.

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

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

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

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

Вот некоторые проблемы, с которыми мы можем столкнуться при использовании подхода "водопада":

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

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