Философия быстрого провала работает только при одном важном условии, которое, кажется, часто игнорируется, превращая всю идею в не более чем модную фразу.
Прежде чем я начну эту статью, я хочу отметить, что то, о чем я говорю, основано исключительно на моем собственном опыте и разговорах с другими разработчиками программного обеспечения, я не утверждаю, что знаю, как работают все компании-разработчики программного обеспечения.
Я предполагаю, что большинство инженеров-программистов хотя бы раз в своей карьере слышали фразу «частые и быстрые сбои», но для тех, кто этого не сделал, позвольте мне представить краткое описание.
В двух словах, быстро ошибаться и часто означает учиться на своих ошибках путем быстрого повторения, другими словами, это причудливый термин для «проб и ошибок».
Что означает фраза «Fail Fast»
Быстрая ошибка — это подход к поэтапному проектированию продукта, который обычно наблюдается в agile-средах. В истинно agile-средах очень хорошо работают быстрые отказы. Говоря «настоящие agile-среды», я имею в виду среды, в которых водопад не маскируется под agile, чтобы выглядеть более приемлемым (или как SCRUM, который там стал синонимом agile).
Однако в средах, которые только притворяются гибкими, это не очень хорошо подходит. Не потому, что философия обучения на своих неудачах плоха, а потому, что образ мышления в таких средах кажется сломанным до такой степени, что никто на самом деле не понимает, что означает «быстро и часто ошибаться». Если бы образ мышления не был сломлен, никто бы вообще не претендовал на agile, но в любом случае agile против водопада — не главная тема этой статьи.
В средах со сломанным мышлением по-настоящему быстрые неудачи невозможны, потому что недостаточно места для изменения планов после того, как неудача говорит о том, что все, что люди там делают, не работает, и нужно сделать что-то еще. Это потому, что долгосрочный план разработки продукта, скорее всего, уже есть, и никто не хочет его менять, поэтому нам остаются только крошечные технические и бизнес-решения, которые можно изменить в процессе разработки продукта.
