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

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

опубликовано
Апрель, 2021
категория
Разработка сайтов

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

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

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

Модели разработки проекта

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

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

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

✔ Дизайн

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agile методология

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

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

Некоторые преимущества Agile подхода:

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

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

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

✔ Разработка часто более ориентирована на пользователя.

И, конечно, есть некоторые недостатки:

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

✔ Лучше всего работает Agile, когда члены команды разработчиков полностью посвящены проекту.

✔ Так как Agile фокусируется на сроки доставки и частые переориентации, возможно, что некоторые элементы, установленные по дедлайну не будут завершены в отведенное время. Могут потребоваться дополнительные спринтеры (сверх первоначально запланированных), что приведет к увеличению стоимости проекта. Кроме того, вовлечение заказчика часто приводит к дополнительным функциям, запрашиваемым на протяжении всего проекта. Опять же, это может добавить к общему времени и затратам на реализацию.

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

Выбор между Agile и Waterfall?

Итак, как мы делаем выбор?

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

Создание сайтов в Алматы.

Похожие Статьи