[БЕЗ_ЗВУКА] Рассматривая в одной из предыдущих лекций роль в скрам-команде владельца продукта, мы отметили, что главной задачей и головной болью последнего является составление и управление бэклогом. Сегодня мы подробно остановимся на данном вопросе. Что следует понимать под бэклогом? В общем виде это список, или, если угодно, журнал предстоящей работы команды над проектом. Бэклог в гибком планировании рассматривается в качестве его важнейшего инструмента, поскольку актуальный, простой и понятный список задач по созданию продукта значительно облегчает работу. Бэклог, включающий в себя совокупность задач, решаемых в ходе всего проекта, называется продуктовым. Если же мы имеем в виду набор задач и требований для отдельной итерации, то это будет бэклог спринта. Характерной особенностью в составлении бэклога в гибких методологиях является максимально возможный учет всех позиций, выбранных для разработки непосредственно силами потребителей, заинтересованными сторонами. Достигается это посредством активного взаимодействия между всеми участниками реализуемого проекта. После составления общего перечня всех высказанных предложений владелец продукта определяет приоритетные направления в продуктовом бэклоге и начинает совместно с командой осуществлять планирование, анализ различных элементов для включения их в бэклог спринта. В итоге общими усилиями определяется объем требований для предстоящего спринта. Последовательность задач бэклога спринта также формируется с учетом определенной приоритетности его элементов. Некоторые функции для заказчика представляют больше значимости, чем другие. Определяя, какие из них включать в ту или иную итерацию, команда осуществляет анализ ценностей, то есть сколько стоит функция по отношению к затратам. Иначе говоря, сколько потребуется сделать работы для ее создания. Приоритизация задач является важным и эффективным методом работы скрам-команды. Дело в том, что при традиционном подходе к управлению проектом для клиента неважно, в какой последовательности команда выполнит все виды работ, поскольку все они включены в перечень. Такой подход обычно приводит к тому, что в конце проекта команда, стараясь уложиться в календарный график, начинает сокращать набор функций. А так как над приоритетностью их никто не задумывался, то часто отбрасываются те функции, которые имеют бо́льшую ценность, чем функции, включенные в продукт. С самого начала планирования спринта команда и владелец продукта должны найти взаимопонимание о том, из чего состоит каждый из пунктов бэклога. Окончательное решение вопроса, какие пункты войдут в бэклог спринта, принимает владелец продукта. И даже после начала спринта владелец продукта может изъять задачи из бэклога спринта, если они в силу каких-либо обстоятельств утратили свою актуальность, не останавливая при этом сам спринт, но и не добавляя задачи взамен. Правильная подготовка бэклога спринта — это половина успеха в предстоящей работе. А разбивая пользовательские истории, команда составляет список индивидуальных задач, формулируя их на отдельных карточках. Данная процедура выполняется применительно ко всем пользовательским историям. После этого карточка пользовательской истории, включенная в спринт, группируется вместе с карточками своих задач и размещается на доске задач в разделе «Сделать». Попутно заметим, что иногда для историй и задач, вытекающих из них, используются карточки различных цветов, что позволяет быстрее отличать их друг от друга. Каждый член команды одновременно занимается решением только одной задачи, поскольку переключение внимания с одного проекта на другой или даже на иную задачу внутри одного проекта, особенно не связанных между собой задач, неизбежно создает для исполнителя дополнительную нагрузку и снижает результативность его деятельности. Закончивший работу над своей задачей, перемещает карточку выполненной задачи в раздел «Сделано» и берет для себя следующую карточку из колонки «Сделать». И написав на ней свое имя, помещает ее уже в раздел доски задач «В процессе». Так, по мере работы над спринтом вся команда переносит задачи из колонки «Сделать» в колонку «В процессе» и затем в колонку «Сделано». Однако при этом следует помнить о том, что пользовательская история не будет считаться выполненной, сделанной до тех пор, пока ее не примет и не одобрит владелец продукта. Если же он решит, что история соответствует не всем критериям, то данная история опять занимает свое место в разделе «Сделать». Кстати, продемонстрированный процесс в точности соответствует методу управления Kanban. Это метод, способствующий равномерному распределению нагрузки, когда весь процесс разработки прозрачен для всех членов команды. Kanban — это японский термин, который начали использовать применительно к производству в 60-х годах XX века в компании «Тойота». В основу данного принципа положен конвейерный метод производства, а также различные скорости выполнения отдельных технологических операций на производстве. При планировании бэклога очень большое значение имеет Definition of Done, то есть однозначное определение понятия «выполнено». Данное определение должно содержать в себе четко сформулированное представление о том, что это означает для каждого пункта бэклога. Это сделанная работа, решенная задача, которая не требует дальнейшей доработки. Скрам-планирование пытается при этом ответить на вопрос: а как оценить, понять, убедиться в том, что задача действительно выполнена? Этот вопрос отнюдь не простой, на него не всегда есть однозначный ответ. Скажем, вы выполнили свою задачу, которая является частью общего процесса, который будет завершен через некоторое время. Действительно ли вам не придется вернуться к своей части работы? Из-за подобной неопределенности может возникнуть множество проблем. Использование же Definitions of Done позволяет реально оценивать ситуацию. В свою очередь, любые пункты, оставшиеся в статусе «Не выполнено», будут в обязательном порядке возвращаться в продуктовый бэклог до момента полной готовности. Поскольку владелец продукта является голосом заказчиков, то они, зная о таком подходе в работе команды, могут быть уверены, что ни одно их пожелание не будет упущено или не доработано. Бэклог задач будет считаться выполненным, когда его положительно оценит и примет владелец продукта, а весь результат можно будет продемонстрировать клиентам. Участник agile-команды должен лаконично, буквально одной строчкой, одним предложением или кратким списком дать понять другим, на что следует обратить внимание. Defintion of Done необходим для четкого понимания каждым членом команды того, что было сделано и что нужно в будущей работе. Не следует перегружать бэклог текущего спринта. Лучше и полезнее оставлять в нем некий запас времени для непредвиденных обстоятельств. Любая команда вынуждена бороться с неожиданно возникающими проблемами. Иногда исправление не может ждать окончания текущего спринта, и команде придется заняться этим вопросом немедленно. Если владелец продукта согласится с данными изменениями от лица заказчика, то команда добавляет эту срочную задачу в бэклог спринта, определив ее приоритет, как правило, в таких экстремальных ситуациях он бывает наивысшим, и использует все возможности, чтобы закрыть этот вопрос. Также весьма нежелательно учитывать нагрузку сверх той, что была рассчитана в предыдущих спринтах. О методах, дающих возможность команде планировать достаточно равномерно нагрузку в бэклогах, мы поговорим с вами еще и в следующей лекции, посвященной анализу пользовательских историй.
