2011-03-02: Тренинг Книберга - день первый

Короткая ссылка: Kniberg1

Ссылки сюда (4) →

По горячим воспоминаниям хочу зафиксировать впечатления от тренинга Генриха Книберга, на первом дне которого я сегодня был. То, что я дальше напишу - отчасти материалы тренинга, а отчасти - услышано в беседах и ответах на вопросы.

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

Первое - роли и их разделение.

• Product Owner отвечает за продукт, а SCRUM Master - отвечает за процесс в команде. И это бьется очень четко и всеобъемлюще.
• PO - продукт целиком, его интересует общая скорость и другие характеристики. Ответственность включает ROI и экономические составляющие, включая выход и стоимость команды. Но внутрь команды он не смотри, для него команда - целиком, в том числе с точки зрения стоимости.
• SM - ответственность за процесс, внутренняя (coach) и внешняя (коммуникации с внешними людьми). Именно он представляет реальный вклад сотрудников команды, смотрит кому и где надо помочь и это организует. Не административно, а предлагая, но в целом - его scope. В том числе - может организовывать привлечение экспертов, если это повысит производительность - согласовав с PO, так как стоимость команды тоже возрастет.
• Деление PO-SM, помимо прочего, позволяет сделать явным поиск компромисса и вовлечь в процесс команду.
• Новые члены - с учетом мнения команды, интервью все или хотя бы один (это уже после HR, естественно).
• За технические решения отвечает команда. Она может инициировать включение в PBL задач, касающихся архитектуры, рефакторинга и прочего, высказывать мнение по приоритетам, которые следуют из техники реализации. Но принятие решения по приоритетам - за PO, он команду слушает, но решает сам.
• Еще есть менеджер, но он - один на много команд. Его задача - зарплата, контракт с сотрудником и подобные вещи. При этом для обратной связи о вкладе человека, его эффективности - он общается со SM. Плюс - может приходить на DSM и прочие мероприятия, беседовать и так далее - для получения нужной ему информации.
• Полной взаимозаменяемости нет, все люди - разные, с разным опытом и по-разному решают задачи. Разделение труда в команде есть или может быть. Жесткость - зависит от конкретного проекта. PO и/или SM могут стремиться к увеличению опыта членами команды за счет непрофильных задач или наоборот, пренебрегать рисками и ориентироваться на то, чтобы каждый брал профильные задачи. В зависимости от этого меняется стратегия оценки при планировании: могут брать оценку для профильного сотрудника, или среднюю, но команда должна договориться. Плюс, когда спринт не сбалансирован с опытом команды - она это учитывает при оценке.

Планирование и организация.

• Есть release plan (на 8-10 спринтов, 20-30 недель), который в крупном, в feature или user story, и он предварительно, в крупном, оценен командой.
• Поскольку есть оценка - то достижение результата в крупном, скорость реализации - контролируется.
• Но спринт - тоже, естественно, оценивается. Оценка может совпасть или нет, по разным причинам. Может быть особенность задачи, а может быть ситуация, когда команда набрала опыт и научилась точнее оценивать. Во второй ситуации PO может понять о коррекции начальных планов и что-нибудь предпринять по этому поводу.
• Исходные данные для формирования SBL итерации - не только PBL, но и цели: business, learning, risk, technical dependencies.
• Важно ограничивать число тем итерации, переключения контекста - дорого. В идеале - один основная тема и одна фоновая. От итерации к итерации темы можно менять.
• Есть мероприятие - Backlog workshop, проводится каждую неделю, PO + команда, оценивается текущее состояние, могут вноситься изменения.
• Окончательно перешли к оценке в попугаях (story point). В них меняют velocity на спринт, а при планировании из нее получают объем спринта в SP (с учетом фактических человеко-дней). Если есть фиксированные по времени мероприятия, то их надо вычесть из длительности спринта. SP оценки спринта и релиза, в общем случае - разные, коэффициент уточняется по прошедшим спринтам.

Обо всем понемногу.

• Варианты с 2-3 командами на одном продукте с общим кодом и нескольких продуктов для одной команды - вполне рабочие.
• Команды должны быть стабильны. В цифрах это означает устойчивое существование 3-6 месяцев.
• Новая команда по опыту выходит на плато скорости за 1-2 месяца.
• В презентации есть интересные ссылки на исследования психологов - как оценивает команда одну спецификацию в зависимости от разных факторов. Например, от числа листов, полученного увеличением размера шрифта (коэффициент 1.5) или предварительно высказанной оценки стороннего эксперта. Первичку, кто интересуется, думаю, можно найти - ссылка была на Simula research lab, Еstimation ..., Oslo 2006.
• "Не бывает низкой скорости, бывают нереалистичные планы". Потому что скорость сама - не поднимется, над этим надо работать.
• Что мотивирует (это известно, но, тем не менее):
  • Autonomy = свобода, самоопределение (да. в рамках, но рамки - они везде есть)
  • Mastery = передовые технологии
  • Purpose = понятные, осмысленные и ценные задачи, которые делаем

Метафоры и образы.

• Водопад как последовательные выстрелы из лука: облако заказа, Req стреляет - получает требования, Designer - получает проект, разработчики - результат. Все как-то промахиваются, естественно - наводят на одно, получают другое. Ну и Заказчик реально хотел не то, что заказал.
• Водопад как стрельба из пушки по движущейся мишени. Agile (SCRUM) как самонаводящаяся на цель ракета вместо этого.

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 23:32, 2 марта 2011 • нет комментариев