Я давно подозреваю, что Agile (в частности — малые размеры итераций) имеет математическое обоснование -- из теории вероятностей или теории игр. А также, что развитие роли системного аналитика и применение agile-методик являются двумя разными ответами на одну и ту же проблему — несоответствие функций и свойств поставленного ПО ожиданиям заказчика и пользователей.

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

Почему задача о разорении: доказано, что если игрок повышает ставку после каждого выигрыша, и не понижает её после проигрыша, то он неизбежно разорится. А также, если шансы хоть немного против игрока, а у его противника денег сильно больше (игрок против казино), то игрок с меньшим капиталом тоже рано или поздно разорится (для этого небольшого смещения на рулетке есть 0, а в некоторых ещё 00 и 000 — именно за их счет казино в конечном счете всегда выигрывает ).

Это всё очень напоминает ситуацию, когда небольшая компания по разработке ПО берет регулярные заказы у крупной компании (с бесконечным количеством денег). Ну или наоборот — небольшая компания обращается к системному интегратору с бесконечным количеством денег. Дальше понятно. Если меньшая компания и не разорится, всё равно может сильно пострадать — рано или поздно.

Что тут можно сделать:
1) увеличивать вероятность исхода "в свою пользу". В ИТ-проектах вероятность успешного результата проекта всё-таки не 50/50, а немного выше: 60/40. Тогда вероятность не разориться уже становится около 55%! А при попадании в цель 80/20 — вероятность уже больше 93%!!! Ого. Это путь аналитиков — стараться разобраться в проекте и повысить вероятность его успеха вдвое (кстати, нигде не видел исследований, насколько улучшение качества сбора и анализа требований повышает вероятность успеха проекта).

2) уменьшать размер ставки: не весь проект целиком, а порезанный на небольшие спринты. Уменьшение ставки в одной игре раз в 10 радикально увеличивает количество игр, за которое игрок с большим банком вас переиграет, то есть он просто не будет успевать, и шансы на успех приближаются к 98-99%. Неплохо, да? Это путь agile — вести разработку небольшими частями (снижать размер ставки).

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

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