Текст книги "Время быть Agile"

Глава 4
Ритмичность и прозрачность SCRUM

SCRUM – наиболее распространенная методология. Роли в команде. Ритуалы и ритмы SCRUM. Особенности целеполагания в Agile.

Методология SCRUM стала структурированной рамкой для ведения проектов в гибком менеджменте, и в этом заложено противоречие между свободой, которую дает идеология Agile, и беспрекословным соблюдением SCRUM-ритуалов, как того требуют адепты. Когда это противоречие стало сдерживать трансформацию, творческая энергия победила и начала вносить изменения в методологию, адаптируя ее под все новые сферы распространения Agile.

В этой части мы вплотную подходим к методологии SCRUM, посредством которой реализуется Agile-философия. В IT-индустрии есть несколько популярных методологий, они подстраиваются под масштабность и многогранность задачи для команд. Но для нетехнологичных бизнесов оптимальной стала методология SCRUM. Поэтому именно на ней мы и остановимся, тем более что все наши консалтинговые проекты опирались именно на эту методологию, и в ней у нас есть практический опыт, позволяющий смело рассуждать о ее плюсах и минусах.

Итак, в команде, работающей по SCRUM, есть три роли: Владелец продукта, SCRUM-мастер и сама команда, как субъект. У каждой роли свои обязанности и свой объем ответственности за процесс. Объективно есть еще одна важная роль в команде – это Agile-коуч. Он присутствует при всех важных переломных моментах в жизни команды, он выстраивает отношения, снижает эмоциональные качели и направляет команду к цели. Однако эта роль осталась за рамками SCRUM-руководства, поскольку коуч – как правило, внешний консультант, сопровождающий Agile-трансформацию.

Придерживаясь принятого мной правила не повторять дословно информацию, которую уже многократно описывали различные источники, о применении Agile в IT-сфере, тем не менее я даю общие сведения со своей интерпретацией для тех, кто впервые слышит об этом и хочет сам разобраться, что он может взять из этого в свою жизнь, в свой бизнес.

SCRUM состоит из четко прописанных ритуалов, ролей и мероприятий. Важно, чтобы все участники процесса знали терминологию, понимали, что она означает и правильно ее применяли. В таком случае создается единое информационное поле, исключающее разночтения и самовольную интерпретацию. На первый взгляд это условие кажется сложным, но в процессе работы, когда все участники овладевают знаниями методологии, становится очевидно, насколько проще в таком поле осуществлять рабочие процессы.

ЕСЛИ КОМПАНИЯ УЖЕ AGILE, ТО НИКТО НЕ УМЕР. ПОТОМУ ЧТО ЕСТЬ РЕФЛЕКСИВНЫЙ ЦИКЛ. ЭТО ГЛАВНОЕ СВОЙСТВО AGILE, ПОЭТОМУ ОН ЛУЧШЕ ПРИСПОСОБЛЕН К ВЫЖИВАНИЮ В УСЛОВИЯХ НЕОПРЕДЕЛЕННОСТИ

Минимально жизнеспособный продукт

Дальше мы много раз будем повторять понятие «минимально жизнеспособный продукт» или «минимально готовый продукт». Так обозначают тот продукт, который команда представляет Заказчику и всем заинтересованным лицам, включая клиентов и потребителей в конце каждого спринта. И это непременное условие в SCRUM-методологии. Команда не просто входит в процесс производства продукта, но и выдает в равные промежутки времени минимально жизнеспособный продукт, чтобы протестировать гипотезу, дать возможность всем увидеть то, что, собственно, производит команда, протестировать это, собрать все замечания и пожелания. Затем в начале следующего спринта происходит корректировка продукта.

Это существенное отличие Agile от проектного менеджмента, где продукт показывают в конце всего процесса. И если даже устраиваются промежуточные встречи с Заказчиком, то скорее для того, чтобы сверить, соответствует ли работа, сроки и бюджет ранее установленным в документах параметрам.

Минимально готовый продукт называется так еще и потому, что его уже можно представить рынку, то есть продать. Представим, что мы создаем сайт и хотим, чтобы он был суперсовременным, с личным кабинетом пользователей, видеовставками, обратной связью и тому подобным. Наше техническое задание расписано на несколько страниц. Если мы работаем в Agile, то уже после первого же спринта у нас есть one page – одна страница со всеми выходными данными и торговым предложением потребителям. То есть сайт начинает работать и привлекать клиентов после первого же спринта. И так каждый новый промежуток времени наш сайт дополнятся новыми опциями, продолжая все время работать и расширять клиентскую базу компании. Это, конечно, простой пример.

В Agile вне IT-отрасли сложно выделить минимально готовый продукт. Иногда на это уходят часы и дни командной работы. В Agile в науке мы принимали за такой продукт научную гипотезу. Марина Алекс, интервью с которой будет дальше, разрабатывая Agile для продаж, и вовсе отказалась от этого требования разработчиков методологии. Так как заменила минимально готовый продукт финансовым планом на спринт. И все-таки лучше его поискать.

Минимально жизнеспособный продукт обладает определенными качествами. Он должен быть:

• функциональным;

• надежным;

• готовым к употреблению.

Минимально жизнеспособный продукт в Agile не является прототипом продукта. Потому что прототип мы можем нарисовать в презентации, снять по нему видео, сделать макет, но мы не можем продать его потребителю. В этом отличие этих двух понятий.

Главное назначение минимально готового продукта в Agile:

• убедиться, что идея, над которой работает команда, нужна потенциальным потребителям;

• составить свое представление о целевой аудитории продукта, возможно, внести какие-то изменения в свое первоначальное представление об этом;

• собрать и проанализировать обратную связь, составить протокол необходимых изменений, внести эти изменения в бэклог следующего спринта;

• получить импульс для размышлений о правильности идеи и ее исполнения;

• повысить мотивацию команды, увидевшей реакцию потребителей и Заказчика, даже если она критическая, но все равно доброжелательная, поскольку все заинтересованные лица всегда благодарны за то, что их спросили о продукте по ходу дела, а не в конце, когда уже ничего нельзя изменить;

• начать монетизировать свои разработки;

• сократить сроки и бюджет производства конечного продукта за счет раннего распознавания положительных и отрицательных качеств продукта.

* * *

Вернемся к тем понятиям, о которых вскользь упоминалось во вступлении к книге, для выравнивания информационного поля. Теперь – некоторые интерпретации и упорядочение понятий методологии.

Роли

Мы не включаем Заказчика в список традиционных ролей в SCRUM, поскольку он действует за рамками процесса. Это может быть руководитель направления, который инициирует проект и принимает решение реализовать этот проект посредством Agile. Иногда роль Заказчика выполняет первое лицо компании. Это зависит от того, какой уровень задачи стоит перед командами, какого размера сам бизнес, какой уровень корпоративной культуры в компании и принятый в коллективе стиль руководства.

Заказчик присутствует на обзоре спринта (релизе), когда команда демонстрирует минимально готовый продукт, созданный за период спринта. Далее на конкретных примерах из бизнеса мы будем говорить о том, чем чревато нарушение этого правила.

Итак, в SCRUM действуют три основные роли.

1. Владелец продукта (Product Owner).

Предпочтительно, чтобы человек, занявший эту роль, прекрасно разбирался в бизнесе, в котором работают команды, и знал запросы потенциальных клиентов. Это важно, так как он составляет бэклог продукта – описывая весь объем работы на проект – и отвечает за результат деятельности команды. Если у участников возникает потребность изменить что-либо в бэклоге продукта, то делается это только через Владельца продукта.

Он дает команде понятные требования для работы, разъясняет сложные моменты, уточняет у Заказчика ответы на вопросы, возникшие у команды, организует взаимодействие с различными подразделениями компании, если это требуется команде. Не являясь руководителем команды ни в коей мере, Владелец продукта участвует в тестировании результата работы перед обзором спринта и демонстрацией продукта перед Заказчиком и потребителями. Основная задача Владельца продукта, несмотря на большую ответственность за производственную часть работы, – постоянно поддерживать у участников видение и понимание цели.

Владелец продукта осуществляет свою деятельность для команды, но вне команды. Он не вмешивается во внутренние процессы, происходящие во время работы над проектом, но отвечает на запросы участников, направленные вовне: к другим подразделениям, подрядчикам, поставщикам, аналитикам.

Для Заказчика Владелец продукта играет очень важную роль, поскольку поддерживает в нем уверенность, что все действия команды соответствуют первоначальному замыслу и видению. Владелец продукта может ответить на любой вопрос о том, как движется работа, и в любое время, когда в этом появляется потребность, не ожидая окончания спринта.

Естественно, что для реализации всех требований к Владельцу продукта, человек, который получит эту роль, должен ко всему прочему быть хорошим коммуникатором. Правда, в Agile все участники учатся говорить, даже если не очень отличались разговорчивостью на собраниях и конференциях.

2. SCRUM-мастер.

Деятельность этой роли, напротив, направлена внутрь команды. Все, что делает SCRUM-мастер, способствует тому, чтобы команда соблюдала все ритуалы методологии, ритм работы и поддерживала деловую, творческую атмосферу в коллективе. При этом у SCRUM-мастера, так же, как и у Владельца продукта, нет власти самостоятельно решать какие-то вопросы. Его роль – служение команде.

SCRUM-мастер работает в трех направлениях: проводит мероприятия в четком соответствии с правилами, поддерживает визуализацию процессов на SCRUM-доске, сопровождает преобразование команды в единое целое. От его профессионализма зависит адекватность распределения равных по объему и сложности задач между участниками. Но при этом не принимает выполненную работу и не тестирует ее, как у нас случилось в одном консалтинговом проекте.

Просто со стороны может показаться, что человек, который распределяет задачи, спрашивает, что сделано и что намечено в работу, должен и собирать результаты. Но это не так. Категорически SCRUM-мастер этим не занимается. Но это достаточно частая ошибка. Происходит она по причине, что в Agile мало того, чтобы руководитель отдал свою ответственность команде, нужно, чтобы команда приняла ее и присвоила, отказавшись от старой привычки быть лишь ни за что не отвечающими винтиками в производственном процессе. Agile кардинально меняет эту парадигму и создает новые привычки, при которых личная ответственность становится коллективной ответственностью команды, как единой роли в SCRUM-методологии.

3. Команда.

Этой роли будет посвящена вся пятая глава. Настолько важно то, кто войдет в команду, как распределятся роли, как будет происходить взаимодействие между всеми участниками, что это выделено в отдельную главу. Недостаточно только подобрать профессионалов, способных решить задачу в полном объеме от начала работы до выхода продукта на рынок, это еще должна быть команда, действующая как единый организм. Недаром основоположники Agile объединили команду в одну роль. Все процессы, которые происходят по пути к реализации цели, решаются в команде сообща, большинством голосов утверждаются изменения, коллективно тестируются гипотезы и готовятся демонстрационные версии минимально готового продукта. И, конечно, совместно празднуется победа, что сильно повышает мотивацию каждого члена команды.

Документы

Когда мы рассказываем на своих тренингах о том, что такое бэклог спринта и продукта, мы представляем своим слушателям большого слона, которого надо съесть по кусочкам. Слон – это цель на весь проект, а спринты – это те части, которые надо хорошо приготовить и подавать к столу по одному. Этот образ дает хорошее представление о том, как разделить задачу на составляющие и не потерять качество и цель конечного продукта.

БЭКЛОГ ПРОДУКТА

В соответствии со своей ролью, Владелец продукта – единственный, кто отвечает за конечный продукт, поэтому на нем лежит ответственность составить бэклог продукта таким образом, чтобы предусмотреть все аспекты работы над продуктом. От полноты этого документа во многом зависит успех команды.

При этом бэклог продукта составляется таким образом, чтобы задачи, которые он содержит, были понятны членам команды, выполнимы и оцифрованы. Здесь как раз время вспомнить о том, что до того, как создавать бэклог продукта, участники проекта уже составили канвас продукта, определили все его аспекты. Таким образом, у Владельца продукта уже есть все наработки, чтобы выполнить свою работу качественно.

БЭКЛОГ СПРИНТА

После того как Владелец продукта, знающий бизнес и все процессы производства продукта, составил бэклог продукта, команда совместно со всеми другими ролями создает бэклог спринта.

В начале пути, прежде чем обсуждать задачи и присваивать их себе, члены команды принимают решение, какой продолжительности будут спринты в течение всего проекта. Изначально выбранная командой длительность спринтов на протяжении всего проекта остается неизменной. В расчете учитывается не только то, сможет ли команда в определенный период выдать минимально жизнеспособный продукт, но и то, насколько часто Заказчик, потребители и подрядчики смогут участвовать в демонстрации результата в конце спринта.

На практике проверено, что спринт не должен быть больше, чем четыре недели, так как в противном случае он превратится в обычную процессную деятельность. То есть исчезнет скорость и напряжение, а следом и мотивация. В нашей консультационной работе оптимальными стали две недели спринта. Как только заканчивается один спринт, сразу же создается следующий.

В исключительном случае, а такой может произойти в любом проекте, Владелец продукта может отменить или перенести спринт из соображений целесообразности.

ДИАГРАММА BURNDOWN

В Agile вне IT-отрасли этот документ может использоваться факультативно, но не обязательно. Мне не приходилось встречать этот документ в своей консалтинговой работе. В этой диаграмме отражается динамика работы команды в течение спринта, чтобы сориентировать участников, какой объем работы уже сделан, что остается до окончания спринта и успевает ли команда создать минимально готовый продукт.

Мероприятия

ПЛАНИРОВАНИЕ СПРИНТА

Теперь наступил момент планирования спринта: команда обсуждает, что ей необходимо взять из бэклога продукта, чтобы создать промежуточный продукт и представить его заинтересованным сторонам, то есть создается цель спринта. Для того чтобы каждый человек четко знал, какой объем работы будет выполнять, он выбирает из бэклога продукта необходимые опции и присваивает им свое имя.

ЕЖЕДНЕВНЫЙ СТЕНДАП

Каждый день в одно и то же время, изначально выбранное командой, около SCRUM-доски проходит стендап (в методологии SWAY, о которой я буду говорить позднее, это мероприятие называется «дейли», но его суть от этого не меняется) – 15-минутная встреча всех без исключения членов команды для синхронизации действий. В этом моменте важно напомнить, что у доски говорит каждый член команды, никто не молчит и не отвечает уклончиво. На стендапе обсуждается три вопроса: что было сделано вчера, что делается сегодня и что планируется делать завтра. Все более серьезные разговоры и обсуждения SCRUM-мастер выносит за рамки стендапа.

Мне приходилось встречать мнение о том, что методология SCRUM настолько жесткая, что люди долго не выдерживают работать в таком ритме, поэтому длительность жизни команды не превышает трех месяцев. Однако в своей консалтинговой практике я не встречала такого ограничения. Напротив, появляется потребность в таких встречах и сверке деятельности и настроений, эти встречи становятся своеобразным тимбилдингом для всех участников. Это как раз о том, что, прежде чем внедрять методологию SCRUM, необходимо осознать и принять ценности и принципы Манифеста Agile. Остальное – дело техники.

И тогда понятно, что стендап – это не отчет, а сонастройка действий команды. И все, что происходит внутри команды, делается на основе доверия и эмпатии. Иначе у методологии нет души. И тогда это действительно не Agile, а муштра.

ОБЗОР СПРИНТА (РЕЛИЗ)

Как раз на этом мероприятии происходит встреча Заказчика и потребителей с командой проекта. Это демонстрация того, что было сделано за спринт, тестирование минимально жизнеспособного продукта всеми заинтересованными сторонами и определение его сильных и слабых сторон. Желательно, чтобы итогом обзора стала возможность реализации сделанного продукта, чтобы команда ощутила, что она в скором времени уже способна создавать прибыль для бизнеса. Но это, конечно, идеальный вариант, к которому надо стремиться.

Если мы вернемся к образу слона, то в момент обзора спринта мы созываем гостей, чтобы они попробовали, хорошо ли приготовлен наш кусочек, и высказали свои замечания, которые будут учтены в следующем спринте.

После обзора и принятия всех возможных замечаний, команда намечает следующий спринт, корректируя задачи и формируя новый минимально готовый продукт.

РЕТРОСПЕКТИВА

Это один из элементов самоуправляемости команды. Ретроспективы проводятся один раз в полтора-два месяца. Их цель заключается в том, чтобы обсудить все вопросы, поделиться мнениями, определить, что из прошлого периода можно взять в будущий. Для обсуждения в ретроспективе выделяются четыре основные области: что было хорошо в прошедшем спринте, минусы этого же периода, идеи, которые возникали в промежутке между спринтами, но не были припаркованы в работе над проектом, и как итог – план изменений или дальнейших действий. Возможно, достигаются новые договоренности, если прежние уже изжили себя.

Фасилитирует ретроспективу SCRUM-мастер. Его задача направлять дискуссию и следить за тем, чтобы высказывались как можно больше участников.

АРТЕФАКТ – SCRUM-ДОСКА

SCRUM-доска содержит всю информацию по проекту в режиме реального времени. Она живая, подвижная, одушевленная. Обычно она разделена на три колонки, иногда, если того требует сложность проекта, появляется четвертая плоскость.

Первая колонка – «бэклог спринта» – это персонифицированные задачи на спринт. При создании этого бэклога члены команды уже разбирают их себе, при этом присваивая задаче свое имя. В процессе работы карточки в этой плоскости могут меняться. Какие-то задачи дробятся на более мелкие или перепоручаются кому-то другому. Как я уже говорила, доска живая.

Вторая колонка – «в работе» – это перенесенные из бэклога спринта задачи, которые выполняют члены команды в данный момент. Буквально в течение двух-трех дней, иначе задачу надо разделить на более мелкую, чтобы участник не зависал на ней, а двигался вперед быстрыми темпами. За этим следит SCRUM-мастер.

Третья колонка – «сделано» – это готовые к демонстрации Заказчику и потребителям задачи, выполняемые участниками по ходу спринта. Из этих задач формируется минимально готовый продукт. Эта колонка дает возможность команде видеть, успевает ли она за спринт выполнить весь запланированный объем и подготовиться к демонстрации. Такая визуализация процессов дает возможность ускорить темп работы. В конце спринта все задачи из бэклога спринта переходят сюда.

Четвертая колонка – «на проверке» – иногда появляется, когда сделанные участниками части работы надо тестировать прежде, чем перенести их в колонку «сделано».

Раньше мы всегда говорили о том, что для наглядности процессов SCRUM-доска должна быть реальной, а не виртуальной. Корни этого лежат в особенностях мозга человека, о которых мы будем говорить в последней главе этой книги. Если участник своей рукой переместил свою карточку со сделанным заданием, значит, он испытывает больше гордости за свой труд, и таким образом повышается его мотивация. Но сейчас стало понятно, что актуальным стал перенос доски в сеть в связи с пандемией и всеми сопровождающими ее ограничениями. И это нормально, мы все привыкаем жить в сети, и понятно, что переносим в нее все нужное нам для движения к цели.

Целеполагание

Один из самых важных моментов в Agile – постановка цели, оцифровка результатов и пошаговый план реализации задуманного, который и ложится в основу бэклога продукта. Из всего вышесказанного мы отлично знаем, чем чреваты ошибки в составлении этого документа SCRUM, и куда может завести команду недостаточность данных. Что-то в процессе целеполагания мы берем из старой жесткой модели управления, что-то делаем совсем по-новому. Об этом говорится в интервью с Валентиной Коричиной, моей коллегой по бывшему корпоративному опыту работы, отличным стратегом, опытным «эйджалистом».