История изменений

Я говорю про типа готовый проект под внедрение

Ну ты как маленький... А они все такие. От операционных систем до чего угодно :) (Операционный системы, правда, по гибким технологиям не разрабатывались изначально - но люди, стоявшие у начала таких проектов, рано или поздно... уходят - и «ключевые посты» захватывают фанаты «гибкости» и «эффективности»(ТМ)). Иначе сервиспаки бы не клепали друг за другом и прочие обновления. Документацию не пишут - потому что требования меняются внезапно, а время на ее написание стоит денег (в идеальном мире - на оплату труда специально обученных людей «технических писателей»), поэтому все это порежут на этапе планирования люди с соответствующей властью. Хоть ты по скраму работай, хоть по канбану. Всегда может прийти большой начальник и сказать "Миша, все х*ня, давай сначала Чего вы тут херней маетесь - спринты-х*инты, срочно делайте вон ту х*ню, от которой вчера заказчик кончил радугой, когда мы пообещали". Они пообещали - а ты делай :) Пообещать могут что угодно - все эксцессы будут на исполнителях. Недавний пример: для шлюза одной биржи надо было, со слов манагера, «быстренько настроить готовый фреймворк» - программисты месяц помаялись с «готовым кодом», поняли, что где-то манагер «чего-то не договорил, исказил» - фреймворк по ТЗ должен был работать параллельно с N источниками данных. Он отлично работал с одним тестовым источником в песочнице заказчика. Но... был один нюанс «А на N источниках его никогда не тестировали» (с) - а источников у заказчика было... 80. Так что не рассказывай мне тут о тяжелой жизни админов :)

Я говорю про типа готовый проект под внедрение

Ну ты как маленький... А они все такие. От операционных систем до чего угодно :) (Операционный системы, правда, по гибким технологиям не разрабатывались изначально - но люди, стоявшие у начала таких проектов, рано или поздно... уходят - и «ключевые посты» захватывают фанаты «гибкости» и «эффективности»(ТМ)). Иначе сервиспаки бы не клепали друг за другом и прочие обновления. Документацию не пишут - потому что требования меняются внезапно, а время на ее написание стоит денег (в идеальном мире - на оплату труда специально обученных людей «технических писателей»), поэтому все это порежут на этапе планирования люди с соответсвующей властью. Хоть ты по скраму работай, хоть по канбану. Всегда может прийти большой начальник и сказать "Миша, все х*ня, давай сначала Чего вы тут херней маетесь - спринты-х*инты, срочно делайте вон ту х*ню, от которой вчера заказчик кончил радугой, когда мы пообещали". Они пообещали - а ты делай :) Пообещать могут что угодно - все эксцессы будут на исполнителях. Недавний пример: для шлюза одной биржи надо было, со слов манагера, «быстренько настроить готовый фреймворк» - программисты месяц помаялись с «готовым кодом», поняли, что где-то манагер «чего-то не договорил, исказил» - фреймворк по ТЗ должен был работать параллельно с N источниками данных. Он отлично работал с одним тестовым источником в песочнице заказчика. Но... был один нюанс «А на N источниках его никогда не тестировали» (с) - а источников у заказчика было... 80. Так что не рассказывай мне тут о тяжелой жизни админов :)