Сначала сделай работающий простой вариант, потом усложняй.

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

Не стоит кодить так, чтобы часть приложения оставлась сломанной продолжительное время. В идеале приложение всегда должен быть рабочим, а новые участки кода должны «подключаться» по мере готовности.

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

Такой подход максимально приемлем для бизнеса.

Когда ты покажешь продакту что-то базово работающее, вполне возможно, он скажет: давай выкатим этот простой работающий вариант, так как он позволит уже сегодня решить часть проблем, а на следующие неделе — всё остальное. И иногда может оказаться, что всё остальное вообще не понадобится.

Любая работоспособная сложная система является итогом эволюции более простой работоспособной системы… Сложная система, разработанная «с нуля», никогда не работает так как надо, и никакие «заплатки» не заставят ее работать правильно. Проектирование следует начинать с простой работоспособной системы.

— Gall John. 1986. Systemantics: How Systems Work and Especially How They Fail. 2nd edition. Ann Arbor, MI: The General Systemantics Press, p. 65.

Литература

• Буч Г. и др. Объектно-ориентированный анализ и проектирование с примерами приложений. 3-е изд., М., Вильямс, 2008.