Как работать с неизвестностью и неопределенностью в разработке

Автор оригинальной статьи действительно скуп на примеры, но я могу привести своё понимание методологии и ответить на ваши вопросы.

Представим ситуацию, что мы делаем веб приложение и у нас готов фронтенд, но мы оба не совсем понимаем как будет работать бэкенд. Если мы совсем не представляем как устроен бэкенд в принципе, то делаем анализ. Но мы с вами опытные разработчики и уже знаем как примерно работает и что умеет тот же ASP.NET и поэтому эту фазу пропускаем, не испытывая неопределенности "а решит ли бэкенд наши проблемы?".

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

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

А представьте что вместо спайка мы бы уже началиписать код с тестами да с контроллерами, потратили время и силы и выбросили бы это всё. Тут мы выбросим только бумагу.

Мы не пользовались файрбейсом и для нас это тоже неизвестность. Тут свой внутренний цикл анализ-спайк-трассер: мы смотрим что умеет сервис (анализ), пробуем написать простые облачные функции (спайк), а потом попробовать написать наши околопродакшен функции (трассер) чтобы убедиться, что файрбейс удовлетворяет нашим требованиям.

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

Работает? Кайф. Внедряем полноценно. Файрбейс выбросил утку? Возвращаемся к началу цикла и просматриваем другие варианты решения исходной проблемы.

TLDR

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

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