Коллеги попросили меня написать им методичку по внедрению аджайла в проектное управление. Честно говоря, они попросили ещё методичку по канбану. На что я им отправил PDF-дамп описания канбана из компании unusual-concepts. Однако по скраму методичку мне пришлось писать с нуля, т.к. есть проблемы в текущем скрам-гайде. Наиболее острая из них - там не описаны принципы, хотя в скраме они есть! Полагаю, что методичку придётся допиливать, поэтому - to be continued. Последнее обновление: 2017.11.27

Шаг 0. Скрам?

Данный метод проектного управления подходит для ситуаций, когда работа носит эвристический характер. Последнее время такое бывает сплошь и рядом, т.к. внешние условия постоянно меняются, и даже вполне очевидные проекты требуют творческого подхода в командной работе. Верный признак, что скрам нужен, это когда наиболее продуктивное время исполнителей приходится на утренний/вечерний душ, завтрак, фитнес-зал, разговоры с коллегами, бессмысленное хождение по коридору взад-вперёд, и прочие “непроизводительные” затраты времени. Ещё одним верным признаком является попытка заранее запланировать побольше запасов времени, чтобы хоть как-то компенсировать изначальную неопределённость. Будьте готовы к тому, что с точки зрения целесообразности использования ресурсов, скрам выглядит абсурдно.

В том случае, если:

Трезво оцените ситуацию, и решите - нужен скрам или нет?

Шаг 1. Бизнес-цель

Вся проектная команда должна чувствовать сопричастность к происходящему и важность общего дела для бизнеса (компании). Для этого у всех членов команды в голове всегда должна быть конечная цель, кратко и ёмко в одно предложение. Цель должна отвечать не только на вопрос “Что мы хотим получить в конечном итоге?”. Цель обязательно должна отвечать на вопрос “В чём важность для бизнеса?” Если это проект, то формулировка цели проекта.

Напечатать цель крупными буквами на листе A3-A2 и повесить на стену.

Шаг 2. Лидер (владелец продукта)

Должен быть один человек, кому действительно нужен результат: владелец продукта (или владелец результата). Основные качества - видение результата и готовность принимать смелые ответственные решения по приоритетам. Владелец результата буквально означает - человек, который будет пользоваться результатом, т.е. использовать в своей ежедневной работе, или серийно выпускать, продавать, воспроизводить, и т.п. В идеале, таким лидером должен быть представитель клиента (заказчика), который точно знает в чём заключается потребность или проблема, которую мы пытаемся решить, а также её контекст.

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

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

Выбрать человека на роль лидера (владельца продукта), наделить его ответственностью за бизнес-результат и дать свободу принятия решений.

Шаг 3. Команда

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

  1. Выписываем по вертикали (строки) все необходимые навыки и умения, которые нужны для достижения бизнес-цели.
  2. Выписываем по горизонтали (колонки) имена всех потенциальных членов команды. В идеале следует привлекать только тех, кто искренне заинтересовался бизнес-целью.
  3. Проставляем всей команде степень владения навыками и умениями с помощью звёзды (могу учить других), плюса (могу делать работу) и восклицательного знака (не умею, но хочу научиться). Пустая клетка означает - не умею и не интересно.

Важно понять разницу между специализацией и профессионализмом. Специалист - человек, который обладает навыками, умениями и экспертизой, а значит может делать определённый тип работ (активность). Профессионал - человек, который ответственно относится к своему делу, и готов отвечать рублём (головой?) за результат. Поэтому в эту матрицу нельзя включать зоны ответственности и какие-либо части результата. Каждый является специалистом по одной или нескольким сферам деятельности, но ответственность должна быть общая, чтобы избежать проблемы лебедя, рака и щуки.

Тасуем людей (убираем/добавляем), пока не будет найден баланс между численностью команды и незаменимостью отдельных членов (bus factor = сколько членов команды должен сбить автобус, чтоб работа встала колом). Просим команду критично отнестись к оценкам друг-друга. Выделяем риски по специализациям:

По каждому риску придумываем, как его снизить. Возможны разные варианты: аутсорс (внешний, внутренний), срочное обучение, временное привлечение в команду специалиста извне, и др. Но при этом учитываем, что нет ничего эффективнее, чем full-time специалист с нужной специализацией.

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

Составить матрицу специализаций, сформировать автономную кросс-функциональную команду, проработать риски.

Шаг 4. Результат

На этом шаге надо визуализировать результат так, чтобы представить его в максимально общем и полном виде. Представьте себе результат в виде стены из 10-20 кирпичей. Если их больше 10, то это на самом деле уже много, и возможны варианты:

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

Во втором случае не надо обобщать. Проблема не в количестве, а в отсутствии качественного видения у владельца продукта. Лучше отложить шаг 3 и заняться поиском ответов на вопрос “Какую проблему мы пытаемся решить?”. Честно отвечая себе на этот вопрос мы выкинем кучу никому не нужной работы, которой так часто обрастают проекты на этапе разработки требований. И даже если проблема есть, то не всегда у неё есть потребитель, у которого она достаточно остро стоит. Поэтому также спрашиваем себя “Кто это купит и почему именно у нас?”. Иногда эти вопросы позволяют остановить никому не нужный проект на старте, когда мы ещё не успели выкинуть много времени и денег.

Каждый элемент результата должен представлять из себя какую-либо одну его часть, которая достаточно изолирована. Важно понять, что это не работа, которую надо выполнить, а именно то, что должно получиться в итоге её выполнения. Поскольку работа носит эвристический характер, оценить трудозатраты на получение результата практически невозможно. Поэтому следует оценить сложность достижения результата. Для этого каждый кирпичик оценивается в относительных функциональных единицах методом т.н. дельфийского оракула (planning poker).

Рисуем на бумажках цифры немного исправленного ряда Фибоначчи (0, 1, 2, 3, 5, 8, 13) и знак бесконечности. Выдаём каждому члену команды комплект таких бумажек для голосования, можно использовать специальные карты Planning/Scrum Poker. Командным соглашением выбираем самый маленький кирпичик и присваиваем ему сложность = 1. Затем просим владельца продукта поочерёдно называть кирпичики (по одному за раз), а команда при этом оценивает сложность получения результата с помощью бумажки.

Если оценки у разных членов команды сильно разнятся, то задаём вопросы тем, кто выбрал крайние значения “Почему так мало/много?”. После обсуждения голосование происходит повторно, и так до тех пор, пока разброс оценок не сузится до соседних значений (например 8 и 13). Если элемент оказался слишком большим (все выбрали бесконечность), то его следует разбить на части и оценить каждую отдельно. Полученная оценка сложности кирпичика вычисляется как среднее арифметическое между оценками всех членов команды.

Поскольку в команде у каждого, как правило, своя уникальная специализация, а оценить нужно именно результат, а не “свою” работу, то возникают сложности и вопросы “Как я могу оценить не свою работу?”. Здесь важно понять, что профессионал отвечает за результат, а не за выполнение работы. Поэтому каждый должен подумать о всей работе целиком, а не только о той, которую он умеет/будет делать. Ответ на этот вопрос должен быть таким: “Попробуй оценить настолько точно, насколько знаешь, и если оценки не совпадут, то послушай, что скажут другие члены команды”.

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

Визуализировать и оценить результат в виде 10-20 составляющих.

Шаг 5. Планирование

Невозможно предсказать трудозатраты на получение результата эвристической деятельности. Более того, зачастую сложно предсказать каким именно будет результат такой деятельности. Поэтому устойчивость по предсказуемости в таком проекте обеспечивается за счёт:

  1. Постоянной кросс-функциональной команды (бюджет);
  2. Наличия готового результата в каждой контрольной точке (время/объём).

Второй фактор обеспечивается через итерации (спринты), в ходе которых результат проекта, либо один из его кирпичиков создаются целиком от и до. В начале итерации мы задаём себе вопрос "Насколько исчерпывающе мы можем решить проблему клиента (или же закрыть потребность в кирпичике) к концу спринта?”. В конце итерации мы смотрим на полученный результат и принимаем ответственные решения.

Важно понять назначение спринта. Спринт нужен не для того, чтобы создать какую-то часть результата, хотя результат безусловно создаётся в ходе спринта. Спринт нужен для того, чтобы получить обратную связь в конце и принять решение о дальнейшей работе. Принятие управленческих решений относительно проекта нередко требует участия высшего руководства компании, каких-либо внешних/внутренних экспертов и возможно даже конечных пользователей (потребителей). Таким образом, мы планируем не результат, а обратную связь.

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

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

Чтобы ещё сильнее снизить риски выхода за рамки бюджета и срыва сроков, можно применить правильную сортировку бэклога. Для этого просим владельца продукта проставить всем кирпичикам бизнес-ценность в виде цифры, скажем, от 10 до 1000. Когда он будет думать, задаём ему вопросы аля "А почему здесь больше, чем тут?","Какими критериями оценки ты пользуешься?", "Мы действительно учли интересы инвестора/компании/клиента?", и т.д. В итоге половина элементов бэклога может и вовсе стать ненужной, потому что навряд ли владелец продукта задавал себе эти вопросы и честно отвечал на них. Для оставшихся элементов вычисляем приоритет через деление бизнес-ценности на сложность. Полученное отношение используем для сортировки. Конечно, из-за зависимостей между элементами, полученные приоритеты придётся корректировать, но это уже лучше чем было в начале.

Длина спринта выбирается владельцем продукта от 1 до 4 недель в зависимости от необходимой частоты обратной связи. Если на проект выделено 3-6 месяцев, то спринт должен быть длиной в 1 неделю. Если 9-12 месяцев, то можно позволить себе спринт длиной в 2 недели.

Сформировать плоский список всех элементов результата (бэклог) и выбрать длину спринта.

Шаг 6. Работа

После того, как получен ответ на вопрос “Насколько тщательно мы можем закрыть потребность клиента к концу спринта?”, команда совместно планирует реализацию взятого в работу кирпичика (или кирпичиков), которые в ходе такого планирования расписываются по отдельным работам, исполнителям и времени в рамках одного этого спринта. Следует также учесть решения с ретроспективного анализа, которые были приняты ранее (если они есть). Полученный план должен быть фрагментирован на работы не длиннее одного рабочего дня, чтобы ежедневные планёрки не превращались в бесполезный обмен статусами.

Важно понять, что время получения результата сокращается не за счёт более интенсивной работы, а за счёт выкидывания лишней, ненужной работы - той активности, которая не приносит ценности. Но этого не происходит, если команда не использует рэгби подход: все несут один мяч, а не каждый свой. Да, это неэффективно с точки зрения использования ресурсов, однако с точки зрения скорости движения к конечной цели в условиях неопределённости - это самый эффективный способ. Поэтому мы также должны ответить себе на вопрос “Зачем понадобился ещё один спринт?” или “Почему нельзя использовать то, что уже есть сейчас?” - из ответа на этот вопрос становится ясна цель спринта, которую следует зафиксировать и использовать в ходе спринта в качестве фокусирующего фактора.

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

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

В течение спринта команда должна собираться каждый день на 15 минут, чтобы обновить текущий план спринта, обменяться мнениями о ходе работ (успеваем или нет) и предпринять корректировки плана в случае необходимости. Время и место ежедневной планёрки должно быть постоянным, чтобы избавиться от сложностей согласования и координации. Если планёрка занимает больше 15-ти минут, значит есть проблемы излишнего углубления в детали, и вероятнее всего команда плохо общается по ходу работы (есть смысл обсудить это в конце спринта на ретроспективном анализе).

К концу спринта владелец продукта организует встречу с людьми, которые могут дать обратную связь и помочь принять управленческие решения относительно проекта. Как правило это топ-менеджмент компании, эксперты по предметной области, представители клиента и т.п. Для того, чтобы обратная связь была качественной, команда организует демонстрацию результата, который есть на текущий момент, а также текущее состояние проекта в бэклоге. Владелец продукта может попросить команду показать весь продукт целиком, либо какие-то отдельные части. Приглашённые люди могут попросить показать что-то конкретное. Любые корректировки в проекте, которые владелец продукта делает в процессе принятия решений при получении обратной связи, должны быть немедленно (желательно прямо на глазах у присутствующих) отражены в бэклоге. По фактически реализованным кирпичикам, владелец продукта, при необходимости, очень быстро может вычислить текущую скорость команды и дать прогноз по срокам. Максимальная длина этой встречи для недельного спринта - один час.

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

По результатам ретроспективного анализа команда должна принять решение о том, как изменится командная работа в следующем спринте. Есть смысл отметить, насколько эффективны решения прошлых ретроспектив, и если есть проблемы - то также их обсудить. Не следует думать, что всё и так хорошо - всегда есть, что улучшить. Также не следует принимать слишком много изменений за раз, т.к. есть риск что ни одно из них не будет выполняться. Принятые командой решения должны быть зафиксированы для того, чтобы никто не забывал о них. Помните - ретроспектива очень важна, так как это единственный (в таких условиях) способ повышения эффективности командной работы, а значит и снижения себестоимости. Максимальная длина встречи по ретроспективному анализу для недельного спринта - 45 мин.

Запустите и поддерживайте два цикла PDCA - спринт и ежедневная планёрка.

Шаг 7. Ретроспектива

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

По окончанию проекта проведите ретроспективный анализ проекта.

Ссылки