Дрейфусы, аджайлы и прочие страшные слова

Есть такой замечательный товарищ по имени Энди Хант. Известен он, прежде всего, авторством замечательной книги «Программист-прагматик. Путь от подмастерья к мастеру». Некоторые же знают его как одного из авторов Agile Manifesto, и автора интересной книги “Pragmatic Thinking and Learning: Refactor Your Wetware”.

В своей книге “Pragmatic Thinking and Learning” Энди Хант рассматривает много интересных моментов, связанных с работой нашего с вами серого вещества и уделяет немало внимания его работе в контексте разработки ПО. Так вот, есть один интересный момент, на который должны обратить внимание менеджеры и разработчики, в душах которых тлеет огонь надежды на успешное применение модного нынче понятия “agile development”.

И связан он с моделью Дрейфуса, которая, в свою очередь сильно напоминает известную с древности концепцию Сюхари.

Модель Дрейфуса и разработка ПО

В основы модели Дрейфуса лежат следующие понятия. Разных людей, в профессиональном плане, можно разделить на 5 категория – от новичка до эксперта. При этом каждая категория обладает определенными навыками и, что самое главное, разными подходами к решению проблем.

• Новичок (novice) или нуб. Для решения задачи требуется четкий набор шагов. Любые паттерны или принципы рассматриваются как набор шагов и прописных истин. Без четких шагов работа невозможна, а если попадается внештатная ситуация, то он/она впадает в ступор и паникует.
• Продолжающий (advanced beginner) или джун. Шаги и правила все еще нужны, но если в описании этих шагов будет пункт – отформатировать диск С, то есть все шансы, что столь явный ляп будет замечен.
• Комптентный (competent) или норм. На этом уровне появляется желание понять проблему, а не только решить задачу, не вникая в ее суть. Начинаются попытки использовать повторно чужой опыт и понять, что же лежит в основе принципов разработки. Но паттерны все еще понимаются довольно буквально, что может привести к Абстрактым Фасадным Фабричным Методам, завернутых в специализированный Синглтон.
• Специалист (Prificient) или профи. Здесь начинает рулить контекст и отношение к принципам, паттернам и другим «правилам» начинает меняться. Появляется желание понять общую картину мира/решаемой проблемы. На смену рецептам приходят фундаментальный принципы и появляется понимание того, когда им можно следовать, а когда на них можно и нужно забить.
• Эксперт (Expert) или гуру. Гуру (или Просветленный) уже не зажат рамками технологий, принципов или парадигм. Он решает проблему, причем может помочь в ее нахождении. Наличие правил убивает продуктивность гуру и делает из него печального котика.

Это описание не претендует на полноту или на точность. Но самое главное, нужно понимать тренд при движении от новичка к эксперту. Чем выше в пищевой цепочке находится специалист, тем меньше ему требуется точных указаний для решения задачи. Более того, профи и гуру будут категорически против, если им дать решать конкретную задачу и объяснить им КАК ее нужно решить: им достаточно лишь поставить задачу или, даже, описать проблему, с остальным они справятся сами.

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

UPDATE
Еще одна важная метаморфоза, которая происходит со специалистом, при движении по лестнице Дрейфуса, связана с отношением к проблемам. Новичок делает только то, что ему явно сказали, и все остальное – не является его проблемой. Для эксперта же, не существует такого понятия как «не моя проблема». Любая проблема проекта или заказчика – это его проблема.

Модель Дрейфуса и аджайл

Как связаны модель Дрейфуса и Аджайл, спросите вы? А вот как:

«Как вы, наверное, уже понимаете, некоторые новые направления в разработке ПО нацелены на специалистов и экспертов. Гибкая разработка основана на обратной связи; но возможность самокоррекции на основе предыдущего опыта осуществима лишь при наличии сотрудников с более высоким уровнем развития. Продолжающие и компетентные (advanced beginners и compenent) разработчики обычно путают паттерны проектирования с рецептами, что иногда приводит к губительным последствиям. … Гибкая разработка является очень эффективным инструментом, но оно не работает в командах, построенных исключительно из новичков и продолжающих.»
Энди Хант «Pragmatic Thinking and Learning: Refactor Your Wetware», pp. 36-39.

Другими словами, для того, чтобы «гибкая» команда была эффективной в ней должна быть критическая масса специалистов двух последних уровней. Конечно, это не гарантия результата, это лишь необходимые требования. Это значит, что нельзя забить на отбор сотрудников, набрать десяток человек средней компетенции, добавить к ним «продакт оунера», сказать, что «мы теперь работаем по скраму» и рассчитывать на положительный результат.

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

Нужно, чтобы кто-то умел собирать требования и их анализировать, ведь это нельзя отдать просто на откуп «продакт-оунера», как многие полагают.

Кто-то должен уметь дизайнить и архитектурить ПО. «Херак-херак и в продакш», несмотря на популярность, является не лучшим подходом. Важно, чтобы в команде были люди, знающие ключевые архитектурные паттерны и последствия их применения.

Нужен кто-то толковый в тестировании, в базах данных, в целевой платформе, все это важно, чтобы качество продукта было на достойном уровне. И тут явно недостаточно книги «Изучи что угодно за 21 день» или подхода «да ладно, у нас гибкая команда, все должны быть взаимозаменяемыми».

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