В этом случае мы можем говорить об историях сотрудников, и их сюжет будет таким: «Играя
Истории в бэклоге, задачи в спринте
Истории покупателей и сотрудников могут служить основной расчетной единицей приоритизированной маркетинговой работы, как показано на рис. 14.1. В предыдущей главе мы говорили, что циклы agile-спринтов начинаются с обновления бэклога. Во время планирования спринта команда вытягивает из журнала наиболее приоритетные элементы, добавляет их в колонку «Сделать» на канбан-доске и выполняет в соответствии с рабочим процессом маркетинга.
РИС. 14.1.
ПРИ ПЛАНИРОВАНИИ СПРИНТА ИСТОРИИ ИЗ БЭКЛОГА ПРЕВРАЩАЮТСЯ В РАБОЧИЕ ЗАДАНИЯТеперь можно обрисовать эту картину точнее, опираясь на истории. Маркетинговый бэклог должен состоять из историй покупателей и сотрудников. Если отдел большой, целесообразно иметь несколько бэклогов для разных групп. Тогда удастся избежать чрезмерного разрастания одного бэклога. Детализация историй (кто, что, для чего и почему) должна быть достаточно подробной, чтобы обеспечить быстрый темп гибкого управления (см. рис. 14.1). Но она не может диктовать, какие шаги надо предпринять для выполнения задач, соответствующих этим историям.
Когда история вытягивается в спринт из бэклога, при планировании команда делит ее на несколько задач. По общему правилу, задача должна быть такого размера, чтобы ее можно было завершить в течение одного спринта. Ее выполняет один либо несколько членов команды поочередно.
Некоторые истории и так довольно малы, и их не нужно разбивать на задачи. Например, история покупателя, созданная с целью написания поста в блоге или простой кампании имейл-рассылки, может вполне двигаться по канбан-доске как одна задача. Однако масштабную историю, такую как большой массив маркетингового контента, желательно разделить на задачи: написание текста, разработка графического дизайна, целевой страницы, уведомлений по электронной почте, размещение сообщений в соцсетях, продвижение и прочее.
При делении истории на задачи следует учитывать, какие из них можно выполнять
Вы можете сами решить, как поделить истории на задачи. Если деление слишком дробное, то канбан-доска будет «замусорена» мелочами. А вот при чересчур крупных задачах теряется прозрачность рабочего процесса и уменьшается гибкость. Между этими полюсами находится широкий спектр возможностей. Постарайтесь отрегулировать степень детализации задач для команды в соответствии с обстоятельствами.
Выбор степени детализации задач, параллельности или последовательности в рабочем процессе — отличные темы для ретроспективы спринта.
И еще, при дроблении полезно убедиться, что в задачах есть указание на историю, для воплощения которой они реализуются. Тогда тот, кто будет выполнять задачу, сможет глубже понять,
Бэклог как инструмент гибкого управления
Самое главное правило: задачи в бэклоге должны быть приоритизированы. Из-за сложности компромиссов иногда появляется искушение утверждать, будто все рабочие задания одинаково ценны. Тем не менее, учитывая ограниченность ресурсов, особенно времени, мы не в силах сделать все сразу. Приходится выбирать, что должно выполняться в первую очередь, а что — во вторую, третью и далее по порядку. Тут уместно вспомнить поговорку: если вы ничего не выбрали, вы все же сделали свой выбор. Если придумывать слишком много историй с равным приоритетом, то порядок завершения задач окажется случайным. Члены команды начнут принимать различные решения, влияющие на результат, не осознавая, какие цели важнее других.
Обязательная расстановка приоритетов в бэклоге устраняет эту двусмысленность. Все члены команды и заинтересованные лица видят, что находится в верхней части списка в следующем спринте, а до чего очередь дойдет позже и в какой последовательности.