Чеклист СкрамМастера
Переводчик: Кривицкий Алексей
От переводчика:
Не только в украинском сообществе аджалистов, но и в мировой группе дискуссий по Скраму вопросы типа: чем должен заниматься СкрамМастер? может ли он работать с несколькими проектами? может ли он совмещать свою роль с программированием или управлением продукта? поднимаются довольно часто.
Я решил перевести статью "A ScrumMaster's Checklist", опубликованную на сайте Danube, Майкла Джеймса (Michael James), так как по-моему мнению, она может помочь СкрамМастерам (начинающим и не только) разобраться в том, что же входит в сферу их обязанностей.
И так, далее я привожу мой непрофессиональный перевод первой части статьи. При наличии вдохновения продолжу позже... :)
"Адекватный СкрамМастер может работать с двумя или тремя командами одновременно. Если вы готовы ограничить вашу роль до организации митингов, напоминания тайм-боксов и разгребанию препятствий, которые члены ваших команд в явной форме репортят вам, вы можете справиться с вашей ролью, работая в part-time режиме. Команды, скорее всего, в этом случае будет превышать свою продуктивность в сравнении с тем, как они работали до перехода на Скрам, и в проектах не случится ничего катастрофического...
Но если вы сможете вообразить сверхпроизводительную команду - команду, которая в наикратчайшие сроки справляется с задачами, которые никому не под силу - подумайте о том, чтобы стать Великим СкрамМастером.
Мы рекомендуем одного выделенного СкрамМастера на команду (из семи человек), особенно на начальной фазе.
Для того, чтобы найти весь спектр работ, которыми стоит заниматься СкрамМастеру, попробуйте взглянуть на работу вашего Product Owner, вашей команды, на их инженерные практики и также на вашу компанию вне команды и проекта. Нельзя точно описать роли и задачи СкрамМастера, но я выписал вещи, которые на моём опыте СкрамМастеры по ошибке упускают из вида:
- Как поживает мой Product Owner?
Вы можете повысить эффективность работы вашего Product Owner’а, помогаю ему управлять Product Backlog и планом релиза. (Помните, что только Product Owner может приоритезировать беклог)
- Приоритезирован ли беклог в соответствии с последними пожеланиями Product Owner’а?
- Все ли требования и пожелания от всех заинтересованных в продукте сторон записаны в беклоге? Помните, что беклог обновляется постоянно.
- Управляемого ли размера беклог? Для поддержания управляемого количества элементов в беклоге, храните его элементы более гранулярными кверху, с более крупными (эпическими) элементами книзу. Зачастую непродуктивно детально анализировать беклог, делаю это далеко вниз от его верха. Требования будут часто изменяться во время обсуждений между разработчиками и заказчиками.
- Могут ли элементы беклога (особенно те, что ближе к верхушке) быть выражены как независимые, обсуждаемые, полезные, оцениваемые, мелкие и тестируемые истории?
- Объяснили ли вы вашему Product Owner суть технической задолженности и то, как её избегать? Одним из решений этой головоломки может быть добавление автоматизации тестов и рефакторинга в определение готовности элементов вашего беклога.
- Является ли беклог радиатором информации, который доступен и виден всем заинтересованным сторонам проекта?
- Если вы используете автоматические средства для управления беклогом, все ли знают, как ими эффективно и просто можно пользоваться? Средства автоматического управления беклогом могут стать информационными холодильниками (information refrigerators), если СкрамМастер не пытается превратить беклог в коллективный легкодоступный инструмент.
- Можете ли вы помочь коммуницировать беклог, раздавая распечатки?
- Можете ли вы помочь коммуницировать беклог, создавая большие видимые настенные диаграммы?
- Можете ли вы помочь вы вашему Product Owner'у организовать элементы беклога по релизам, адекватного размера?
- Все ли стороны проекта (включая команду) знают, отвечает ли план релиза текушему прогрессу проекта, основан ли он на текущей велосити (сумме оценок завершаемых историй за спринт)?
- Обновил ли Product Owner план релиза после последней демонстрации результатов спринта? Вы можете показать всем Product/Release Burndown Charts, которые рекомендует Mike Cohn, это может помочь выявить отставания о на ранних фазах."
