Agile методологии (aka «тяп-ляп и готово») уже давно стали де-факто стандартом разработки софта. В некогда солидной сфере IT, которая брала свои истоки от классической инженерии, где планировался и предугадывался каждый шаг, стала теперь по сути игрой без правил. Что заказчик хочет — то и творит.
Если еще пару десятилетий назад тотальное большинство программ разрабатывалось по надежной (но потому и более дорогой) каскадной методологии — Waterfall, то в начале двухтысячных разжирневшему на IT бизнесу потребовалась более гибкая методика клепания софта, которая бы заменила закостенелые «академические» методики и позволила бы быстрее перестраивать софт под сиюминутные хотелки заказчика. Так появилась целая плеяда методологий разработки, объединенных в одно коварное слово Agile.
SCRUM (он же скрам/срам) — это фреймворк, следующий принципам Agile, который и должен был описать и структурировать новый подход к разработке ПО. А именно:
Ключевым принципом Scrum является обоюдное признание того, что заказчик изменит свое мнение о том, что он хочет (часто это называется «волатильностью требований»), и что возникнут непредсказуемые проблемы, для которых не подходит прогнозирующий или запланированный подход (он же Waterfall — прим.ред.). Таким образом, Scrum применяет эмпирический подход, основанный на фактических данных, признавая, что задача не может быть полностью понята или определена заранее, и вместо этого сосредотачивается на том, как максимизировать способность команды быстро выполнять поставленные задачи, реагировать на возникающие требования и адаптироваться к развивающимся технологиям и изменениям рынка.
Если вас, прочитав эти слова, не стало тошнить радугой, то скорее всего вы:
1) Бесконечно далеки от разработки программного обеспечения
2) Вы — Agile-коуч (то бишь нахлебник, паразитирующий на бесчеловечных методологиях выжимания соков из работников)
3) Вы — программист-мазохист
Кто платит, тот и заказывает музыку
Для бизнеса Agile выгоден, иначе бы им не пользовались так широко. Заказчику намного дешевле поскорее сделать работающий прототип и сразу же его протестировать, чтоб на ходу внести изменения и снова тестировать, чем разрабатывать «от» и «до», неукоснительно придерживаясь плана, заморачиваться красотой кода и правильными архитектурными подходами, а также спокойствием команды. Иначе бизнес не выживет! В конкурентном капиталистическом мире бизнес-акул побеждает тот, кто быстрее может нащупать золотую жилу. Поэтому у заказчика нет выбора. Раз все стали играть в гибкие методологии разработки, то и тебе придется, голубчик, иначе ты быстро проиграешь. Звучит вроде бы логично. Но кто в этой истории крайний? Правильно — исполнители-золотоискатели, они же айтишники. Рядовые пешки — солдаты фронта нулей и единиц.
Формулировка SCRUM-определения «заказчик изменит мнение» — уже многое говорит о том, чего стоит вся эта возня с Agile’ом. Она стоит нервов и здоровья. Как юная девушка, которая всё время «меняет мнение» и тем самым нервирует парня, так и заказчик всё время «меняет мнение», нервируя всю команду — от тестировщиков и программистов до тимлида и продакт оунера. Это та плата, которую платят исполнители за то, чтоб бизнес получил максимальную прибыль.
Одна из целей SCRUM-подхода:
[…] максимизировать способность команды быстро выполнять поставленные задачи, реагировать на возникающие требования и адаптироваться к развивающимся технологиям и изменениям рынка.
Но мы-то с вами понимаем, что любая «максимизация» требует того, чтоб кто-то больше напрягался. Как и любая «адаптация». Все эти телодвижения требуют как минимум большего напряжения извилин и выжигания нервных клеток и сетчатки. Ведь если у тебя распланирована работа на полгода вперед — ты приходишь каждый день и знаешь что будешь делать и у тебя нет никаких неприятных неожиданностей, а значит и стрессов. Однако в современном мире разработки софта, даже двухнедельное планирование — утопия. В какой-то момент отцы-основатели «Скрама» это поняли, и потому даже заменили в своем Scrum Guide слово commitment на forecast. Мол, мы не беремся сделать все задачи, мы лишь прогнозируем, что выполним такой-то объем задач.
Однако легче от этого не стало. Вместо того, чтоб спокойно, с чашечкой кофе, запланировать на полгода вперед объем задач и постепенно выполнять его от фазы к фазе: от дизайна к разработке, от разработки к тестированию и так далее, у 99% айтишников Земли сплошной головняк. Никто не знает, что будет завтра на работе. Ни программист, ни тестировщик, ни тимлид, ни даже продакт-оунер. И все потому стрессуют. Либо же уходят «в отказ» (во внутреннюю эмиграцию с целью сохранить здоровье), то бишь перестают переживать за проект. И потому качество их работы страдает. Да и к чему рвать пятую точку, если ты никогда не выполнишь все задачи в срок (а если и выполнишь, то тестировщики не успеют их протестить)? Или если вы даже напишете весь функционал, а QA его протестят, то вам всё равно накинут задач. К чему тогда упахиваться? Ведь в любом случае вам будет уготовано вечное чувство неудовлетворенности, будто вы недорабатываете.
Работающим по SCRUM’у в принципе надо выписывать как летчикам — кефир или 100 грамм. От нервов. Может поэтому многие IT-компании поощряют алкоголь и устраивают «алко-пятницы» для своих сотрудников.
В самих «энциклопедических» Agile методиках по SCRUM’у давным давно было некое планирование со встроенной защитой от «дурака» (читай, переменчивого мечтателя-заказчика). Например, если Sprint (двухнедельная итерация, он же «забег») был запланирован на определенное количество задач и человекочасов, то изменять на ходу его ёмкость было нельзя. Однако очень быстро на это правило все стали плевать, объясняя это тем, что есть «бэклог» (набор задач), и раз в нем есть задачи, значит их можно докидывать в спринт. Или мол «а как это нельзя менять задачи по ходу пьесы, если вдруг команда прозрела, что разрабатывала что-то не то или использовала неподходящие технологии?». Хотя никто почему-то не вспоминает, что такая ситуация возникла в первую очередь из-за того, что на фазу планирования как таковую просто наплевали, ужав всё до минимальных сроков. Ведь это Agile, детка, тут надо всё успеть сделать на коленке. Иначе конкуренты сожрут.
Что бы предпочел программист, если бы ему предложили:
1) Минимум стресса, спокойный распланированный день без суеты, понимание всего объема задач на несколько месяцев вперёд и уверенность в выбранных технологиях.
2) Стресс, суета, планирование «для галочки» (по факту хаос), непонимание всего объема задач даже на ближайщие пару недель, отсутствие уверенности в выбранных технологиях и качестве продукта, вероятные овертаймы.
?
Ответ очевиден. Лишь самые забитые рабы-мазохисты, страдающие подобием стокгольмского синдрома, выбрали бы пункт #2.
Но дело в том, что в цепочке разработки софта страдают не только главные труженики — программисты. Но и практически все звенья вплоть до продакт оунера! Выберите любую SCRUM-команду, и вы не найдете там ни одного члена команды, который бы хоть раз за весь двухнедельный спринт не ходил бы по офису с выпученными глазами, цокающим языком или придурошным смешком.
Waterfall можно сравнить с социализмом. Такой подход более человечен, но менее прибылен.
Тогда как Agile — квинтэссенция капитализма в самом скверном смысле этого слова. «Рубить бабло любой ценой, здесь и сейчас» — вот о чем гибкие методологии разработки. Или, если быть точнее, — «практики прогибающихся». Поэтому и неудивительно, что проблема выгорания приобретает масштабы эпидемии в IT-компаниях мира, где применяется SCRUM. Человеческая психика не готова к ежедневному стрессу. Но капитализм сильнее социализма, поэтому будем работать по Аджайлу, то есть на износ, хлопцы и девчата. Добро пожаловать в блаженный мир IT, дамы и господа!
