с которой будет дальше, разрабатывая Agile для продаж, и вовсе отказалась от этого требования разработчиков методологии. Так как заменила минимально готовый продукт финансовым планом на спринт. И все-таки лучше его поискать.
Минимально жизнеспособный продукт обладает определенными качествами. Он должен быть:
• функциональным;
• надежным;
• готовым к употреблению.
Минимально жизнеспособный продукт в Agile не является прототипом продукта. Потому что прототип мы можем нарисовать в презентации, снять по нему видео, сделать макет, но мы не можем продать его потребителю. В этом отличие этих двух понятий.
Главное назначение минимально готового продукта в Agile:
• убедиться, что идея, над которой работает команда, нужна потенциальным потребителям;
• составить свое представление о целевой аудитории продукта, возможно, внести какие-то изменения в свое первоначальное представление об этом;
• собрать и проанализировать обратную связь, составить протокол необходимых изменений, внести эти изменения в бэклог следующего спринта;
• получить импульс для размышлений о правильности идеи и ее исполнения;
• повысить мотивацию команды, увидевшей реакцию потребителей и Заказчика, даже если она критическая, но все равно доброжелательная, поскольку все заинтересованные лица всегда благодарны за то, что их спросили о продукте по ходу дела, а не в конце, когда уже ничего нельзя изменить;
• начать монетизировать свои разработки;
• сократить сроки и бюджет производства конечного продукта за счет раннего распознавания положительных и отрицательных качеств продукта.
Вернемся к тем понятиям, о которых вскользь упоминалось во вступлении к книге, для выравнивания информационного поля. Теперь – некоторые интерпретации и упорядочение понятий методологии.
Роли
Мы не включаем Заказчика в список традиционных ролей в SCRUM, поскольку он действует за рамками процесса. Это может быть руководитель направления, который инициирует проект и принимает решение реализовать этот проект посредством Agile. Иногда роль Заказчика выполняет первое лицо компании. Это зависит от того, какой уровень задачи стоит перед командами, какого размера сам бизнес, какой уровень корпоративной культуры в компании и принятый в коллективе стиль руководства.
Заказчик присутствует на обзоре спринта (релизе), когда команда демонстрирует минимально готовый продукт, созданный за период спринта. Далее на конкретных примерах из бизнеса мы будем говорить о том, чем чревато нарушение этого правила.
Итак, в SCRUM действуют три основные роли.
1. Владелец продукта (Product Owner).
Предпочтительно, чтобы человек, занявший эту роль, прекрасно разбирался в бизнесе, в котором работают команды, и знал запросы потенциальных клиентов. Это важно, так как он составляет бэклог продукта – описывая весь объем работы на проект – и отвечает за результат деятельности команды. Если у участников возникает потребность изменить что-либо в бэклоге продукта, то делается это только через Владельца продукта.
Он дает команде понятные требования для работы, разъясняет сложные моменты, уточняет у Заказчика ответы на вопросы, возникшие у команды, организует взаимодействие с различными подразделениями компании, если это требуется команде. Не являясь руководителем команды ни в коей мере, Владелец продукта участвует в тестировании результата работы перед обзором спринта и демонстрацией продукта перед Заказчиком и потребителями. Основная задача Владельца продукта, несмотря на большую ответственность за производственную часть работы, – постоянно поддерживать у участников видение и понимание цели.
Владелец продукта осуществляет свою деятельность для команды, но вне команды. Он не вмешивается во внутренние процессы, происходящие во время работы над проектом, но отвечает на запросы участников, направленные вовне: к другим подразделениям, подрядчикам, поставщикам, аналитикам.
Для Заказчика Владелец продукта играет очень важную роль, поскольку поддерживает в нем уверенность, что все действия команды соответствуют первоначальному замыслу и видению. Владелец продукта может ответить на любой вопрос о том, как движется работа, и в любое время, когда в этом появляется потребность, не ожидая окончания спринта.
Естественно, что для реализации всех требований к Владельцу продукта, человек, который получит эту роль, должен ко всему прочему быть хорошим коммуникатором. Правда, в Agile все участники учатся говорить, даже если не очень отличались разговорчивостью на собраниях и конференциях.
2. SCRUM-мастер.
Деятельность этой роли, напротив, направлена внутрь команды. Все, что делает SCRUM-мастер, способствует тому, чтобы команда соблюдала все ритуалы методологии, ритм работы и поддерживала деловую, творческую атмосферу в коллективе. При этом у SCRUM-мастера, так же, как и у Владельца продукта, нет власти самостоятельно решать какие-то вопросы. Его роль – служение команде.
SCRUM-мастер работает в трех направлениях: проводит мероприятия в четком соответствии с правилами, поддерживает визуализацию процессов на SCRUM-доске, сопровождает преобразование команды в единое целое. От его профессионализма зависит адекватность распределения равных по объему и сложности задач между участниками. Но при этом не принимает выполненную работу и не тестирует ее, как у нас случилось в одном консалтинговом проекте.
Просто со стороны может показаться, что человек, который распределяет задачи, спрашивает, что сделано и что намечено в работу, должен и собирать результаты. Но это не так. Категорически SCRUM-мастер этим не занимается. Но это достаточно частая ошибка. Происходит она по причине, что в Agile мало того, чтобы руководитель отдал свою ответственность команде, нужно, чтобы команда приняла ее и присвоила, отказавшись от старой привычки быть лишь ни за что не отвечающими винтиками в производственном процессе. Agile кардинально меняет эту парадигму и создает новые привычки, при которых личная ответственность становится коллективной ответственностью команды, как единой роли в SCRUM-методологии.
3. Команда.
Этой роли будет посвящена вся пятая глава. Настолько важно то, кто войдет в команду, как распределятся роли, как будет происходить взаимодействие между всеми участниками, что это выделено в отдельную главу. Недостаточно только подобрать профессионалов, способных решить задачу в полном объеме от начала работы до выхода продукта на рынок, это еще должна быть команда, действующая как единый организм. Недаром основоположники Agile объединили команду в одну роль. Все процессы, которые происходят по пути к реализации цели, решаются в команде сообща, большинством голосов утверждаются изменения, коллективно тестируются гипотезы и готовятся демонстрационные версии минимально готового продукта. И, конечно, совместно празднуется победа, что сильно повышает мотивацию каждого члена команды.
Документы
Когда мы рассказываем на своих тренингах о том, что такое бэклог спринта и продукта, мы представляем своим слушателям большого слона, которого надо съесть по кусочкам. Слон – это цель на весь проект, а спринты – это те части, которые надо хорошо приготовить и подавать к столу по одному. Этот образ дает хорошее представление о том, как разделить задачу на составляющие и не потерять качество и цель конечного продукта.
В соответствии со своей ролью, Владелец продукта – единственный, кто отвечает за конечный продукт, поэтому на нем лежит ответственность составить бэклог продукта таким образом, чтобы предусмотреть все аспекты работы над продуктом. От полноты этого документа во многом зависит успех команды.
При этом бэклог продукта составляется таким образом, чтобы задачи, которые он содержит, были понятны членам команды, выполнимы и оцифрованы. Здесь как раз время вспомнить о том, что до того, как создавать бэклог продукта, участники проекта уже составили канвас продукта, определили все его аспекты. Таким образом, у Владельца продукта уже есть все наработки, чтобы выполнить свою работу качественно.
После того как Владелец продукта, знающий бизнес и все процессы производства продукта, составил бэклог продукта, команда совместно со всеми другими ролями создает бэклог спринта.
В начале пути, прежде чем обсуждать задачи и присваивать их себе, члены команды принимают решение, какой продолжительности будут спринты в течение всего проекта. Изначально выбранная командой длительность спринтов на протяжении всего проекта остается неизменной. В расчете учитывается не только то, сможет ли команда в определенный период выдать минимально жизнеспособный продукт, но и то, насколько часто Заказчик, потребители и подрядчики смогут участвовать в демонстрации результата в конце спринта.
На практике проверено, что спринт не должен быть больше, чем четыре недели, так как в противном случае он превратится в обычную процессную деятельность. То есть исчезнет скорость и напряжение, а следом и мотивация. В нашей консультационной работе оптимальными стали две недели спринта. Как только заканчивается один спринт, сразу же создается следующий.
В исключительном случае, а такой может произойти в любом проекте, Владелец продукта может отменить или перенести спринт из соображений целесообразности.
В Agile вне IT-отрасли этот документ может использоваться факультативно, но не обязательно. Мне не приходилось встречать этот документ в своей консалтинговой работе. В этой диаграмме отражается динамика работы команды в течение спринта, чтобы сориентировать участников, какой объем работы уже сделан, что остается до окончания спринта и успевает ли команда создать минимально готовый продукт.