Солдатов в Телеграм

От Waterfall до Snowball

Несмотря на то, что книжки про гибкую разработку уже давно стали классикой, а agile всеми интерпретируется как "абсолютное добро", вот и у Сбера есть целый Agile центр (правда, закрылся, видимо, они agile уже повсеместно внедрили и необходимость в Центре пропала) и пишут они о нем много теплых слов, на реальном производстве нередко встречается классический waterfall, ровно такой, как мне преподавали в институте, аж в 1996 году, иногда, для осовременивания, этот waterfall снабжают итерациями (спринтами), видимо, это и есть основное достижение гибкой разработки.

В 1996 году в институте я проходил жизненный цикл информационной системы: она разрабатывается (по waterfall-у), внедряется, эксплуатируется и выводится из эксплуатации (или что-то вроде того). Однако, за все свои 25 лет работы, ровно такого цикла я никогда не видел, а было примерно так: разработка - внедрение - эксплуатация с постоянной доработкой - .... (видимо, я уже поколение CI/CD). И это нормально, ибо ничто не стоит на месте и нам постоянно нужно дорабатывать используемую систему, чтобы она лучше отражала постоянно изменяющуюся действительность (да и закон диалектики утверждает, что совершенству нет предела). А вот для "постоянной доработки" waterfall совсем не пригоден, как минимум, потому, что за время пути собака точно подрастет. Но детали еще хуже!

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

Чем больше функционала, и чем он сложнее, тем больше дефектов! А исправление дефекта тоже может что-то поломать, поэтому после исправления бага объяснимо желание проведения полного регрессионного тестирования. Бесконечно сложный функционал и так имеет бесконечно долгий регресс, но надо не забыть добавить к этому бесконечное количество багов! Хорошо, что математика тут за нас - умножая бесконечность на бесконечность, мы получаем все ту же бесконечность, а не супер-бесконечность или мета-бесконечность, однако, легче от этого не становится, а ситуация нарастает как снежный ком.

#dev #пятница

Telegram

Солдатов в Телеграм

Гибкая разработка

- единственный подход, чтобы сделать решение быстро, качественно, максимально попасть в ожидания заказчиков. Но я так думал не всегда, поскольку в институте, в конце 90-х, я проходил Водопад в качестве правильного, системного, подхода…

www.tg-me.com/jp/Солдатов в Телеграм/com.soldatov_in_telegram/640

919 viewsApr 18 at 08:11

От Waterfall до Snowball

Несмотря на то, что книжки про гибкую разработку уже давно стали классикой, а agile всеми интерпретируется как "абсолютное добро", вот и у Сбера есть целый Agile центр (правда, закрылся, видимо, они agile уже повсеместно внедрили и необходимость в Центре пропала) и пишут они о нем много теплых слов, на реальном производстве нередко встречается классический waterfall, ровно такой, как мне преподавали в институте, аж в 1996 году, иногда, для осовременивания, этот waterfall снабжают итерациями (спринтами), видимо, это и есть основное достижение гибкой разработки.

В 1996 году в институте я проходил жизненный цикл информационной системы: она разрабатывается (по waterfall-у), внедряется, эксплуатируется и выводится из эксплуатации (или что-то вроде того). Однако, за все свои 25 лет работы, ровно такого цикла я никогда не видел, а было примерно так: разработка - внедрение - эксплуатация с постоянной доработкой - .... (видимо, я уже поколение CI/CD). И это нормально, ибо ничто не стоит на месте и нам постоянно нужно дорабатывать используемую систему, чтобы она лучше отражала постоянно изменяющуюся действительность (да и закон диалектики утверждает, что совершенству нет предела). А вот для "постоянной доработки" waterfall совсем не пригоден, как минимум, потому, что за время пути собака точно подрастет. Но детали еще хуже!

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

Чем больше функционала, и чем он сложнее, тем больше дефектов! А исправление дефекта тоже может что-то поломать, поэтому после исправления бага объяснимо желание проведения полного регрессионного тестирования. Бесконечно сложный функционал и так имеет бесконечно долгий регресс, но надо не забыть добавить к этому бесконечное количество багов! Хорошо, что математика тут за нас - умножая бесконечность на бесконечность, мы получаем все ту же бесконечность, а не супер-бесконечность или мета-бесконечность, однако, легче от этого не становится, а ситуация нарастает как снежный ком.

#dev #пятница

BY Солдатов в Телеграм