понедельник, 2 ноября 2015 г.

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

Есть такой замечательный товарищ по имени Энди Хант. Известен он, прежде всего, авторством замечательной книги «Программист-прагматик. Путь от подмастерья к мастеру». Некоторые же знают его как одного из авторов 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 день» или подхода «да ладно, у нас гибкая команда, все должны быть взаимозаменяемыми».

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

10 комментариев:

  1. В скраме две проблемы.
    - скраму нужна команда профессионалов, а команде профессионалов скрам не очень нужен.
    - скрам справляется хорошо с тривиальными предсказуемыми задачами, а там профессионалы не нужны, нужна дисциплина.
    Поэтому из скрама выкидывается 90% хлама, и тогда Окей.

    ОтветитьУдалить
    Ответы
    1. Полностью согласен.

      А вообще, меня очень веселит, когда где-то звучит "настоящий скрам" или "а у нас все вообще по скраму".

      "Строгое следование гибким методологиям" - это же как "теща - девственница":))

      Удалить
  2. Аааа, понял про тещу. Есть очень хорошая фраза - "Процесс для команды, а не команда для процесса". Сколько крови попили с желанием оценивать таски в часах. Говорю, не надо. Нет, у нас так по процессу... В общем, да, на больную мозольку тут наступил, ага...

    ОтветитьУдалить
    Ответы
    1. Да, фраза - просто класс! Как-то странно, что очень немногие это понимают:))

      Удалить
    2. Боюсь, вы смотрите на скрам только с позиции девелопера. Конечно оценка в часах вам не нужна и даже мешает. Но с позиции ПО этот показатель важен

      Удалить
    3. А что-то в скраме изменилось и там появилась оценка в часах? Мне всегда казалось, что там оценка дается в попугаях (стори поинтах) для оценки велосити, чтобы построить бёрн-даун чарты и постоянно уточнять "сходимость" спринтов...

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

      Удалить
    4. Скажу больше. Моего прожекта совсем не интересует сколько часов было потрачено и на что. Интересует, чтобы спринт выполнялся без переносов. И чтобы PBI были привязаны к фичам и оценены в попугаях. Собственно, все... И оцениваем мы задачи с прожектом и сервис - менеджером в попугаях. Часов там нет - нигде вообще.

      Удалить
  3. Сергей, напишите пожалуйста пост, что вы думаете, насколько эффективно поступает Microsoft конкурируя с linux и др. средами в сфере удобства и экономичности создания онлайн-приложений и сервисов, можно ли будет на C# легко и дешево писать онлайн-утилиты.

    ОтветитьУдалить
    Ответы
    1. Мне кажется - что вопрос цены это пара: цена разработки, цена развертывания.
      Микрософт не дешевый вариант в развертывании, и выбирая его надо быть готовым что вы привязываетесь к среде. Система разработки, операционная система, базы данных, и прочее - вся инфраструктура.
      И да, микрософт делает потрясающие тулзы из коробки, но шаг в право-влево и огромные трудности, приходится либо "слишком много знать" либо иметь штат знатоков.
      Вы должны быть готовы, что мс в лбой момент может "забить" на то, что обширно используется в вашем проекте - это конец поддержки в новых тулсетах как минимум и отсуствие патчей как максимум. (и у вас не будет шанса скачать исходники и пофиксить своими силами).
      В остальном порог вхождения для онлайн сервисов в мс невысокий. Красивая платформа (я про дотнет). Лучшая среда разработки. В простом случае - простой менеджмент. Азур на котором задеплоить что-то простое может даже ребенок.

      Удалить
    2. @csblogru я вряд ли могу дать полноценный ответ на этот вопрос, поскольку не особенно сильно смотрю на другие платформы и не обладаю огромным опытом создания онлайн-приложений и сервисов на C#. Тут и правда слишком много моментов, которые нужно учитывать, включая опыт команды, кратковременная стоимость, важность быстрого выхода на рынок и т.п...

      Удалить