Изменения

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

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

Первое - — роли и их разделение. * ''Product Owner '' отвечает за продукт, а ''SCRUM Master - '' — отвечает за процесс в команде. И это бьется очень четко и всеобъемлюще. * PO - — продукт целиком, его интересует общая скорость и другие характеристики. Ответственность включает ROI и экономические составляющие, включая выход и стоимость команды. Но внутрь команды он не смотри, для него команда - — целиком, в том числе с точки зрения стоимости.* SM - — ответственность за процесс, внутренняя (coach) и внешняя (коммуникации с внешними людьми). Именно он представляет реальный вклад сотрудников команды, смотрит кому и где надо помочь и это организует. Не административно, а предлагая, но в целом - — его scope. В том числе - — может организовывать привлечение экспертов, если это повысит производительность - — согласовав с PO, так как стоимость команды тоже возрастет.

* Новые члены - — с учетом мнения команды, интервью все или хотя бы один (это уже после 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 командами на одном продукте с общим кодом и нескольких продуктов для одной команды - — вполне рабочие.

* В презентации есть интересные ссылки на исследования психологов - — как оценивает команда одну спецификацию в зависимости от разных факторов. Например, от числа листов, полученного увеличением размера шрифта (коэффициент 1.5) или предварительно высказанной оценки стороннего эксперта. Первичку, кто интересуется, думаю, можно найти - — ссылка была на ''Simula research lab'', ''Еstimation ...'' …, ''Oslo 2006''.* "Не «Не бывает низкой скорости, бывают нереалистичные планы"планы». Потому что скорость сама - — не поднимется, над этим надо работать.* Что мотивирует (это известно, но, тем не менее): ** Autonomy = свобода, самоопределение (да. в рамках, но рамки - — они везде есть)

* Водопад как последовательные выстрелы из лука: облако заказа, Req стреляет - — получает требования, Designer - — получает проект, разработчики - — результат. Все как-то промахиваются, естественно - — наводят на одно, получают другое. Ну и Заказчик реально хотел не то, что заказал.

[[CategoryКатегория:AgileDays-2011]]