В своей предыдущей статье я начал дискуссию о плохо выработанных привычках внутри скрам-команды, которые в конечном итоге приведут (рано или поздно) к провалу в доставке. В этой статье я хотел бы еще раз расширить эту тему и сосредоточиться теперь на функциональных процессах внутри команды.
Они так же важны, как и техническое совершенство команды. Даже если люди внутри суперквалифицированы для работы, которую они собираются выполнить, все еще есть области, которые могут свести на нет их усилия по достижению совершенства. И это будет не столько их вина, сколько прямая ответственность за решения по управлению проектом и их способность обслуживать команду с помощью процессов, соответствующих цели, чтобы поддерживать команду с четкими намерениями и предсказуемыми действиями.
Оглавление
Сильно сегрегированная команда с разными наборами навыков
Представьте, что в команде есть опытные разработчики, совершенно независимые и способные выполнять свои обещания и предоставлять согласованный контент спринта как раз к концу спринта. Даже в таком идеальном сценарии (который в любом случае маловероятен) у команды будут проблемы с выполнением (постоянно растущих) функций невыполненной работы, если навыки строго разделены между членами команды.
Несколько примеров
- В команде есть 1 или 2 DevOps-инженера, способные вносить любые изменения в автоматизированные конвейеры или заботиться о сервисах внутри платформы, но остальная часть команды понятия не имеет о таких вещах. Тогда обсуждение этих историй на скрам-церемониях вроде доработок приведет к пустой трате времени для большей части команды на зависание на совещании без какого-либо участия и наоборот — DevOps-разработчику не будут интересны остальные истории, ориентированные на функциональность, и время на встрече также будет в основном потрачено впустую.
- На всю команду работает один эксперт по базам данных. В зависимости от сложности и использования решений для данных в системе, которую разрабатывает команда, этот человек может быть постоянно перегружен историями, которые у него нет возможности завершить достаточно быстро, особенно с учетом их приоритетов. Хуже того, другим историям также придется подождать, поскольку они зависят от источника данных, предоставленного историями из базы данных.
- Когда конкретный продукт в основном ориентирован на бэкенд-разработку, на всякий случай присутствует единственный разработчик внешнего интерфейса (потому что время от времени в любом случае требуются небольшие изменения даже в приложении пользовательского интерфейса). В этом случае, опять же, большая часть церемоний схватки — пустая трата времени для этого члена команды, поскольку его знания ограничены только интерфейсом, а все остальное не имеет значения.
Где это заканчивается
В любом из вышеперечисленных случаев результатом является то, что люди либо тратят свое время впустую, либо, напротив, не могут справиться с отставанием спроса. Они мешают остальной команде начать работу над следующими историями или фактически снижают общую эффективность команды Scrum, потому что слишком много времени не используется в спринте.
Однако в команде по-прежнему есть такое количество разработчиков. Со стороны не видно (даже не желая разоблачаться), что люди внутри команды не способны браться за какие-то истории только потому, что слишком ориентированы на какой-то определенный набор навыков. Таким образом, они не могут помочь другим членам команды с историями, даже если их возможности позволяют это, и приоритеты для историй также благоприятствуют этому.
Владельцу продукта даже трудно составить какой-то значимый контент спринта для команды, поскольку владелец продукта всегда должен учитывать, сколько людей может работать над каждой отдельной историей и будут ли в спринте одновременно появляться больше похожих историй. , в конечном итоге возможности команды переполнены, даже если на самом деле есть люди, которые могли бы работать над этими историями, но у них нет набора навыков, чтобы начать с них.
Решение дилеммы
Это дилемма, которую необходимо решить, и руководители проектов должны знать, какой путь выбрать. В частности, выбор между:
- Наличие большого количества разработчиков полного стека, способных работать с более широким контентом, но не являющихся экспертами во многих темах. Таким образом, они могут идти широко, но не глубоко. Тогда доставка может идти быстро, но качество может пострадать.
- Имея специальных экспертов для каждой технологии, но затем принимая ограничения и усердно работая над более подходящим печатным контентом. Тогда люди смогут углубиться и создать отличные истории, но к историям нужно будет подходить последовательно, что займет больше времени.
Слабый владелец продукта
Это не обязательно «проблема процесса» по определению, но я отношусь к ней так только потому, что создание надежных историй можно понимать как процесс, который команда должна хотеть иметь надежным и совместимым с командой разработчиков.
То, что я подразумеваю под слабым, не должно относиться к свойству знаний человека, а скорее к способности владельца продукта обслуживать командные истории, которые разработчики могут понять и которые имеют некоторый ясный смысл с точки зрения дорожной карты продукта. И то, и другое очень важно для успешной скрам-команды.
Если в историях не хватает деталей, чтобы разработчики могли четко понять цель, функциональную ценность или технические ожидания, то в основном могут произойти два сценария:
- Разработчики создадут что-то отличное от того, что на самом деле хотел владелец продукта. Это даже трудно уловить во время самого спринта, потому что в основном владелец продукта не имел возможности отслеживать ход историй на таком детальном уровне, и в основном PO просто ожидает, что что-то произойдет (волшебным образом).
- Разработчики будут тратить слишком много времени на разъяснение историй и их обсуждение снова и снова, вместо того, чтобы начать их создавать. Это включает в себя множество дополнительных звонков, повторные соглашения и перенос работы на поздний этап спринта. Наступает момент, когда первоначальные оценки историй уже нельзя считать точными, а истории невозможно закрыть в рамках спринта, и они переходят в следующие спринты. В худшем случае ситуация повторяется в последующих спринтах.
Время для саморефлексии
Обычно это трудно признать, но владелец продукта должен найти время, чтобы подумать, посмотреть на созданные истории невыполненной работы и, в конечном итоге, сравнить их с видением дорожной карты продукта, если между ними все еще есть какая-то разумная связь — если есть какая-либо дорожная карта. совсем. Если нет, то это первое, что нужно решить. Иногда решение состоит в том, чтобы признать, что владелец продукта слишком далек от команды и слишком далек от своей цели.
В таком случае, часть команды, принадлежащая владельцу продукта, должна быть решена. По крайней мере, привлечение в команду надежного бизнес-аналитика, ориентированного больше на содержание команды, а не на бизнес-контент (для этого у нас уже есть владелец продукта в этом случае), может быть приемлемым вариантом, даже по цене увеличение общих затрат команды.
Процессы тестирования без фиксированной временной шкалы
Что, если действия по тестированию не привязаны к конкретному графику внутри спринта?
На первый взгляд это может показаться чем-то хорошим, чего мы хотим от agile/scrum-команды. Гибкость всегда приветствуется и звучит хорошо, когда представлена снаружи.
Мой опыт показывает, что результатом этой свободы является больше хаоса, чем гибкости. Это не означает, что решением этой проблемы должно быть создание «водопадов внутри спринта» с выделенными фазами тестирования, которые следуют сразу после завершения разработки. В данном случае это не совсем правильный подход. Вы можете прочитать больше об этом в моих постах о стратегии тестирования схватки и жизненном цикле гибкого тестирования.
Мы по-прежнему можем допустить некоторую гибкость и выбрать график тестирования, который выглядит наиболее подходящим для текущей команды разработчиков и заданных свойств продукта, которые команда предоставляет. Однако при таком выборе должны быть достигнуты две основные цели:
Если эти условия будут соблюдены, команда естественным образом адаптируется к процессу подгонки, и на график поставки не повлияют незапланированные длительные испытания.
В конце концов, важнее всего надежный и предсказуемый выпуск спринта, что подводит меня к последнему пункту этого блога.
Неопределенный процесс выпуска
Это очевидная вещь для каждой скрам-команды. Тем не менее, как ни странно, это также обычно один из самых недооцененных процессов.
Очень часто скрам-команда просто говорит, что релиз будет после каждого спринта, но это не подкрепляется прочным процессом. Что происходит тогда, на самом деле, так это то, что во время релиза возникнет множество хаотичных, непредсказуемых действий. Внезапно все люди заняты «выпускными задачами», и никто не может сосредоточиться на продолжении разработки новых историй спринта. Показатели спринта отключены, а релиз выглядит как случайная, непредсказуемая активность с точки зрения третьего лица (обычно клиента).
Люди настолько сосредоточены на бэклоге, содержании спринта, разработке, тестировании и, наконец, демонстрации результатов, что забывают, что как только они со всем этим закончат, следующий спринт уже идет, и они уже теряют время.
В поисках подходящего времени для релиза
Итак, когда именно команда должна сделать фактический выпуск в производство? Единственная важная вещь, которая имеет значение в конце.
Ответ на этот вопрос находится в процессе, если он у вас есть. В зависимости от:
- сложность контента, который команда создает в спринтах,
- продолжительность спринта,
- количество затронутых компонентов в системе
- количество людей, использующих и запрашивающих изменения,
следует установить процесс повторного выпуска и следовать ему в дальнейшем. Точные правила процесса могут снова быть гибкими в определении. Но, как и в случае с тестированием, превращение его в прочную привычку, которая предсказуема и запланирована на конкретные дни в будущем, делает ее чем-то, на что можно положиться и на что можно ссылаться.
Варианты выбора
Возможными формами такого процесса могут быть любые из следующих или другие:
- Завершите тестирование функций текущего спринта в течение следующего спринта и выпустите контент в конце этого спринта (после завершения тестирования). Это означает, что в каждом выпуске не будет контента из самого последнего спринта, но он будет содержать истории из двух предыдущих спринтов.
- Последний спринт перед релизом всегда посвящен тестированию контента двух предыдущих спринтов.
- Это не означает, что разработка во время «тестового спринта» будет остановлена; в нем только говорится, что контент, разработанный в этом тестовом спринте, еще не будет включен в следующий выпуск.
- Если уже проведено достаточно автоматизированных тестов, старайтесь выпускать релиз после окончания каждого спринта. Тогда это должен быть очень строгий процесс с преданными делу людьми, которые сосредотачиваются на этих нескольких днях на 100%. Это все еще не должно каким-либо образом повлиять на остальную часть команды разработчиков.
- Вы также можете выбрать выпуск один раз в месяц или один раз в N месяцев, в основном, если это будет хорошо с точки зрения конечных пользователей. Это увеличит усилия на стороне тестирования для каждого спринта (поскольку контент будет больше для каждого выпуска). Но, с другой стороны, это будет означать меньшее количество повторяющихся действий с течением времени, что в этом случае может принести пользу команде. В результате это может позволить команде создавать больше новых функций между выпусками, несмотря на то, что на самом деле функции будут внедряться в производство с более медленным темпом.
Но, как уже говорилось несколько раз ранее, не так важно, какой из этих процессов будет выбран. Гораздо важнее, насколько хорошо команда будет придерживаться этого процесса и сделает его прочной привычкой.
Вы также можете прочитать это руководство по процессу и практикам управления релизами.