Для принятия “культуры Agile” важны понимание ролей и уход от должностей. В книге, о которой я писал раньше, Джеф Сазерленд рассказывает о своей первой Scrum-команде. Трансформация началась с того, что Джеф сказал им: “Порвите свои визитки”. Все практикующие “аджалисты” сходятся в том, что в Agile-методе важны роли – как наборы обязанностей, ответственностей и практик.
Для многих команд переход к Scrum (или к другой методологии из семейства Agile Software Development) начинается с определения того, кто и что делает, и за что отвечает. Понимание и обсуждение ролей всегда было частью моих публичных и командных тренингов. Сейчас я готовлю серию постов о создании Agile-тренинга для команды, и в результате опубликую готовый шаблон такого тренинга, поэтому расскажу об этом упражнении подробнее.
Самое простое, что приходит на ум для обсуждения ролей – сортировка терминов. В итоге механизм упражнения (или “игры”) предельно прост: участники делятся на группы по 2-4 человека и сортируют пачку терминов, которые относятся к ролям Scrum (в Scrum их 3, но вы можете ввести необходимое вам количество ролей). После работы в группах материал лучше закрепить общим обсуждением и уточнением, чтобы не было ошибок в понимании и разницы в трактовке. Я называют это “игра в бинго”. Мы берем одну роль, и каждая группа по очереди называет термин, который она отнесла к ней. Если остальные группы тоже отнесли термин к этой роли, они кричат “бинго”. Если нет – начинается обсуждение. Именно за обсуждения я и люблю это упражнение – в них мы проясняем понимание и углубляемся в аспекты той или иной практики, принципа или концепции. Даже если у вашей группы достаточно опыта и расхождений в сортировке терминов нет, просите участников привести практические примеры. Так вы можете проверить их знания более глубоко.
Но где взять термины? Долгое время я использовал набор фраз, которые составил вместе с моими коллегами-консультантами. Но они были не совсем понятны участникам. С тех пор, как я узнал про Agile Topic Cards, я заменил фразы карточками, и все стало работать во много раз лучше!
Как вы помните (или можете прочитать), Agile Topic Cards представляют собой карточки, на которых нарисованы Agile-термины. Зеленые – это практики, синие – принципы, а красные – концепции. Из 166 карточек можно выбрать любое количество, которое покажется вам необходимым для дискуссии.
Лично я выбрал следующие номера:
2 – Definition of Done
По моему мнению, это ответственность команды, хотя Scrum-мастер может отвечать за внедрение и поддержку этого внутреннего договора.
3 – Vision
9 – User Story
10 – Backlog
Имеется в виду Product/Project Backlog, за которые отвечает Владелец Продукта.
11 – Trade Offs
Для меня это – договоренности и компромиссы, которых Владелец Продукта достигает между бизнесом и командой, но всегда можно обсудить, как это понимаете вы.
14 – Team Performance (Velocity и другие)
25 – 1:1s
26 – Vertical Slice
Это – хитрая карточка. Прежде всего имеется в виду, что Владелец Продукта должен мыслить функциональностью (Features), а не задачами. Но также нужно, чтобы команда сфокусировалась на всех технических аспектах и делала функциональность целостной – от UI до глубин БД. Эта дискуссия может перекликаться с тем, о чем я писал в статье “Какого цвета ваш Бэклог”.
31 – Adaptive Planning
Это ответственность Владельца Продукта. Картинка показывает движение к Цели (эта Цель – звезда, нарисованная на карточке Vision(#3)).
40 – Code Review
41 – Slicing
42 – Test Driven Development
47 – KPI’s
54 – Timebox
60 – Team Development
Эта картинка означает модель развития команды Брюса Такмана: Forming-Storming-Norming-Performing.
63 – End to End testing
64 – Decision Making
По-моему, это Владелец Продукта решает, чего не делать, и говорит пожеланиям “да” или “нет”.
66 – Face to Face conversation
Эту картинку я трактую так: команда должна предпочитать прямое общение другим типам коммуникации.
68 – Pair Programming
69 – Autonomy
Здесь подразумевается, что cross-functional-команда должна иметь достаточно автономности.
71 – Collective Code Ownership
72 – Visualization
78 – Motivation
83 – Transparency
84 – Sprint Burndown
85 – Release Burnup
86 – Forecasts and Velocity
87 – Retrospective
89 – Team dependencies
94 – Relative Estimation
95 – Poker Planning
99 – Iterative & Incremental
100 – Backlog Grooming
Тут я обычно даю выбрать большинству. Иногда Владелец Продукта заинтересован в том, чтобы узнать от команды “цену” следующих элементов бэклога. Иногда Scrum-мастер заинтересован в том, чтобы команда получила качественные Элементы Бэклога (PBI) до начала планирования следующего спринта.
101 – Continious Deployment
102 – Continious Delivery
104 – Clean Code
107 – Daily StandUp
111 – Demo
Продемонстрировать результаты и получить обратную связь – это ответственность команды (!). Во всяком случае, в нормальных компаниях :).
114 – Risks
Риски, о которых заботится Владелец Продукта, или менеджер, который стоит за командой и Sсrum-мастером (на картинке основные категории рисков: Бизнес, Технологии, Социальный, Дедлайны).
117 – Outcome VS Output
Владелец Продукта занимается тем, что максимизирует результат (Outcome) – больше счастливых пользователей.
120 – Continious Integration
126 – Servant Leadership
128 – Refactoring
132 – Automated Test Checking
143 – Sprint Backlog
146 – Team Kick-off/Lift-off
Это означает запуск новых команд или запуск нового проекта в команде.
Итак, все, что нужно для этого упражнения – перемешать, не взбалтывать и разделить на три или более пачки в соответствии с ролями в вашем Agile-процессе. Приятного обсуждения!
В этом году, несмотря ни на что, состоялось много больших и малых мероприятий. Это отлично, так как делится знаниями и опытом просто необходимо для приобретения нового знания и опыта. Уверен, как в ближайшем будущем, так и в дальнейшем, будет еще немало поводов для публичных выступлений на которые вы, возможно, решитесь пойти рассказчиком.
На прошедшей недавно конференции Agile Base Camp Value Driven Development я затронул тему Agile требований.