2011-03-03: Тренинг Книберга - день второй

Текущая версия на 23:24, 28 декабря 2016

Итак, сегодня был второй день тренинга Генриха Книберга. Тоже очень полезный. Фиксирую впечатления тезисами.

Оценка в SP.

• Почему перешли на оценку в SP (story point)? Это — опыт. При такой оценке команда быстрее приходит к согласию, чем при оценке в идеальных днях/часах. И легче калибровать разные команды, передавать им подходы к оценке. А точность — не уменьшается. Для рефлексии о причинах падения скорости SP обычно хватает, если какая-то одна-две задачи несоразмерно выросли.
• Как первоначально получают оценку в SP? На начальной оценке release PBL берут простую и понятную всем историю, которую оценивают, например, в 3 SP или 5 SP. Получается начальный масштаб, от которого дальше пляшут. Когда переходят к оценке спринта и оценивают task, на которые поделили user story, то оценка user story задает некоторый масштаб, пока команды не привыкнут. Но при этом укладываться и подгонять не обязательно, более того у многих есть практики не показывать на планировании спринта оценки user story, во всяком случае сначала — чтобы они не влияли на оценки отдельных задач. Но в случае расхождений — разбираться, вопрос в подробностях задачи или более систематично что-то поплыло.
• Новичкам для калибровки оценок полезно посмотреть оценки предыдущих спринтов до первого планирования. И, опять-таки, оценить задачу как «похожую на ту» легче, чем прикинуть часы.

О SM

• Если кто не разделяет цели — гнать из команды. Движение должно быть сонаправленным. Размер шага (скорость) — не так важны, это тренируется, если человек разделяет цели. Ответственность за фиксацию таких проблем — на SM.
• Про SM, не смотря на много «управляющих» функций по процессу, явный акцент Книберга на самовыдвижении и отсутствии формальной власти. И SM создает условия для самоорганизации, а не управляет. Основне средство — вопрос «А что вы думаете о …» (а не «Давайте решим такую проблему…»).
• Если есть персональные проблемы, например, кто-то систематически не соблюдает стандарт кодирования и на review это вылезает, то задача SM — это выявить. Хотя на ретро об этом могут не говорить. Поговорить до ретро с членами команды, а дальше по обстановки — можно индивидуально, можно на ретро. То, что это в компетенции SM — «по умолчанию».

Процесс в целом

• Практика, когда задачу заранее готовят к выполнению, например, постановка силами той же команды или согласование с заказчиком — распространенная. И хорошая техника — вместе с DoD сделать Definition of Ready — check list, что должно быть у задачи, чтобы ее можно было запускать в спринт. Пример DoR: есть bug, grade S/M/L, есть acceptante test.
• Еще раз сформулировали — кросс-функциональная команда — не значит, что каждый заменяет каждого. Но значит, что нет критичного для процесса человека, и в целом компетенции сбалансированы с потоком задач с учетом отклонений. Техника: матрица деятельность (DB/Java/Design/Test, например) — сотрудник, на пересечении — оценка: пусто/точка/звездочка. Должно быть минимум две звездочки и несколько точек, если нет, то включаем в цели их прокачку у конкретных участников в ходе спринта за счет выполнения задач (например).
• Project Manager в смысле CMMI поделен в SCRUM примерно так:
  • release plan — PO
  • build team — SM
  • архитектура — команда
  • раздача задач — task board
  • набор персонала — за рамками команды
• Надо ограничивать количество задач, находящихся в работе. На это есть мат.модель (правда тут надо смотреть, насколько плюшевая, я готов рассказать подробности). Кратко так. Если дело проходит через несколько стадий, и на каждой имеет некоторую неопределенную трудоемкость (например, от 1 до 3), то с некоторого числа дел в работе мощность выходит на плато, но чем меньше дел в работе — тем быстрее новое дело, вкинутое на вход, появится на выходе. И это — без узкого горла. Если стадий 5, то в работе оптимально 7 начатых дел. Практически это мощное ограничение, особенно с учетом дорогого переключения контекста, и надо этим пользоваться, и того, что люди не могут одновременно держать много целей.
• Working smart more important than working hard. Не рубите деревья бензопилой, а пилите, и вообще не рубите деревья молотком. Используя SCRUM смотрите, насколько подходит.

Две команды на одном продукте.

• Итерации — рекомендуется синхронно, и общий релиз. Иначе сложно с кодом.
• Задачи на итерации делить можно на общей сессии: все задачи висят на доске, команды у них и высказывают желания, а PO — отдает. Как вариант — в каждой команде свой «локальный PO», который берет задачи от общего, так тоже можно.

Разные техники.

• Если у команды период активной поддержки, то можно резервировать на это некоторую долю времени при планировании спринта, а можно — вставлять в SBL задачи типа «фиксируем 10 самых критичных багов».
• Если возник стресс и запарка — найдите силу воли сделать паузу и проанализировать причины.
• Любопытный пример. Kanban of SCRUM, на 60 человек. Большая доска, слева область для подготовки, потом область выполнения — разбита на 4 части для отдельных scrum-команд — задача уходит на их доску, а после спринта — возвращается на общую. Впечатляет. И, возможно, на проектах с несколькими командами типа ГПБ — может быть полезным.
• Где-то всплыл сайт http://userstories.com - всякие тулы и прочее для поддержки. Может, кому интересно — даю ссылку.

Повсеместная работа с карточками меня впечатлила. Техника ведения трека через карточки, которые сначала есть в PBL, потом помещаются на мини-доску Todo/Doing/Done, а потом — в сделанное в рамках спринта может быть полезна на собраниях с повесткой дня. Я, во всяком случае, буду пробовать — если не забуду. Приоритеты — тоже через них. И bring down на планировании — user story на доске, пишем task и вешаем.

Общение с другими.

• Было много участников, успешно применяющих scrum и приехавших. чтобы улучшить опыт. Сам scrum — разный, в том числе в варианте, когда scrum master близок к менеджеру. У других — упор на PO, есть те, у кого он в команде.
• Была практика, когда один SM ведет две команды, и это — его полная загрузка, а задача его — именно наладить процесс. При этом он знает разряды сотрудников и следит за адекватным вкладу разрядом, говоря о проблемах индивидуально. На ретро или эскалируя.
• Планирование 2-недельной итерации вместе с декомпозицией story на task — полдня, 4 часа.
• SCRUM позволяет делать качественные вещи, вопрос в применяемых практиках. Например, может быть жесткое требование, что по каждой user story — пишем acceptant test (пишет или утверждает PO), который развертывают в test case. И все это делает команда.
• Есть практика тех.лидов, тоже поделенных на 2 команды и занимающихся техническими архитектурными вопросами.
• Понимание терминов — разное. Не все считают, что DoD — это общее для всех задач, некоторые используют его скорее как HowToDemo или Acceptante Test. Это надо иметь ввиду, когда общаетесь.

PO в команде, как это у нас. Не отрицается, что это возможно. И ряд участников рассказывали о положительном опыте, они тоже так делают. Почему сам Генрих не делает, мне понятно — у него основной профиль — работа с проблемными проектами, бизнес-часть там разная, соответственно, он ей не занимается, а обеспечивает процесс за счет SM. Поэтому ничего определенного на мой вопрос не сказал. Что касается моих собственных мыслей об этом (с учетом тренинга и прочего), то, думаю, для нас нынешний вариант неизбежен. Потому что заказчик хочет PO у нас, в том числе согласовывающего позиции разных stakeholder’ов с его стороны. А для этого PO должен разбираться в архитектуре и уметь давать оценки, для чего, в общем-то быть в команде. И естественно им оказывается самый сильный член команды. Теоретически это не мешает появиться еще сильному SM, и команде будет только лучше, но практически в этом случае фирма просто сделает две команды — потому что дефицит руководителей проявляется наиболее отчетливо. Однако все это не мешает работе в SM для их роста, как будущих PO, управляющих процессом, или просто сосредоточенных на тех аспектах, на которые PO не хватает.

От тренинга остались 2 книги, напечатанные и на пружинке.

• SCRUM и XP из окопов с автографом, так что только на почитать.
• SCRUM и Kanban: выжимаем максимум.

И авторский checklist по SCRUMу с градацией bottom line/core/recommended/scaling/positive indicators, он есть на его сайте.

Засим — все.