Реактивный инкрементный метод работает так (продолжение):
Хотя есть версии и сборки, их не передают пользователю. Разработчики находят море причин хранить версии втайне, и (что более важно) версии, которые они выбирают, как правило, бесполезны для пользователей.
Всё это изменяется, когда проект не укладывается в сроки. В этот момент руководство объявляет, что вместо поставки целиком в установленный срок, будет происходить поэтапная сдача. Результат первого этапа будет передан новым владельцам к первоначально запланированной дате сдачи, но полная система не будет закончена до четвёртой, девятой или какой-то ещё даты, спустя месяцы, а то и годы. Такое заявление направлено на то, что задержку будет легче пережить, если проект способен представить хотя бы что-то в первоначальный срок сдачи. Но что именно представляет собой это что-то?
Поскольку неоспоримое опоздание имеет обыкновение проявляться довольно поздно по отношению к первоначальному графику, то ясно, что выбор компонентов для первичной поставки также происходит поздно. В этот момент вопрос "Что включим в поставку на первой фазе?" выглядит несколько фальшивым, поскольку единственно возможен ответ: "При том, как близка дата поставки, первая фаза включит всё, что будет к этому моменту готово".
Такой реактивный подход не имеет ни одного из тех преимуществ, на которые претендует инкрементный метод.