Привыкнуть к гибким действиям может быть непросто для всех в организации, от высшего руководства до инженера основной команды.
Но применение гибкой технологии — это больше, чем просто слепое следование ритуалам, заполнение артефактов и обозначение людей ролями.
Гибкая организация должна воплотить философию гибкой, чтобы извлечь реальную выгоду из процесса. В противном случае Agile может стать заменой для любой популярной техники управления модными словечками, и она только поможет скрыть любые реальные проблемы, которые могут существовать.
Чтобы распознать потенциальные проблемы гибкого процесса и решить их, полезно иметь набор сигналов для отслеживания.
Вот четыре таких сигнала, которые я заметил — я называю их «запахами процесса».
Распознавание запахов процесса
Как инженер, который работал в командах разработчиков в течение многих лет, одна из моих любимых метафор для того, чтобы замечать что-то подозрительное в том, как проект выполняется, — это «запах кода».
Запахи кода — это узнаваемые образцы поведения, которые отражаются в коде, который создает команда, и они обычно означают проблемы.
В Javascript запахом кода может быть злоупотребление глобальными переменными, объявленными без ключевого слова var В HTML распространенным запахом кода является чрезмерное использование элемента div Одним из распространенных запахов кода является кодовая база без автоматизированных тестов или тестов, которые проверяют основные языковые функции, но игнорируют критическую бизнес-логику.
Запахи кода часто указывают на то, что команда разработчиков не обращает внимания на качество своей работы. Зачастую они являются признаком того, что кодировщики были слишком быстро загружены, чтобы соответствовать одному варианту использования в необоснованный срок. В этом случае команде не хватает стимулов для рассмотрения последствий для удобства обслуживания, читаемости или масштабируемости.
Когда инженер говорит вам, что ваш код пахнет , это часто означает, что существует глубокая основная проблема, которую необходимо решить, прежде чем можно будет предпринять практические изменения.
Гибкий рабочий процесс обычно работает в среде кодирования, но сам Agile сообщается на языке, который люди используют для обмена идеями и отслеживания прогресса. За эти годы я заметил несколько моделей общения, которые я считаю запахами процесса .
Это фразы или отношения, которые возникают во время разговора, которые указывают на то, что организация может использовать терминологию agile, продолжая при этом старые практики, которые подрывают их усилия по эффективному использованию agile.
Вот некоторые подсказки, на которые я настраиваюсь, когда слоняюсь по запахам процессов в организациях, которые пытаются внедрить гибкие методы. Я также проиллюстрирую, как я обращаю на них внимание, чтобы их можно было признать и обработать.
1. «Разве мы не можем просто…»
Одна из фраз, которую люди начинают использовать, когда они тестируют границы agile, — это некая вариация «не можем ли мы просто…»
Это может произойти, когда владелец продукта пытается втиснуть дополнительную функцию в задел, который уже был определен. Это может быть важной особенностью. Возможно, это не вина владельца проекта, что никто не заметил, что он отсутствовал, пока не было завершено отставание. Истории в отставании могут даже не иметь смысла без этого.
Но «мы не можем просто» открывает двери для ползучести. Часть того, что заставляет гибкие методологии работать, состоит в том, что у команды есть возможность распознать и выполнить весь объем работы, которую они собираются завершить в данном спринте, прежде чем спринт начнется. Как только эта область была определена, команда знает сверху вниз, над чем они должны работать.
Инженеры гибкой команды могут поверить, что они не будут испытывать затруднения при изменении ожиданий и требований, по крайней мере, до тех пор, пока длится спринт. Эта безопасность дает им возможность работать эффективно и целенаправленно.
Когда вы слышите, как люди в команде говорят «мы не можем просто», напомните им, что они согласились следовать гибкому процессу, потому что они осознали ценность, которую он будет предлагать по сравнению с тем, что они делали раньше. Укажите преимущества поддержания доверия команды и предоставления им возможности сосредоточиться на историях, которым они привержены.
Затем спросите их: «Разве мы не можем просто сохранить это до следующего спринта?»
2. «Исторически это не сработало здесь».
При внедрении гибкого процесса, как правило, существует уже существующая схема выполнения задач, которую заменяет гибкая.
Возможно, определенные инженеры «владеют» определенными функциями, и люди в компании привыкли обращаться к ним напрямую, когда возникают проблемы. Возможно, владельцы продуктов привыкли работать вместе с инженерами, чтобы определять функции по мере их создания, вместо того, чтобы создавать понятные пользовательские истории.
Но организация не стала бы рассматривать возможность применения гибкой технологии, если бы в прошлом работал способ. Хотя такое поведение может быть глубоко укоренившимся, команда и руководитель схватки должны помогать обучать людей, как внутри, так и за ее пределами, гибкому способу ведения дел.
Возражения, основанные на истории, могут исходить от людей в команде, которым неудобно пытаться объяснить, как гибкий процесс отличается от клиентов, старшего руководства или клиентов. Эти возражения могут также исходить от людей в команде, которые полагались на старые шаблоны и привычки, чтобы разработать способы защиты своих карьерных путей и предпочитаемых рабочих процессов, даже если эти шаблоны были разрушительными для команды в целом.
Лучший способ справиться с этим возражением — подготовить разумные ответы на эти вопросы. Укажите, что команда пробует что-то другое, и что Agile — это итеративный процесс. Всегда можно попробовать что-то для одного спринта, а затем обсудить это на ретроспективе, если окажется, что это не работает. Напомните людям, что раньше дела шли не очень хорошо, и у agile есть прямые ответы на некоторые из этих, казалось бы, укоренившихся проблем.
3. «Это исправление в одну строку».
Сфера ползучести бывает во многих формах. Одним из наиболее распространенных является предположение (часто кем-то, кто не знает, как работает код), что конкретное изменение критериев приемлемости для истории, уже находящейся в зачете спринта, мало повлияет на уровень усилий.
Но заблуждение здесь заключается в том, что размер запроса функции каким-то образом делает безопасным введение этого изменения после того, как задание спринта было установлено и согласовано.
Эта проблема может исходить как от владельцев продукта, так и от инженеров. Часто инженеры сталкиваются с частью кода, над которым они работают, и признают, что что-то не связанное с историей кажется быстрым решением.
Есть несколько проблем с этим. Во-первых, внесение этого изменения означает, что команда будет выполнять работу, которая не будет точно отражаться в ее скорости. Это рискует изменить функциональность продукта так, чтобы это не отслеживалось в историях. Кроме того, очевидные однострочные исправления могут иногда иметь более глубокие последствия, ведя инженеров к кроличьей норе и отводя больше внимания от целей спринта.
Является ли влияние предлагаемой работы в середине спринта на самом деле минимальным, на самом деле не имеет значения. Дело в том, что критерии оценки истории меняются после оценки истории. Независимо от того, насколько незначительной является проблема, при появлении несвязанного изменения об этом следует упомянуть владельца продукта и рассматривать как независимую историю, которую нужно добавить в «холодильник» до тех пор, пока она не будет запланирована и оценена должным образом.
Затраты на проведение такой большой церемонии за то, что на первый взгляд может показаться тривиальным, являются полезными инвестициями в поддержание гибкого процесса в чистоте и надежности для всех участников.
4. «Нам нужно нанять больше инженеров рок-звезд ниндзя».
Культура героя лежит в основе многих проблем инженерных организаций.
Часто организация проводит годы, празднуя ключевых инженеров, которые работали до поздней ночи и в выходные дни, чтобы решить сложные проблемы. Структура вознаграждения для компании иногда строится вокруг того, насколько очевидными были усилия по преодолению трудной задачи, а не ценность бизнеса или поддержка остальной части команды. Герою, взявшему на себя сверхскоростную задачу и придумавшему удачное решение, могут быть вручены премии, аплодисменты и аплодисменты на встречах компании.
Проблема культуры героев заключается в том, что она не создает устойчивую рабочую среду, в которой всем предлагается вносить свой вклад и делиться правами владения кодом в рамках всей команды. Когда организация сосредотачивается на своих героях-инженерах, остальная часть команды может испытывать недостаток внимания и ресурсов, создавая больше обиды, чем мотивации.
Инженеры-герои могут работать над специальными проектами, которые они считают интересными, но их время и энергия отвлекаются от усилий команды. Они могут игнорировать направление, намеченное владельцами продукта, или они могут работать вместе с владельцами продукта, чтобы разрабатывать решения вне гибкого процесса, которому следуют все остальные. В любом случае, такой подход подрывает доверие и сплоченность команды и создает искусственное впечатление об истинной скорости команды.
Кроме того, код, разработанный индивидуалистами, работающими в нерабочее время и работающими на кофеине и других стимуляторах, почти наверняка не тот вид, которым вы хотите похвастаться перед своими клиентами.
Если бы вы ставили будущее своей компании на продукт, поверили бы вы организации, чья литература по набору персонала была сосредоточена на рок-звездах и ниндзя? Лично я хотел бы получить свои продукты от компании, которая стоит за своим кодом и демонстрирует это, предоставляя своим инженерам то, что им нужно для правильного выполнения работы.
Гибкий процесс стимулирует командные усилия, в которых все работают вместе, и разделяет как кредит, так и ответственность за весь продукт. Код, разработанный изолированно, всегда будет иметь подпись того, кто его написал. Опора на рок-звезд и ниндзя может поставить усилия вашей компании по разработке продукта на милость уникального кода, в который другим людям будет сложно вмешаться и измениться, если этот конкретный инженер однажды выиграет в лотерею и выйдет из нее.
Обнюхивать запахи процесса
Несмотря на то, что мастеру схватки поручено обеспечивать бесперебойное продвижение гибкого процесса, все в организации должны обратить на это внимание.
Даже в компаниях, которые вложили время и деньги в обучение и материалы, местный колорит гибкой манеры может быть лишь тонкой завесой, скрывающей сломанный и хаотичный процесс.
Слушание того, как люди говорят о работе, которую они выполняют, может выявить скрытые закономерности, которые необходимо разоблачить и устранить.