|
 С проектами разработки ПО обычно обращаются за помощью одного из двух методов – водопадного или гибкого. Оба имеют плюсы и минусы, и каждый подход имеет свою ценность. В данной статье рассматриваются оба метода, и анализируется, какой метод и при каких обстоятельствах лучше всего подходит для проектов разработки ПО.
Водопадный метод
Водопадный метод существует с 1970-х годов и остается общеупотребительным. Он говорит о необходимости следовать определенному набору шагов на протяжении жизненного цикла вашего проекта. Речь идет о следующих шагах:
- Анализ требований
- Планирование
- Реализация
- Тестирование
- Установка
- Поддержка
Он называется водопадным методом, потому что каждая стадия вытекает из предыдущей, когда предыдущая завершается, стекая вниз словно водопад. Как водопад, стадии текут вниз, а не вверх. Данный метод часто считается более надежным.
Водопадный метод подходит для коммерческих сделок, в которых договоры подписаны и деньги заплачены. Но при работе на внутренних клиентов труднее трезво относиться к вносимым в последний момент изменениям, когда о нем просят люди из вашей собственной организации, имеющие поддержку руководства.
|
Плюсы
|
Минусы
|
|
Подробная документация.
|
Медленный запуск.
|
|
Согласованные и утвержденные требования.
|
Трудноизменяемые жесткие требования.
|
|
Выпускаются менее квалифицированными разработчиками.
|
Клиент не видит программное обеспечение до завершения разработки.
|
|
Сниженное число дефектов благодаря тщательному планированию структуры.
|
Малая гибкость затрудняет изменение направления.
|
|
Заданная начальная и конечная точка для каждой фазы, что позволяет легко измерять прогресс.
|
Клиенты вначале не имеют ясного представления о своих требованиях.
|
Гибкий метод
Гибкий метод является итерационным подходом к проектам, в котором требования и решения изменяются на протяжении сотрудничества клиентов и групп разработчиков. Термин был придуман в 2001 году, когда был составлен «гибкий манифест».
Если ваш руководитель беспокоится, что вы наделаете ошибок перед клиентами, данный метод вам не подойдет. Гибкий метод означает, что вы создаете предоставляемые результаты заранее и улучшаете их на протяжении нескольких шагов вместе с клиентом. Однако некоторые заинтересованные лица могут смотреть на это отрицательно.
В ходе недавнего проекта по созданию главной страницы с видео для сайта клиента первый шаг был близок к примеру, предоставленному конструкторской фирмой. Тестирование этого шага выявило несколько требующих внимания элементов, устранение которых требовало небольших усилий.
Руководитель счел это невыполнением требований клиента и позором для группы. Я считал, что 90 процентов требований было реализовано верно, а оставшиеся 10 были бы исправлены за несколько дней. Этот первый шаг позволил полностью понять требования клиента, а клиенту дал возможность четко высказать свои требования.
После получения выговора я однозначно понял мнение руководителей. Мне запрещалось повторять подобное вновь, и вся дальнейшая работа должна иметь полностью согласованную и утвержденную спецификацию перед написанием первой строки кода.
Что интересно, клиент был доволен гибким подходом, так как он позволил клиенту наблюдать за выполнением работы и комментировать ее в процессе разработки.
Приводит ли гибкий метод к более быстрой сдаче проекта? Это спорно. Начав программировать рано, вы не обязательно закончите скорее. Но гибкий метод гарантирует соответствие конечного результата нуждам клиентов, потому они дают полезную информацию в течение всей фазы разработки.
|
Плюсы
|
Минусы
|
|
Быстрый запуск, пошаговый выпуск и регулярная критика и отзывы от клиента.
|
Может быть неверно расценен как отсутствие плана или расхлябанность.
|
|
Изменение требований со временем.
|
Требует высококвалифицированной, ориентированной на клиента группы разработчиков.
|
|
Способность быстро реагировать на изменения.
|
Требует высокого уровня вовлеченности клиента.
|
|
Меньше доработок благодаря непрерывному тестированию и вовлеченности клиента.
|
Отсутствие долгосрочных подробных планов.
|
|
Связь в реальном времени между группой разработчиков и клиентом.
|
Производит меньше документации.
|
Заключение
Так какой метод лучше – водопадный или гибкий? Ни один из двух...
Какой метод применять, зависит от следующих нескольких факторов:
- Характер работы: есть ли четко определенный результат? Разработка веб-сайтов является творческим делом и поэтому подходит для гибкого метода. Разработка транзакционной системы, где есть четко определенный результат, больше подходит для водопадного метода.
- Тип клиента: согласен ли он работать итеративно, есть ли у него время на проверку и комментирование регулярных итераций?
- Мнение вашего руководителя: какой метод он больше предпочитает, насколько легко он адаптируется?
- Представление об ИТ в организации: воспринимается ли ИТ как ценный партнер или неизбежное зло? В последнем случае используйте водопадный метод.
- Внутренний или внешний клиент: является ли ваш клиент внутренним или внешним? Водопадный метод подходит для внешних клиентов, от которых можно потребовать соблюдения подписанного договора, в отличие от внутренних клиентов, способных вынудить вас внести изменения, получив поддержку руководства.
Руководитель проекта должен выбрать метод, лучше всего отвечающий нуждам клиентов. Проблема возникает при наличии разногласий. В таких случаях выбирайте метод, дающий лучший результат, и усмиряйте всех, кто не согласен.
В конечном счете оба метода могут реализовать ваш проект. Речь идет об управлении ожиданиями вашего клиента и производстве качественного продукта. Как только вы достигаете конца пути, никого не волнует, как вы добились успеха.
Newer news items:
Older news items:
|
