новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts

Системнаяоптимизация:прокачиваемкомпетенцииКоманды

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

Узкие специалисты — неоптимизированная система

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

Команда Разработки получает от Владельца Продукта задачи, каждая из которых требует применения трёх технологий: зелёной, синей и жёлтой. В Спринт Команда взяла три таких задачи, вот промежуточный результат:
Системная оптимизация: прокачиваем компетенции Команды

Что произошло за три дня? Вася и Петя продолжают работать над первой задачей, потому что в ней большой кусок работы по зелёной и синей технологиям. Коля же успел завершить часть своей работы в первой и второй задачах, и перешёл к третьей. Что он будет делать дальше? Скорее всего вытянет менее приоритетную задачу из Бэклога Продукта и займётся ею.
Системная оптимизация: прокачиваем компетенции Команды

Итог Спринта — большое количество незавершённой работы в прогрессе (WIP), готова только одна бизнес-задача.

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

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

Расширение компетенций позволяет решать задачи быстрее

Представим, парни прокачались и матрица компетенций стала выглядеть так:
Системная оптимизация: прокачиваем компетенции Команды

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

Итог Спринта — готовы две бизнес-задачи, нагрузка распределена более равномерно между членами Команды.

Важно, что мы не добавляли в Команду новые «ресурсы», что увеличивает стоимость Команды и количество линий коммуникации, а стали лишь более эффективно использовать существующие. Отсюда вывод: оптимизация системы в разработке инновационных продуктов тесно связана с необходимостью в обучении. Развитие новых компетенций — непрерывная активность в Скраме.

Нас вынуждают не учиться

Мы выросли в парадигме классического менеджмента, который предполагает, что люди должны максимально эксплуатировать свою текущую экспертизу. Просто откройте любой сервис по поиску работы и вы найдёте массу объявлений: Senior Java Developer, Middle .NET Developer и так далее.

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

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

Как сделать так, чтобы люди учились

Чтобы Команда Разработки обучалась и становилась гибче, ей нужно создать необходимые условия для обучения, изменить систему. Как сказал Крэйг Ларман, культура следует за структурой. Система большой организации ломает нас, мы перестаём активно учиться и осваивать новые навыки. Вывод: необходимо изменить структуру, чтобы активировать желание людей вновь обретать знания.

Помогает обучению Препятствует обучению
Продуктовая парадигма, фокус на долгосрочных целях Проектная парадигма, фокус на краткосрочных целях
Команда сидит вместе в одном помещении Распределённые команды
Команда выделена на 100% и работает только над Продуктом Участники Команды работают над несколькими проектами одновременно
Команда работает вместе, как минимум, год, а желательно два-три года Пул ресурсов, после окончания проекта люди распределяются по новым проектам
Меряем системную продуктивность (ROI, PnL, Cycle Time) Меряем индивидуальную продуктивность (количество закрытых задач, человеко-часы), что стимулирует людей эксплуатировать текущую экспертизу
Команда Разработки лояльна Владельцу Продукта и выделена под Продукт Команда Разработки остаётся в «матрице» и имеет функциональных менеджеров
Разработчики получают повышение зарплаты, если расширяют свои компетенции (T-Shaped люди) Разработчики получают повышение в зарплате, если растут узко в одной специальности
Кросс-функциональные и кросс-компонентные команды Компонентные команды

Хочется сделать несколько выводов. Итак, допустим, у вас несколько узких специалистов, и вы понимаете, что командой они могут работать более эффективно.

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

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

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

Ключевые мысли статьи

Илья Павличенко Аджайл Коуч Unusual-Concepts

Плюсануть
Поделиться
Отправить
Класснуть
Линкануть
Вотсапнуть
Запинить
Ещё по теме
Большие элементы в Бэклоге продукта (PBI) — причина неприятных сюрпризов и повышенной вариативности в Спринте. Чем больше задача, тем больше неизвестных. Большие PBI с трудом вмещаются в Спринт, а Владелец Продукта и стейкхолдеры могут долго не видеть результатов работы Скрам-команд. Недавно я начал работать с двумя фиче-командами. Владелец Продукта поместил наверх Бэклога одну огромную фичу, которая, по предварительной оценке, должна была занять команды на много Спринтов вперёд. На актуализации Бэклога Продукта присутствовали обе команды в полном составе (Multi-Team PBR). Мы декомпозировали, оценили и подготовили Бэклог Продукта к планированию за восемь шагов.

Шаг 1. Определить связь PBI с бизнес-целью

Мы обсудили, что связывает PBI с ближайшей бизнес-целью: с увеличением конверсии заявок с сайта (CR). Если ранее вы не определили бизнес-цель, то техника Impact Mapping и её вариация Extended Impact Mapping точно помогут на этом шаге.

Шаг 2. Описать PBI в формате «кто, что и зачем»

Я часто использую такой формат описания элементов Бэклога Продукта:
  • кто — пользовательский сегмент или персона;
  • что — краткое описание задачи;
  • зачем — бизнес-ценность или ценность для пользователя.
Владелец Продукта и команды обсудили это в открытой дискуссии. Я зафиксировал сказанное на флипчарте, чтобы к информации было легко вернуться.

Шаг 3. Разбить PBI в малых группах

Мы сформировали четыре группы по 3–5 человек и отправили их на рабочии станции в опенспейсе, где они в течение 20 минут декомпозировали PBI. Ребята использовали паттерны разбиения и другие техники, в частности, User Story Mapping. Если команды ещё не владеют навыками декомпозиции, нужно провести обучающий воркшоп. Восемь шагов для работы с большими элементами в Бэклоге Продукта (PBI)

Шаг 4. Представить варианты разбиения

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

Шаг 5. Провести финальную «склейку»

Я попросил Владельца Продукта и нескольких представителей команд сделать финальную «склейку» различных вариантов декомпозиции. Для этого мы принесли все флипчарты и повесили их на стену. Владелец Продукта выбирал наиболее удачные части и размещал их на финальной версии. Восемь шагов для работы с большими элементами в Бэклоге Продукта (PBI)

Шаг 6. Оценить и приоритезировали полученные фичи

К этому моменту гигантская фича была разбита на более мелкие элементы. Я попросил представителей из каждой команды провести экспресс-оценку при помощи «рубашечных размеров». Затем Владелец Продукта упорядочил все полученные фичи. В итоге мы получили 11 фич, самые приоритетные из которых должны были комфортно поместиться в двухнедельном Спринте. Восемь шагов для работы с большими элементами в Бэклоге Продукта (PBI)

Шаг 7. Прояснить приоритетные PBI

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

Шаг 8. Обсудить полученную ценность

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

Выводы

  • Предпочитайте использовать Multi-Team PBR, когда Бэклог Продукта актуализируют сразу несколько команд.
  • Всегда начинайте обсуждение PBI со связи с бизнес-целью.
  • Декомпозируйте элементы Бэклога Продукта с помощью паттернов разбиения и техники User Story Mapping.
  • Работайте в малых группах и форматах мирового кафе, трейдшоу или коктейльной вечеринки.
  • Для лучшего взаимодействия используйте бумагу, флипчарты, ножницы или стикеры.
 
Андрей Толмачев рассказывает, как разрешить взаимное недовольство Владельца Продукта и Команды Разработки.

Условия задачи

Представьте такую ситуацию. Вы — новый Скрам-мастер. Ваша Команда Разработки состоит из системного аналитика, двух разработчиков и двух специалистов по тестированию. Длина Спринта — две недели. Команда работает со сложной системой на старой платформе, поэтому для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты. В течение последнего Спринта Команда не успела сделать работу, взятую в Спринт, поэтому на Ретро Владелец Продукта допытывается, кто чем занимался в течение Спринта. Владелец Продукта жалуется, что Команда работает очень медленно. Члены Команды жалуются, что бизнес контролирует и микроменеджит их. Как разрешить взаимное недовольство Владельца Продукта и Команды Разработки? Давайте разбираться.

Что происходит

Для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты — это означает, что элемент будет готов к выпуску только через три Спринта. В таком случае истинная длина Спринта равна шести неделям — это больше, чем допускает Руководство по Скраму.
Максимальная продолжительность Спринта — один календарный месяц. При большем сроке планирования возможны изменения целей, увеличение сложности и рост рисков.
Руководство по Скраму Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:
  • возрастает риск сделать не то, что надо. Способность реагировать на изменения падает;
  • стабильность процесса падает, прогнозировать работу сложно. Например, тестирование выявляет дефекты через недели после разработки. Баги обнаруживаются поздно, поэтому объём «поддержки» будет меняться от Спринта к Спринту;
  • рабочий процесс перестаёт быть прозрачным.
По этим причинам Команда Разработки теряет доверие Владельца Продукта и стейкхолдеров, следовательно, давление возрастает и начинаются конфликты.

Решение

Скрам-мастер не может решить проблему самостоятельно, но может помочь своей Команде следующим образом:
  • объяснить описанную выше системную динамику и её вредные последствия. Скрам-команда должна понимать, что правило Скрама про Done Increment каждый Спринт — это естественное системное решение их проблемы;
  • помочь сформулировать или пересмотреть минимальный DoD, который может быть выполнен в течение Спринта и который обеспечит готовность Инкремента к релизу;
  • научить Команду Разработки правильно декомпозировать элементы Бэклога. Небольшие элементы в Бэклоге Продукта способствуют ранней поставке, оптимизации ценности Продукта и улучшению потока работы;
  • помочь договориться взять в следующий Спринт хотя бы один небольшой элемент Бэклога, но довести его до состояния Done;
  • визуализировать поток работы. Прозрачность — залог успеха;
  • устранить простои в работе. Для этого Скрам-мастер обучает Команду хорошим инженерным практикам, например, общему владению кодом, стимулирует развитие T-shaped или E-shaped людей в Команде, заключает командные соглашения;
  • объяснить Владельцу Продукта, что причина задержек — технический долг и убедить его выплатить.
Используйте Ретроспективу, чтобы найти лучшие решения по устранению препятствий. Помните, что эти решения — эксперименты, не факт, что они принесут ожидаемый эффект. Поэтому инспектируйте результаты прошлых решений и адаптируйте решения на следующих Ретроспективах.

Итоги

Готовый Инкремент в конце Спринта — это важнейшие правило Скрама, которое помогает избежать роста рисков, потери предсказуемости и гибкости. Описанные причинно-следственные связи полезно знать, чтобы понимать, почему Скрам требует соответствующий DoD, готовый к релизу Инкремент каждый Спринт. Следующие действия могут помочь в достижении этой цели:
  • декомпозиция работы на небольшие PBI;
  • визуализация потока работы в Спринте и поиск основных узких мест;
  • устранение «простоев» работы с помощью командных соглашений, хороших инженерных практик и развития T-shaped или Е-shaped людей;
  • планомерная ликвидация технического долга.
Комментарии
Любовь Мамаева, 25 января 2018

Спасибо! Мы переделаем и заменим эту картинку :)

Томас, 24 января 2018

Очень долго не мог понять картинку "Когда ребята прокачались". Думал что крестиками отмечено то, что не умеют.
Думаю лучше бы заменить их на галочки :)