Постигая агиле
Читаю книжку “Постигая Agile”. В названии поста нет опечатки. Я на полном серьезе называю это сборище методологий именно этим словом. Иронизирую и выражаю свою оценку.
Книга феерическая. Огромное количество воды, голословные утверждения, одни и те же лозунги по кругу, демагогия и высмеивание тех, кто не хочет привыкать к Новой Управленческой Религии. Никак не могу взять в толк, почему эту книгу порекомендовал Гради Буч.
Но продолжаю читать.
Добрался до главы про Scrum, от которой становится особенно тошно.
В главе приводится старая басня, с помощью которой все имеющие отношение к проекту люди делятся на две категории:
Свинья и курица идут по дороге. Курица говорит свинье: «Давай откроем ресторан!» Свинья отвечает: «Хм, можно. А как мы его назовем?» Курица отвечает: «Почему бы не назвать его “Яичница с беконом”?» Свинья, немного подумав, говорит: «Нет, спасибо, ведь тогда мне придется посвятить себя проекту полностью, а ты будешь вовлечена лишь частично»
Именно уровень вовлеченности (и отождествление себя с командой и своих целей с целями команды) и обсуждается дальше. Если провал проекта - не провал лично твой,и если твой успех возможен без успеха проекта - ты “курица”. Если же между этими понятиями есть равенство - ты “свинья”. Все шло относительно неплохо (по крайней мере, в этой главе мысли были сформулированы хоть сколько-то логично) до следующей фразы:
Но есть одно обстоятельство, предусмотренное правилами Scrum: выполнение задач спринта важнее всех прочих профессиональных целей, которые у вас есть. Иными словами, пока ты в scrum-команде – оставайся «свиньей»
Скрам по описанию создателя, да и по этим самым правилам, подходит для проектов. Активностей, у которых есть ограниченный фронт работ, который выполняется относительно недолго (скажем, до года). Для таких проектов еще приемлемо (хоть и с натяжкой) попросить сотрудников на какое-то время отказаться от личных и профессиональных целей и амбиций в пользу очень важного проекта для компании.
Но часто скрам применяется в совершенно другой среде - в разработке продуктов. Разработка продукта отличается от разработки проекта тем, что ведется до тех пор, пока “спонсору” не надоест придумывать потребности и платить. Как правило, платить спонсор (чаще всего, крупный бизнес) может годами, так что такая разработка отлично подходит под определение Continuous Development. А просить от людей отказываться от своих целей и потребностей в проектах, длящихся годами, уже подло. Это требование жертвы. И в жертву должно быть принесено то, что компания не сможет да и не захочет компенсировать. Время, молодость, энергия, потенциал. Все ради целей спринта - часто сиюминутных, порожденных близорукостью и страхом.
Отсюда же растет тотальное пренебрежение качеством, игнорирование рефакторинга и бесконечные попытки записать те же самые тесты в техдолг, который никогда не будет погашаться. Что в условиях того самого Continuous Development почти всегда приводит к тому, от чего этот агиле так старался уйти: разобщенность, низкопробный софт, разочарование, превышение бюджета и недовольство пользователей.
Разумеется, я описываю случай, когда никто не должен работать по скраму. Вот только одно “но”. Из книги это не следует - там это “one-fits-all” универсальное решение. И в это верит индустрия. Никто не анализирует границы применимости. Все применяют.
Читать эту книгу дальше всё тяжелее.
















