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

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

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

Оценка в 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/recomended/scaling/positive indicators, он есть на его сайте.

Засим - все.


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

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

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