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