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

Материал из MaksWiki
Перейти к: навигация, поиск

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

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

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

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

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

  • Есть release plan, который в крупном, в feature или user story, и он предварительно, в крупном, оценен командой.
  • Поскольку есть оценка - то достижение результата в крупном, скорость реализации - контролируется.
  • Но спринт - тоже, естественно, оценивается. Оценка может совпасть или нет, по разным причинам. Может быть особенность задачи, а может быть ситуация, когда команда набрала опыт и научилась точнее оценивать. Во второй ситуации PO может понять о коррекции начальных планов и что-нибудь предпринять по этому поводу.

Продолжение следует...

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

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

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