Пример чек-листа для Скрам-мастеров
An Example Checklist for ScrumMasters (​ScrumMasterChecklist.org​)
Michael James (​MJ4Scrum@gmail.com​)Переведено 14 сентября 2007(обновлено 30 июня 2017)Фасилитатор со 100% загрузкой?

1Часть I — Как дела у моего Владельца продукта?

2Часть II — Как дела у моей команды?

3Часть III — Как поживают наши инженерные практики?

4Часть IV — Как идут дела в нашей организации?

5Заключение

6Инструкция

6Карточка организационного препятствия

7Фасилитатор со 100% загрузкой?
Опытный Скрам-мастер (​Scrum Master​) может работать с 2-3 командами одновременно.
Если вы готовы ограничить свою роль организацией встреч, контролем отведенного наних времени (timebox), реакцией на препятствия, о которых сотрудники сообщают вявном виде, то сможете справиться с такой ролью, уделяя ей не 100% своего времени.
Скорее всего, команда станет эффективнее и при таком объеме участия — ситуациястанет лучше, чем была до внедрения Скрама (​Scrum​).
Но если вы хотите видеть команду, которая достигает результатов, ранее считавшихсяневозможными в трансформируемой компании, и при этом не перегорает на работе, тосерьезно обдумайте возможность стать первоклассным Скрам-мастером, а такой
Скрам-мастер может работать только с одной командой. Мы рекомендуем на начальномэтапе выбирать одного Скрам-мастера на одну команду из 7 человек.
Если вы не можете определить все предстоящие вам задачи, то прислушайтесь квашему Владельцу продукта (​Product Owner​), к вашей команде, обратите внимание наинженерные практики команды и на всю организацию вне вашей команды. И хотяединого рецепта для всех нет, я опишу некоторые моменты, которые многие
Скрам-мастера упускают из виду. Пожалуйста, отметьте приведенные ниже строкисимволами √, ∆, ?, N/A в соответствии с описанной на последней странице инструкцией.

Часть I — Как дела у моего Владельца продукта?
Скрам-мастер повышает эффективность Владельца продукта, помогая поддерживать
Бэклог продукта (​Product Backlog​) и План релиза. Обратите внимание, что только
Владелец продукта может приоритизировать Бэклог.
▢ Приоритезирован ли Бэклог продукта в соответствии с его/ее последнимисоображениями?
▢ Все ли требования и пожелания к продукту и от всех ли заинтересованных лицзафиксированы в Бэклоге? Помните: Бэклог постоянно изменяется.
▢ Имеет ли Бэклог управляемый размер?
● Чтобы поддерживать контролируемое число элементов (items) в Бэклоге, вверхней его части должны быть мелкие и детальные элементы, а в нижней части— элементы с более общим описанием. Детально анализировать задачи,расположенные ​не​в верхней части Бэклога продукта, контрпродуктивно,поскольку в ходе систематических обсуждений продукта с заинтересованными
лицами и заказчиками требования к нему будут меняться.
▢ Может ли каждое требование (особенно из верхней части Бэклога) быть лучшеописано в формате пользовательской истории (User story), удовлетворяющейкритериям INVEST (независимая, обсуждаемая, ценная, готовая к оценке,небольшая, проверяемая)1?
▢ Объяснили ли вы своему Владельцу продукта о техническом долге и как егоизбегать?
● Одним из способов является добавление автоматического тестирования ирефакторинга в критерии готовности (​Definition of Done​, DoD) каждого элементаБэклога.
▢ Ведется ли Бэклог в виде ​информационного радиатора​, легко доступного для всехзаинтересованных лиц?
▢ Если вы используете инструменты автоматизации управления Бэклогом, то все лиумеют их использовать? Такие инструменты представляют определеннуюопасность, поскольку без активного участия Скрам-мастера обычно превращаются винформационные холодильники​.
▢ Можете ли вы сделать информацию доступнее, демонстрируя распечатки?
▢ Можете ли вы сделать информацию доступнее, создав большие и понятныедиаграммы, графики или схемы?
▢ Помогли ли вы своему Владельцу продукта организовать элементы Бэклога всоответствующие релизы или группы по приоритетам?
▢ Все ли участники знают, насколько план релиза соответствует реальности?
● Вы можете попробовать продемонстрировать всем графики сгорания
продукта/релиза (Product/Release Burndown Charts2), после того как элементыБэклога признаются выполненными (done) в ходе каждого Обзора спринта(​Sprint Review​). Графики показывают как скорость реализации элементовБэклога, так и скорость добавления новых, позволяя отследить изменениясостава и сроков проекта.

1
2

xp123.com/articles/invest-in-good-stories-and-smart-tasks/​Mike Cohn, Agile Estimation and Planning, 2005.

▢ Скорректировал ли Владелец продукта план релиза после последнего Обзораспринта?
● Лишь небольшое число Владельцев продукта ​перепланируют​релиз каждыйспринт. Может потребоваться отложить некоторые работы на будущие релизы,поскольку появятся более важные задачи.

Часть II — Как дела у моей команды?
Несмотря на то, что Скрам-мастеру ст​о​ит подавать личный пример применения навыкови взаимодействия с членами команды (например, участвовать в парномпрограммировании), довольно легко увязнуть в технических задачах слишком глубоко.3Поэтому не забывайте, что основными задачами Скрам-мастера по отношению ккоманде являются:▢ Находятся ли члены команды б​о​льшую часть времени в состоянии ​потока​, безразрыва контекста? Некоторые характеристики этого состояния4:● понятные цели (ожидания и правила ясны, цели достижимы и соответствуютнавыкам и умениям исполнителя);● фокусировка, высокая степень концентрации на ограниченной зоне внимания;● абстрагирование от внешнего мира, объединение действия и его осознания;● прямая и моментальная обратная связь (успехи и неудачи в процессе
выполнения очевидны, так что поведение может быть скорректировано принеобходимости);● баланс между способностями и сложностью задачи (задачи не слишком простыеи не слишком сложные);● чувство личного контроля над ситуацией и текущей деятельностью;● задача приносит удовлетворение сама по себе, поэтому ее выполнение даетсялегко.
▢ Хорошо ли члены команды относятся друг к другу, встречаются ли вне работы,радуются ли успехам друг друга?
▢ Поддерживают ли члены команды высокие стандарты при работе друг с другом ипоощряют друг друга к профессиональному росту?
▢ Есть ли проблемы/возможности, которые команда не обсуждает, поскольку в этомслучае ее члены чувствуют себя некомфортно?5▢ Пробовали ли вы различные форматы и места для проведения Ретроспектив спринта(​Sprint Retrospective​)?6▢ Фокусируется ли команда на Цели спринта? Возможно, в середине спринта вамследует повторно рассмотреть критерии готовности для элементов Бэклога, взятыхв спринт.
▢ Отражает ли доска задач то, что реально делает команда? Остерегайтесь “темнойматерии” невыявленных задач и задач длительностью более 1 дня. Задачи, не3Предложение переведено в соответствии с уточнениями автора: “​A Scrum Master with skills in things likeTDD should ​sometimes​help the rest of the team learn these skills and habits by pair programming and mob
programming with them. But since technical work tends to expand, there's a risk the Scrum Master would neglect
the other Scrum Master responsibilities by focusing on the technical work too much.​”4
Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience, 1990.
5Marshall Rosenberg, Nonviolent Communication: A Language of Life: Life-Changing Tools for Healthy
Relationships, 2003. Also consider enlisting a professional facilitator who can make uncomfortable conversations
more comfortable.
6Derby/Larson, Agile Retrospectives: Making Good Teams Great, 2006.

обещанные к выполнению в спринте, являются препятствиями для реализации этихобещаний.
▢ Состоит ли ваша команда из 3-9 специалистов? В команде достаточно навыков дляразработки потенциально готового к релизу продукта?
▢ Своевременно ли обновляется доска задач команды? Актуальна ли представленнаяна ней информация?
▢ Видны ли команде артефакты самоорганизации (доска задач, график сгорания,любые другие)? Удобны ли они для команды?
▢ Защищены ли эти артефакты от назойливого вмешательства? Избыток вниманияизвне к ежедневной деятельности команды может мешать ее внутреннейпрозрачности и самоорганизации.
▢ Самостоятельно ли члены команды берут себе задачи?
▢ Отражена ли необходимость выплаты технического долга явным образом вкритериях готовности (DoD), которые постепенно делают ваш код более приятнымдля работы?
▢ Оставляют ли члены команды свои звания/должности за пределами рабочего места,совместно отвечая за все аспекты работы (тестирование, документирование, пр.)?

Часть III — Как поживают наши инженерные практики?
▢ Есть ли в разрабатываемой вами системе кнопка «Нажми, чтобы проверить», спомощью которой любой сотрудник вашей или другой команды мог бы легкообнаружить допущенные им ошибки регресса (сломанную функциональность,которая работала до момента внесения изменений)? Обычно это достигается спомощью инструментов xUnit (JUnit, NUnit, пр.).
▢ Найден ли оптимальный баланс между автоматическим еnd-to-end тестированием(функциональным тестированием) и автоматическим модульным/компонентнымтестированием?
▢ Использует ли команда для написания тестов язык, совпадающий с языкомразработки? Совместная работа не становится легче от использования редких
скриптовых языков или средств записи действий пользователя, которыми умеет
пользоваться только часть команды.
▢ Удалось ли команде определить “серую зону”, не покрытую ни компонентными, нисистемными тестами?7▢ Уведомляет ли сервер непрерывной интеграции (CI)8 автоматически о появленииошибки регресса? Может ли время появления такого уведомления снижено до часовили минут? (“Ежедневные билды для слабаков”, — Kent Beck)▢ Включены ли результаты ​всех​тестов в результат работы сервера непрерывнойинтеграции?

7

blogs.collab.net/agile/junit-is-not-just-for-unit-testing-anymore​and Michael’s answer: “I know that many people​
advocate pure unit tests, e.g. Michael Feather's suggestion that they should return in 10 ms. But with my aerospacebackground I'm concerned about errors in the larger system made out of the units. Pure "black box" system tests
take a long time to run, but I think there's an area between pure unit tests and pure system tests that should beexplored.”
8MartinFowler.com/articles/continuousIntegration.html​▢ Осознали ли члены команды всю прелесть непрерывного проектирования ипостоянного рефакторинга9 как альтернативу исчерпывающему проектированию доначала разработки (Big Design Up Front)?
● Рефакторинг имеет четкое определение: изменение внутренней структурысистемы без изменения внешнего поведения. Рефакторинг должен происходитьнесколько раз в час при обнаружении: дублирования кода, сложных логических
условий (видны по избыточным отступам и длинным методам), плохих именидентификаторов, избыточной связности между объектами и т. п. Производитьрефакторинг с уверенностью в результате возможно только при покрытииавтоматическими тестами. Пренебрежение рефакторингом сделает сложнымизменение продукта в будущем, особенно потому, что тяжело найти хорошегоразработчика готового работать с плохим кодом.
▢ Включают ли ваши критерии готовности элементов Бэклога (DoD) полное покрытиеавтоматизированными тестами и рефакторинг? Чтобы выполнить эту задачу,изучите методы “разработки через тестирование” (TDD).
▢ Применяется ли парное программирование большую часть времени?
● Парное программирование существенно повышает степень поддерживаемостикода и снижает количество дефектов. Но этот метод сталкивается с проблемойвзаимодействия людей и иногда занимает большее время (особенно если выизмеряете производительность в строках кода, а не в поставляемойфункциональности). Попробуйте ввести в своей команде специальные днипарного программирования и вы увидите, что некоторые разработчики
предпочтут работать таким образом.

Часть IV — Как идут дела в нашей организации?
▢ Достаточно ли количество коммуникаций между командами? “Scrum of Scrums” —всего лишь один из способов добиться такого взаимодействия, и не всегда лучший.
10▢ Могут ли ваши команды независимо друг от друга реализовывать работающую
функциональность даже при пересечении архитектурных границ?11▢ Встречаются ли ваши Скрам-мастера друг с другом для устранения организационныхпрепятствий?
▢ Сообщается ли об организационных проблемах в офис директора по разработке?
Может ли быть определена стоимость в долларах, потерянном времени выхода нарынок (time-to-market), уровне снижения качества, нереализованных возможностяхклиентов?
● Но будьте осторожны и не повторяйте ошибку Кена Швабера, которого уволилиза то, что он слишком сильно подталкивал организацию к изменениям: “МертвыйСкрам-мастер — бесполезный скрам мастер.”12▢ Относится ли ваша организация к тем редким организациями, в которых карьерныйпуть совпадает с общими целями ваших команд? Отвечайте “нет”, если в вашей

9Martin Fowler, Refactoring: Improving the Design of Existing Code, 1999.
See ​less.works/less/framework/coordination-and-integration.html​for alternatives.
11
FeatureTeamPrimer.org​12Ken Schwaber, Agile Project Management with Scrum, 2004. The "dead ScrumMaster" quote is from a story inKen's book. He was fired because he pushed the organization too hard.
10организации в карьерном смысле13 выгоднее заниматься разработкой илиархитектурой, чем тестированием, автоматизацией или документированием.
▢ Признавала ли отраслевая пресса или другие независимые источники вашуорганизацию одной из лучших организаций для работы или лидером в вашейиндустрии?
▢ Создаете ли вы “обучающуюся организацию”?

ЗаключениеЕсли вы сможете ответить на большинство этих пунктов, и у вас еще останется времядо конца дня, то дайте мне знать. Нет готовой формулы для овладения мастерством.
Приведенные выше пункты списков могут как помочь в вашей ситуации, так и оказаться
бесполезным. После того, как вы начнете понимать, что могли бы сделать дляизменения ситуации, вы можете заметить, что боитесь делать это. Это знак, что вы направильном пути.

ИнструкцияЕсли вы получили этот чек-лист как учебное задание, и ваш текущий (или последний)работодатель пробовал что-либо подобное Скраму, пожалуйста, заполните список всоответствии полученным опытом. Отметьте каждый пункт следующим образом:√∆?
N/Aесли сделано хорошо
если “может быть улучшено” и “я знаю с чего начать”если “может быть улучшено, но как?”если “не применимо” или “не принесет пользы”Если ваш текущий (или последний) работодатель не пробовал внедрять Скрам, тозаполните список следующим образом:
√
∆
?
N/A

если “сделано хорошо” или “может быть легко сделано”если “будет тяжело, но я знаю с чего начать”если “будет тяжело, и я ​не​знаю с чего начать”если “не применимо” или “не принесет пользы”Заполнив все пункты, опишите 2-6 организационных препятствий с помощью “Карточки
организационного препятствия” (ниже) независимо, взята проблема из этого чек-листаили нет. Осталось выбрать из этих препятствий те, для которых есть хотя бы 1%вероятность успеха.

Чек-лист был впервые переведен 14 сентября 2007, автор неизвестен (сообщите мне,если знаете). В 2017 году чек-лист обновил Дмитрий Блинов (​Dmitriy.Blinov@mail.ru​,
SkillsCup.com​), уточняя детали у автора. Ревизию провел Денис Тучин(​DenisTuchin@gmail.com​).

13

Alfie Kohn, Punished By Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes,1999.

Карточка организационного препятствияПроблема внешне выглядит так:Первопричина (используйте вопрос “Почему?” пять раз):Влияние на бизнес:Влияние на эмоции:Запрос на конкретное действие:Карточка организационного препятствияПроблема внешне выглядит так:Первопричина (используйте вопрос “Почему?” пять раз):Влияние на бизнес:Влияние на эмоции:Запрос на конкретное действие: