Типичные заблуждения практиков гибких методологий
Но не только менеджерам приходится иметь дело с обилием конкурирующих моделей, аналогичная ситуация существует и в области разработки ПО. Эксперты по Agile без конца повторяют, что для того, чтобы правильно использовать Scrum или XP, «разработчики должны перепроектировать код». Кто-то утверждает, что «всем нужны юнит-тесты» или что «Scrum все ухудшает из-за того, что игнорирует инженерные практики» и что «ты не гибкий, если не используешь непрерывную интеграцию каждый день». Для этих экспертов Agile не про адаптацию и выполнение всего возможного для того, чтобы проект был долгое время успешным. Если верить этим Agile-экспертам, гибкость – это следование практикам X, Y и Z. Но это очередное заблуждение.
Гибкость – это способность оставаться успешным в постоянно меняющейся внешней среде.
Я
Вот и все, к этому нечего добавить.
С моей точки зрения, существует лишь одна универсальная практика, которая в равной степени подходит всем организациям, – гнать с порога любых «экспертов», которые осмеливаются утверждать, что практика X оптимальна для любой организации. Скорее всего, имеется в виду та практика, в которой данный эксперт особенно силен и которую он за хороший гонорар готов помочь вам внедрить. (Если вам интересно, мне никто не приплачивает за усилия, которые я прилагаю, выгоняя таких экспертов из нашего офиса.)
Некоторые практики гибких методологий предлагают вообще отказаться от бренда «гибкие» или «Agile-методологии». В конце концов, поскольку данный термин так и не получил ясного определения, гибкими иногда называют даже дисфункциональные проекты. Это возможно только потому, что гибкие методологии не предписывают выбор конкретных методов и инструментов. Но это естественно, поскольку универсальных практик просто не существует! Если бы они имелись, мы могли бы прописывать любой сложной системе одну и ту же стратегию выживания, а это напрямую противоречит природе сложности (и более конкретно – теории игр). В задачу гибких методологий никогда не входило рекомендовать определенный набор практик. В Agile-манифесте нигде не сказано, что вы должны непременно применять автоматизированное тестирование, парное программирование или рефакторинг. (Я был бы не в состоянии написать книгу по гибким методологиям, если бы какие-либо из практик были обязательными.) Как только люди начинают считать ту или иную практику обязательной, само словосочетание «гибкая практика» становится логически противоречивым.
Казалось бы, естественно ожидать, что эксперты по гибким методологиям должны понимать основы теории сложности. В конце концов, гибкие методологии выросли именно из нее. Но если бы они по-настоящему разбирались в теории сложности, то не давали бы глупых рекомендаций вроде «Если вы не пользуетесь практикой X, то вашу методологию нельзя признать гибкой» или «У вас не настоящий Scrum, поскольку вы не делаете Y». К сожалению, это до сих пор случается очень часто. Последователи спорят о преимуществах гибких методологий над бережливыми, превосходстве Экстремального программирования над Scrum, плюсах канбана по сравнению со Scrum и так далее и тому подобное. (На момент написания этой книги Scrum все еще считается нормой, поэтому если вы усматриваете в нем недостатки, то вполне сможете произвести впечатление на непосвященных.) Но ведь любая модель неполна, и найти в каждой недостатки достаточно легко – только пользы от этого немного.
В мире полно специалистов по гибким методологиям, выучивших слова эмерджентность и самоорганизация, которые в настоящий момент не использует только ленивый. Но они не до конца понимают, что означают эти термины в контексте гибких методологий и в практике разработки ПО. Не пора ли и мне выступить с программным документом?
Инструкция по управлению сложностью
Мне кажется, нам всем пора признать, что, предпочитая простые решения, мы игнорируем сложность окружающего нас мира. Поэтому я предлагаю следующий набор рекомендаций…
У каждой проблемы есть много решений
Кубик Рубика можно собрать несколькими способами. Не существует единственного верного способа управлять бизнесом. Не существует единой оптимальной стратегии, позволяющей всегда выигрывать в настольной игре «Риск». И нет единого оптимального метода управления проектами. По-человечески понятно, что нам бы хотелось, чтобы только предлагаемые нами решения оказывались эффективными. Но следует все же допускать, что и решения, предложенные другими, могут также быть эффективными.
Выбор решения зависит от контекста
Форма биологического вида зависит от окружающей его среды. При выборе оптимальной стратегии необходимо учитывать характеристики данной команды и ее противников. Выбор маркетинговых решений зависит от того, с какими клиентами вы имеете дело. А выбор наиболее эффективных практик зависит от внешней среды, в которой реализуется конкретный проект. При разработке ПО многие факторы важны, но главным из них будет именно контекст.
Изменяющиеся контексты диктуют изменяющиеся решения
Когда изменяется среда обитания, изменяются и населяющие ее биологические виды. Лучшие стратегии продвижения аккаунта в социальных сетях в этом году отличаются от прошлогодних. (Подпишитесь на меня в Twitter, и мы вместе понаблюдаем, какие стратегии будут применяться в следующем году.) Стоит измениться контексту, как приходится изменять и способы управления соответствующими проектами.
Любое странное решение где-то будет лучшим
Антарктический криль – самый успешный вид на планете. Стратегия «око за око» – одна из доминирующих стратегий выживания в теории игр. Но даже рыбе-капле с ее специфической внешностью удалось найти свою нишу в этом мире. Ни одна стратегия в теории игр не будет универсальной. Как бы ни были популярны некоторые методологии разработки ПО, они не заменят другие методы, подходящие именно в нестандартных ситуациях – а такие ситуации будут всегда.
Выбранное решение в свою очередь влияет на контекст
Некоторые новые фильмы оказывают трансформирующее воздействие на всю киноиндустрию, и всем выходящим впоследствии фильмам волей-неволей приходится учитывать новые веяния. Оказавшиеся у нас в головах мемы изменяют наш образ мыслей и облегчают усвоение связанных с ними новых мемов. Аналогичным образом выбранные нами практики разработки ПО изменяют среду, в которой мы функционируем, и влияют на нашу способность применять другие практики.
Простота требует понимания сложности
Биологи, компании и правительства успели причинить много вреда, в свое время не разобравшись в сложности окружающего мира. Тем, кто не понимает, как устроен мир, трудно спрогнозировать, какие именно простые решения могут оказаться эффективными при решении сложных проблем.
Невозможно заранее предсказать, какое решение окажется лучшим
Прогнозирование, безусловно, это ценный инструмент, но тем не менее невозможно точно знать заранее, какие из предлагающихся решений сработают, а какие нет. Только располагая эмпирическими данными о реальной ситуации, мы можем делать заявления об ожидаемом успехе того или иного решения. Но надо научиться признавать, что часто мы просто не в состоянии вынести об этом какое-либо суждение и сначала предстоит испробовать различные методы, прежде чем выяснится, какой из них оказался эффективным в конкретной ситуации.
