Типичные заблуждения практиков гибких методологий

Но не только менеджерам приходится иметь дело с обилием конкурирующих моделей, аналогичная ситуация существует и в области разработки ПО. Эксперты по Agile без конца повторяют, что для того, чтобы правильно использовать Scrum или XP, «разработчики должны перепроектировать код». Кто-то утверждает, что «всем нужны юнит-тесты» или что «Scrum все ухудшает из-за того, что игнорирует инженерные практики» и что «ты не гибкий, если не используешь непрерывную интеграцию каждый день». Для этих экспертов Agile не про адаптацию и выполнение всего возможного для того, чтобы проект был долгое время успешным. Если верить этим Agile-экспертам, гибкость — это следование практикам X, Y и Z. Но это очередное заблуждение.

Гибкость — это способность оставаться успешным в постоянно меняющейся внешней среде.

Я

Вот и все, к этому нечего добавить.

С моей точки зрения, существует лишь одна универсальная практика, которая в равной степени подходит всем организациям, — гнать с порога любых «экспертов», которые осмеливаются утверждать, что практика X оптимальна для любой организации. Скорее всего, имеется в виду та практика, в которой данный эксперт особенно силен и которую он за хороший гонорар готов помочь вам внедрить. (Если вам интересно, мне никто не приплачивает за усилия, которые я прилагаю, выгоняя таких экспертов из нашего офиса.)

Некоторые практики гибких методологий предлагают вообще отказаться от бренда «гибкие» или «Agile-методологии». В конце концов, поскольку данный термин так и не получил ясного определения, гибкими иногда называют даже дисфункциональные проекты. Это возможно только потому, что гибкие методологии не предписывают выбор конкретных методов и инструментов. Но это естественно, поскольку универсальных практик просто не существует! Если бы они имелись, мы могли бы прописывать любой сложной системе одну и ту же стратегию выживания, а это напрямую противоречит природе сложности (и более конкретно — теории игр). В задачу гибких методологий никогда не входило рекомендовать определенный набор практик. В Agile-манифесте нигде не сказано, что вы должны непременно применять автоматизированное тестирование, парное программирование или рефакторинг. (Я был бы не в состоянии написать книгу по гибким методологиям, если бы какие-либо из практик были обязательными.) Как только люди начинают считать ту или иную практику обязательной, само словосочетание «гибкая практика» становится логически противоречивым.

Казалось бы, естественно ожидать, что эксперты по гибким методологиям должны понимать основы теории сложности. В конце концов, гибкие методологии выросли именно из нее. Но если бы они по-настоящему разбирались в теории сложности, то не давали бы глупых рекомендаций вроде «Если вы не пользуетесь практикой X, то вашу методологию нельзя признать гибкой» или «У вас не настоящий Scrum, поскольку вы не делаете Y». К сожалению, это до сих пор случается очень часто. Последователи спорят о преимуществах гибких методологий над бережливыми, превосходстве Экстремального программирования над Scrum, плюсах канбана по сравнению со Scrum и так далее и тому подобное. (На момент написания этой книги Scrum все еще считается нормой, поэтому если вы усматриваете в нем недостатки, то вполне сможете произвести впечатление на непосвященных.) Но ведь любая модель неполна, и найти в каждой недостатки достаточно легко — только пользы от этого немного.

В мире полно специалистов по гибким методологиям, выучивших слова эмерджентность и самоорганизация, которые в настоящий момент не использует только ленивый. Но они не до конца понимают, что означают эти термины в контексте гибких методологий и в практике разработки ПО. Не пора ли и мне выступить с программным документом?