Agile методологии, как правило, предполагают итеративную разработку. Что это значит?
Это конечно не эджайлисты придумали. Термин существует еще с мохнатых 60-х годов (http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf).
Основная идея уже тогда была в том, что waterfall – это плохо, и нужно строить систему по чуть-чуть, итеративно, на каждой итерации проверяя, что строим правильного зверя. Валидировать. И учиться.
In 1975, Vic Basili and Joe Turner published a paper about iterative enhancement that clearly described classic IID:
“The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible. Key steps in the process were to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made along with adding new functional capabilities.”
Замечательно. Когда в обществе витает здоровое недоверие к секте agile – приятно осознавать, что бородатые инженеры NASA еще полвека назад думали примерно так же.
Идём дальше. Откуда итерации взялись в Agile? Видимо из вот этих принципов Agile Manifesto (http://agilemanifesto.org/principles.html):
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.“
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Важно отгружать продукт почаще, чтобы удовлетворить клиента. Другие пункты манифеста, на мой взгляд, прямо не влияют на решение делать разработку итеративной.
Из этого (и из здравого смысла) можно сделать вывод, что итерации полезно было бы совместить с релизами. Зачем нам итерация, в конце которой нет delivery? Такая итерация гораздо менее полезна для валидации функционала и для обучения, да и клиенту такая итерация совершенно неинтересна. Если релизить каждую итерацию – то итеративная разработка обретает смысл.
Дальше возникает вопрос, а как часто нужно релизить? И здесь, наверное, ответ нужно искать в разрезе денег.
С одной стороны, чем реже релизы, тем ниже затраты, как у разработчика, так и у клиента. С другой стороны, и разработчику, и клиенту могут быть выгодны частые релизы.
Сравним две ситуации (цифры приведены условные, сильно не смейтесь).
Ситуация A. Компания-разработчик делает 1 релиз за месяц, релиз сразу же внедряется у клиента.
Затраты на ручное тестирование релиза и на выпуск – 2000 долларов.
Затраты клиента на внедрение новой версии – 15000 долларов (сюда входит upgrade лицензии на продукт, работы по upgrade ПО, переобучение пользователей и админов и т.п.).
Ситуация B. Компания-разработчик делает 2 релиза за месяц, релизы сразу же внедряются у клиента.
Затраты на ручное тестирование релизов и на выпуск – 2 * 2000 = 4000 долларов.
Затраты клиента на внедрение – 2 * 15000 долларов (на самом деле меньше наверное, но для простоты модели пусть будет так).
По сравнению с ситуацией A, в этом случае клиент на две недели раньше получает очень нужный ему функционал, который позволяет ему снизить издержки одного из своих подразделений на 30000 долларов.
А разработчик имеет возможность на 2 недели раньше провалидировать этот функционал. Какова ценность этого факта, выраженная в долларах? Допустим, это позволит скорректировать планы на вторую половину месяца, выкинув половину работ, оказавшихся ненужными, а значит сэкономить на разработке 10000 долларов.
Слишком частые релизы – плохо (каждый релиз требует затрат как со стороны разработчика, так и со стороны клиента), и слишком редкие – тоже плохо (ваш замечательный софт призван позволить клиенту порезать затраты, и чем позже он его получит – тем меньше сэкономит; а ваши разработчики будут месяцами проедать бюджет, кодируя никому ненужные функции).
Нужно найти правильный баланс. И постепенно сдвигать его в правильную сторону, снижая затраты на выпуск. Ведь если выпуск будет бесплатным, то можно хоть трижды в день релизиться, и всем будет счастье 
–
Павел Сурменок