Каждые двадцать лет люди заново переизобретают гибкие подходы Agile. Почему так? Попробуем разобраться в коренных причинах этого, путем фиилософских рассуждений об абстракциях.

Что такое программирование? Это попытка выстроить набор абстракций, превратив много мелких деталей в какой-то один объект, и так далее, по принципу матрешки, все сложить в одну большую абстракцию со свойствами и поведением. Это называют системой, подсистемой и т.п.

Но так ли уникальна эта работа? Не делают ли ее люди, далекие от программирования? Конечно делают!

Любой бизнес и любые его части, включая продажи, постоянно занимаются построением абстракций для клиентов, которые платят деньгами или еще чем-то за их материализацию. Если так посмотреть, то вся экономика — это и есть нагромождение абстракций, желаний и ожиданий разных людей.

Но в чем же разница? Разница в том, что именно абстрагируется. И если в программировании все заранее детерминировано, но при этом допускается огромное число комбинаций при построении абстракций, то в экономике все сложнее — элементами, входящими в абстрагируемые подсистемы и системы, являются устремления и мысли людей в конкретный момент времени, которые подвержены практически любым последующим изменениям, в отличии от детерминированной природы вычислительных устройств. Детерминизм обеспечивается только верой и убежденностью — исключительно гуманитарными категориями, как бы кто не верил в свою технарскую сущность.

Откуда появляется недопонимание между бизнесом и программистами, и почему срываются сроки проектов или почему бизнес программистов не всегда успешен?

Ответ кроется в фундаментальном правиле несовпадения абстракций.

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

Несовпадение абстракций на уровне систем и подсистем софта и железа приводит к ошибкам runtime.

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

Как видите, это почти всегда вопросы, относящиеся к конкретной ситуации с конкретными абстракциями.

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

Но жить как то надо, ведь постоянно пересматривать все абстракции — это очень энергозатратно для мозга.

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

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

Какой можно сделать вывод программисту?

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

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

Помни, что успех будет только тогда, когда разные абстракции дополняют друг друга, создавая эффект синергии.