Между спринтом и водопадом
Раньше в разговорах о программировании часто приводили аналогию со строительством дома. Нельзя сказать, что программисты разбирались в строительстве, но идея понятна: если дома стоят по 100 лет, то давайте и программы будем писать так, чтобы они потом долго эксплуатировались и требовали только косметического ремонта. Опыт показал, что это не работает. Нельзя собрать волю в кулак, всё предусмотреть и сделать решение на годы вперёд. Более того, если дать программисту задачу на год, то он напишет много кода, но неизбежно оторвётся от реальных требований.
Не удивительно, что на смену долгим процессам повсеместно пришёл agile с небольшими задачами и короткими циклами разработки. В принципе, agile работает, но он подразумевает, что есть Product Owner, от которого идёт поток хорошо поставленных задач. К сожалению, в природе часто встречаются менеджеры, которые не умеют писать. Двигать задачи из одного спринта в другой - умеют, а сформулировать, что они хотят - не могут. А когда никто ничего не записывает, то получаются совещания и перерывы между совещаниями, а работающий код - не получается.
Но даже если agile работает нормально, то для проекта, который живёт уже 10 лет (обычно и 5 лет более чем достаточно) технологии, которые использовались в начале, безнадёжно устаревают и нужно вносить радикальные изменения. Добавьте сюда проекты, которые сравнительно молоды, но в которых успели напринимать очень странных решений, которые теперь надо переделывать. И не будем забывать про проекты, которым уже больше 10 лет и в которые все эти годы забивали костыли.
Неизбежно, что от программистов требуется иногда вносить большие изменения, которые не укладываются в один спринт. Конечно, нужно разбивать всю работу на обозримые задачи, но при этом обязательно видеть всю картину в целом и постепенно идти к поставленной цели. Если собрались исправить какой-то костыль, но по факту починили только половину, то через год это будут две половинки разных костылей и не разберешь уже где старый, где новый.
К сожалению, часто компании упорно продолжают закапываться в протоптанную колею и им не хватает сил изменить свою судьбу.
Не удивительно, что на смену долгим процессам повсеместно пришёл agile с небольшими задачами и короткими циклами разработки. В принципе, agile работает, но он подразумевает, что есть Product Owner, от которого идёт поток хорошо поставленных задач. К сожалению, в природе часто встречаются менеджеры, которые не умеют писать. Двигать задачи из одного спринта в другой - умеют, а сформулировать, что они хотят - не могут. А когда никто ничего не записывает, то получаются совещания и перерывы между совещаниями, а работающий код - не получается.
Но даже если agile работает нормально, то для проекта, который живёт уже 10 лет (обычно и 5 лет более чем достаточно) технологии, которые использовались в начале, безнадёжно устаревают и нужно вносить радикальные изменения. Добавьте сюда проекты, которые сравнительно молоды, но в которых успели напринимать очень странных решений, которые теперь надо переделывать. И не будем забывать про проекты, которым уже больше 10 лет и в которые все эти годы забивали костыли.
Неизбежно, что от программистов требуется иногда вносить большие изменения, которые не укладываются в один спринт. Конечно, нужно разбивать всю работу на обозримые задачи, но при этом обязательно видеть всю картину в целом и постепенно идти к поставленной цели. Если собрались исправить какой-то костыль, но по факту починили только половину, то через год это будут две половинки разных костылей и не разберешь уже где старый, где новый.
К сожалению, часто компании упорно продолжают закапываться в протоптанную колею и им не хватает сил изменить свою судьбу.