Lesson 165

Слово Канеру

Водопад приносит качество в жертву времени

Модель водопада описывает жизненный цикл для управления проектами, проходящий через следующие фазы:

- Определение проблемы (что мы пытаемся создать и почему)
- Определение требований
- Внутренний и внешний дизайн
- Кодирование
- Тестирование
- Установка
- Поддержка
- Судебные иски от разочарованных клиентов
- Определение проблемы (для следующей версии продукта)

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

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

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

Водопад (с V или без) выглядит как аккуратный процесс, но что происходит в проектах, не успевающих предоставить все, что нужно для определенной фазы? Что делать, если проект отстает от графика?

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

Используя водопад в определенный момент времени вы получите продукт, все функции которого спроектированы и большинство из них закодированы. Большая часть денег на проект уже потрачена. Ключевой компромисс — между временем и качеством. Исправить ошибка и опоздать с поставкой или поставить продукт с ошибками.

Это классическая борьба между руководителями проекта и тестировщиками: предоставить забагованный или предоставить поздно. В ответ многие тестировщики требуют строгого соблюдения модели водопада. Это не решение проблемы. Водопаду присущ компромисс между временем и надежностью на поздней стадии разработки. Вам не вырваться из этой ловушки.
Подумайте, прежде чем выступать за модель разработки водопад (V-модель).

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