ИЗ АРХИВА ЖУРНАЛА PRAGPUB ИЮНЬ 2011 ГОДА
Медитация гуру: пройти Agile Advanced Beginner
Энди Хант
Кривые обучения, как правило, неравномерно круты, или мы бы назвали их наклонами обучения. Энди занимается одним из самых крутых сегментов кривой обучения Agile.
Снова и снова люди говорят мне, что они’ застряли. Они встали на путь, чтобы стать agile-практиками, но, несмотря на самые лучшие намерения, они, кажется, не могут прорваться, чтобы функционировать как настоящая, самоуправляемая, самокорректирующая agile-машина.
Вместо этого они застревают. Застрял после опубликованных "рекомендаций", которые кто-то придумал для журнальной статьи. Застряли в соответствии с планом, который им передали, из-за крайнего срока, оговоренного юристами, с которыми онини разу не встречались и не разговаривали.
Команда практикует некоторые гибкие методы, но онине гибкие. Предоставленные сами себе, ничто не изменит этого. Они'достигли стадии Advanced Beginner, и им' нужно проявить некоторую осторожность и внимание, чтобы пройти ее и стать компетентным практиком. .
Чтобы понять это, давайте’ рассмотрим модель приобретения навыков Дрейфуса.
Модель Дрейфуса
Модель Дрейфуса — это полезный способ взглянуть на то, как люди приобретают и совершенствуют свои навыки. Он определяет пять уровней, которые вы испытываете, приобретая способности в определенных навыках (дополнительную информацию см. в разделе Прагматическое мышление и обучение).
Вот уровни с некоторыми ключевыми особенностями каждого:
• Новичок — основан на правилах, просто хочет достичь ближайшей цели.
• Продвинутый новичок — нуждается в небольших, частых наградах; большая картина сбивает с толку
• Компетентен — может разрабатывать концептуальные модели, устранять неполадки.
• Профессионально — склонен к поиску более крупной концептуальной модели, может самостоятельно исправлять ошибки.
• Эксперт – опирается на интуицию, всегда ищет лучшие методы.
Большинство людей по большинству навыков так и не выходят за пределы Advanced Beginner. Это, безусловно, верно для потенциальных agile-практиков. На уровне продвинутого новичка вы’чувствуете себя достаточно комфортно, чтобы как-то продираться сквозь пальцы. И для большинства людей этого’достаточно. Внешне это выглядит хорошо, и вы можете указать это в своем резюме. Но это пустая победа. Вы не будете пользоваться преимуществами гибкого подхода. С точки зрения производительности вы могли бы программировать на COBOL карандашом в желтом блокноте.
К счастью, мы можем добиться большего.
В модели Дрейфуса пять уровней, но не все уровни одинакового размера и не так легко пройти. Например, легко перейти от новичка к продвинутому новичку, но перейти от продвинутого новичка к компетентному намного сложнее.
Что нам нужно сделать, так это увидеть, как, в частности, совершить скачок от Agile Advanced Beginner до компетентного Agile-практика. Если вы посмотрите на уровни выше, одно большое различие между продвинутым новичком и компетентным практиком заключается в способности компетентного разрабатывать и использовать концептуальные модели.
Итак, кажется, первое, что нам нужно сделать, это создать некую ментальную модель гибкости.
Гибкая ментальная модель
Agile заключается в том, чтобы делать маленькие кусочки и фокусироваться на непрерывном, а не эпизодическом развитии. Вы хотите все время делать всего понемногу, а не сталкиваться с большими кусками крупных событий. Это' часть "constant" в этом определении:
В Agile-разработке используется обратная связь, чтобы постоянно вносить коррективы в среду тесного сотрудничества.(Практики гибкого разработчика, Венкат Субраманиам и Энди Хант)
Идея исправления на основе постоянной обратной связи является ключевой, но для того, чтобы сделать это успешно, вам’нужно убедиться, что все следующее верно:
1. Все ваши методы разработки и управления обеспечивают постоянную и содержательную обратную связь.
2. Вы можете адекватно оценить эту обратную связь в контексте.
3. Вы можете изменить свой код, свой процесс, свою команду и свой интерфейс для остальной части организации и клиента, чтобы ответить на обратную связь.
Это’ только механическая часть. Чтобы быть гибким, вы должны начать с гибкого мышления. Посмотрите на agile-ценности из Манифеста:
• Люди и взаимодействие важнее процессов и инструментов.
• Рабочее программное обеспечение, а не исчерпывающая документация.
• Сотрудничество с клиентами, а не заключение контракта.
• Реакция на изменение вместо следования плану
…и просмотрите приведенное выше определение. Если вы можете действовать таким образом, чтобы уважать эти ценности и придерживаться этого определения, и вы'способны реагировать по мере необходимости, то вы'двигаетесь дальше. или менее гибкое направление. У вас'основная модельгибкости в голове, и, задавая вопросы и постоянно анализируя, что выделаете с точки зрения этой модели, вы' добьетесь прогресса.
Примените это на практике
Во всяком случае, это теория. Но теория не принесет вам пользы, если вы не сможете применить ее на практике. А практика означает попытки, неудачи, обучение и попытки снова.
Поймите, что здесь никто не скажет вам, что делать дальше. Может показаться приятным, что кто-то держит вас за руку в этот момент, но это роскошь, которую могут себе позволить немногие. Вы’ сами по себе.
Знакомые и удобные способы ведения дел могут выглядеть привлекательно, но это ловушка. Не’ не поддавайтесь на это. Вам’ нужно будет погрузиться в незнакомое и неудобное место, а также избавиться от большого ментального багажа. Подумайте о максиме XP и спросите себя: что самое простое может сработать? Что наименьшее, что вам может сойти с рук? Этот вопрос подходит для кода, процессов, документации, обучения, контроля качества и многого другого.
Предположим, вам нужно достичь определенной цели, XYZ. Как сделать это легко, без церемоний, быстро и при этом полностьюдостичь цели?
Например, пройти тестирование (пожалуйста :-).
Вы'начали новый проект на основе agile и знакомите всех с этим новым “agile-материалом.”Теперь вы ' им поручено привлечь сотрудников отдела контроля качества в вашу новую среду для проведения тестирования. Как вы можете сделать это в гибкой манере?
Давайте’ разъясним, что они’делают— это всегда хорошая идея для начала. Мы’не говорим о модульном тестировании. Модульное тестирование названо неправильно; это практика написания кода, а не практика тестирования. Да, это необходимо разработчикам, и нет, этоне оказывает негативного влияния на ваш персонал по контролю качества. Так что, возможно, ваша команда разработчиков использует Test-Driven Development или Test-First Development. Этоотлично, они должны писать модульные тесты на постоянной основе, сохраняя их непрерывными и эпизодическими.
Итак, теперь вам нужно привлечь QA для проведения более всестороннего тестирования, возможно, сосредоточив внимание на приемочном тестировании, тестировании производительности, других нефункциональных требованиях и так далее. Собираетесь ли вы ждать окончания основного релиза, чтобы дать им код для тестирования?
Конечно, нет, это представление о событии как о большом, отдельном эпизоде,— что нарушает модель. Вы не хотите ’непрерывного развития, вам нужно постоянное развитие. Вы собираетесь ждать до конца итерации? Возможно, но это’ все еще ждет и делает из ситуации большее событие, чем нужно.
Предоставьте QA возможность получить тестируемую версию прямо с вашей машины непрерывной сборки. Каждая сборка, прошедшая все автоматизированные тесты для разработчиков, имеет право на участие, и QA может получить последнюю функционирующую базу кода и поиграть. У них есть возможность получать релизы каждый час, каждые полчаса, в течение всего дня. Или они могут подождать и взять его один раз, когда закончат (в негибкой манере), но выбор за ними, и они могут изменить этот выбор по своему желанию.
Это работает?
Как этот простой пример соотносится с нашей ментальной моделью?
Вы’внедрили политику,’легкую и простую в обслуживании. Вы’поставляете ценность постоянно, и вы’поставляете фактическое Рабочее программное обеспечение. Подобно модели голодного потребителя (см. Программист-прагматик), отдел контроля качества может принимать собственные решения о том, когда и что тестировать. Вы можете поэкспериментировать с обратной связью с командой разработчиков, основываясь на потребностях обеих команд. Таким образом, вы’отдаете предпочтение отдельным лицам и взаимодействиям, а не жесткому процессу. Вы’можете реагировать на изменения легко, не влияя на ритм разработки, так как две команды слабо связаны.
Об Энди Ханте
Энди — прагматичный программист, автор нескольких книг, в том числе Прагматическое мышление и Обучение, а также занимается музыкой и деревообработкой. Следите за ним на Mastodon по адресу @[email protected], в Twitter по адресу @PragmaticAndy или в его блоге.
Что такое медитация гуру? Это фирменная шутка из первых дней существования компьютера Amiga, которая относится к сообщению об ошибке операционной системы Amiga, сбивающему с толку обычных пользователей и имеющему смысл только для технически подкованных.
