Scream Guide. Как быть Agile и не меняться

16 min readFeb 21, 2019

Scream — это фреймворк, созданный как имитация Scrum, дающий невольным наблюдателям впечатление, что организация использует Scrum. Scream — это основа для закрепления статус-кво, сохранения существующих мировоззрений и создания иллюзии улучшения процесса разработки. Scream Guide, который вы читаете, это руководство, содержащее важные элементы Scream. Он состоит из ролей, событий, артефактов и правил Scream, которые связывают их вместе. Пока Ken Schwaber и Jeff Sutherland создавали Scrum, Scream использовался и используется в тысячах организаций по всему миру, которые утверждают, что занимаются Scrum.

Определение Scream

Scream: фреймфорк в рамках которого организация создает видимость внедрения Scrum без решения каких либо значимых проблем в процессах разработки. Scream создает иллюзию Agile, дает менеджерам чувство контроля над ситуацией, обеспечивает строгие сроки и подталкивает разработчиков к неэтичным и неустойчивым методам разработки.

Практики Scream легко внедрять, просто использовать и очень сложно искоренить.

С момента появления компьютеров, ещё до получения собственного имени, Scream использовался для управления разработчиками в сложных проектах. Scream это не процесс, техника или метод. Скорее, это структура, в рамках которой менеджеры могут использовать различные процессы и методы. Scream опирается на информационное преимущество, двусмысленность и запутанность. Он контролирует людей и их работу и успешно снижает производительность, сдерживает развитие команды и ухудшает рабочую среду.

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

Правила Scream описаны в тексте этого документа. Способы использования Scream различны и встречаются практически в каждой организации на Земле.

Использование Scream

Изначально Scream был разработан для управления командами разработчиков. Начиная с начала профессиональной разработки программного обеспечения, Scream широко используется во всем мире для:

Сдерживания команды и поддержания иллюзии контроля;
Повышения предсказуемость проекта (У вас ничего не получится!);
Управления талантами (Они быстро от вас уйдут!);
Потери стабильности ради быстрых побед;
Добавления заслуг в резюме менеджеров, готовящих свой следующий карьерный ход;
Закрепления статус-кво в организации.

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

Теория Scream

Scream основан на теории абсолютного контроля над людьми, также известной как «империализм». Империализм утверждает, что знание приходит сверху вниз и принятие решений должно быть основано на звании и власти. Scream использует устойчивый итеративный подход, чтобы создать иллюзию предсказуемости и контролировать людей. Четыре столпа, на которые опирается Scream это запутывание, асимметричная информация, изменяющиеся цели, а также метрики и отчетность.

Запутывание

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

Например:

Использование терминологии Scrum, чтобы люди не осознавали, что это не Scrum;
Те, кто выполняет работу, и те, кто будет использовать результат, должны использовать термин «Готово» так, как им это удобно.

В некоторых частях Scream Guide мы используем термин «прозрачность». В контексте Scream «прозрачность» всегда следует понимать как одностороннее зеркало — каждое движение команды наблюдается без получения какой-либо информации взамен.

Ассиметричная информация

Пользователи Scream должны часто проводить встречи с разным составом участников и рассказывать им разные истории, чтобы никто не знал, как на самом деле идет процесс продвижения к Цели Спринта. Эти встречи должны быть настолько частыми, чтобы важные аспекты менялись прежде, чем кто-либо смог к ним адаптироваться. Проверки в основном направлены на людей и их текущее понимание ситуации, чтобы держать их под контролем.

Изменяющиеся цели

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

Scream предписывает четыре формальных события для смены целей:

Планирование Спринта
Ежедневный Scream
Обзор Спринта
Ретроспектива

Кроме того, встречи один на один могут использоваться для смещения целей отдельного члена команды, чтобы еще больше изолировать его от других участников.

Метрики и отчеты

Scream способствует глубокому пониманию эффективности команды, позволяя менеджерам точно определять, где, когда и кто не работает на 110%. Scream предоставляет менеджерам все необходимые данные для измерения и контроля каждого чиха любого разработчика.

Ценности Scream

Под влиянием четырех столпов Scream ценности Scrum, такие как обязательство, фокус, открытость, уважение и смелость трансформируются и принимают другое значение:

«Смелость» означает всегда брать больше работы, чем вы можете сделать;
«Обязательство» означает делать эту работу сверхурочно;
«Открытость» означает, что все должны браться за другое задание, когда возникает такая потребность сверху;
«Фокус» означает жонглирование множеством шаров, не будучи пойманным на том, что вы уронили один из них;
«Уважение» означает не жаловаться ни на что из вышеперечисленного при общении с менеджерами.

Успешное использование Scream зависит от того, как ловко менеджеры используют эти пять ценностей, чтобы исключить инакомыслие и критическое мышление в команде. Особенно когда самоорганизация команды вытаскивает на поверхность бесполезность менеджера.

Scream команда

Команда в Scream состоит из владельца продукта, команды разработчиков и Scream мастера, а также их менеджера. Команды Scream кажутся самоорганизующимися и кросс-функциональными пока всё шоу управляется менеджером. Менеджер выбирает, как лучше всего выполнить работу, а не позволяет команде решать за себя. Менеджер добавляет или убирает людей из команды по мере необходимости, чтобы результат был достаточно далеко от «почти готово».

Команды Scream кажутся самоорганизующимися и кросс-функциональными пока всё шоу управляется менеджером.

Командная модель в Scream предназначена для оптимизации управления, подчинения и занятости. Команды Scream накапливают разочарование итеративно и постепенно, максимизируя возможности для вспышек ярости. Инкрементальные поставки «почти готового» (хотя и абсолютно бесполезного) продукта гарантируют постоянное чувство вины и напряжения в команде, в то время как бизнес не получает ничего ценного.

Владелец продукта

Владелец продукта отвечает за максимизацию рабочей нагрузки каждого члена команды разработки. Как это делать, может сильно различаться в разных организациях и Scream командах. Владелец продукта является основным лицом, ответственным за управление бэклогом продукта.

Владелец продукта поддерживает бэклог настолько длинным, чтобы никто не мог дочитать его до конца.

Управление бэклогом продукта включает в себя:

Описание элементов бэклога так, чтобы все думали, что они понятны, хотя важные факты в задачах всё ещё отсутствуют;
Расположение элементов в бэклоге так, чтобы команда была всегда занята;
Максимизацию объема работы команды без доставки ценности;
Трансляцию требований в пользовательские истории с заполнением всех обязательных полей в трекинг-системе;
Определение всеобъемлющих критериеы приемки на уровне юнит-тестов;
Добавление подробных дизайн макетов ко всем элементам бэклога;
Поддержание бэклога настолько длинным, чтобы никто не мог дочитать его до конца;
Обеспечение того, чтобы бэклог был как можно более запутанным и вводящим в заблуждение, будучи на первый взгляд понятным для всех, и мало показывающим то, что на самом деле происходит в Scream команде;
Обеспечение того, чтобы команда думала, что понимает продукт (на самом деле нет!)
Переписывание задач и требований с использованием шаблона пользовательских историй;
Декомпозиция задач на части, которые достаточно малы, чтобы обеспечить микроменеджмент.

Владелец продукта может выполнять вышеуказанную работу добровольно или по указанию своего менеджера. Любой менеджер с более высокой должностью может добавлять, изменять или удалять элементы из бэклога без предварительного уведомления. Тем не менее, владелец продукта остается ответственным за всё.

Владелец продукта — марионетка другого лица или группы лиц. Он должен подчинятся воле тех менеджеров, которые хотят изменить приоритеты бэклога продукта. Поскольку у владельца продукта нет шансов добиться успеха, вся организация может игнорировать его или её решения. Любой менеджер более высокого ранга может заставить команду разработчиков работать с другим набором требований в любое время.

Команда разработки

Команда разработки состоит из людей, которые выполняют работу, которую им велят. Их кормят морковкой на верёвочке, чтобы однажды что-то могло быть «готово». Достижение «готового» Инкримента это лотерея с оглашением результатов на обзоре спринта. В то время как члены команды разработки создают Инкремент, их менеджер может изменить цели спринта ещё до того, как он будет закончен. Команды разработчиков структурированы и ограничены форматом выполнения работы, которую им поручено делать. В результате синергия сводит к минимуму способность команды разработчиков сотрудничать или делать правильные вещи.

Команды в Scream называются «самоорганизующимися». Любой (даже уборщик) может рассказать команде разработчиков, как они должны делать свою работу.

Команды разработчиков имеют следующие характеристики:

Они называются «самоорганизующимися». Любой (даже уборщик) может рассказать команде разработчиков, как они должны делать свою работу;
Команды разработчиков называются «кросс-функциональными» и обладают практически всеми необходимыми навыками для создания «почти готового» продукта;
Команды разработчиков проводят большую часть своего времени, открывая новые и инновационные способы игр с метриками, придуманными руководством;
Scream распознает любое количество названий для членов команды разработчиков и может различать членов команды по причудливым критериям, даже таким как возраст или пол;
Scream делит команду на фракции и подгруппы, например, тестирование, архитектура, бэкенд или бизнес-анализ, чтобы еще больше запутать выполняемую работу;
Отдельные члены команды разработчиков могут не иметь требуемых навыков, но ответственность в любом случае лежит на них.

Размер команды разработки

Оптимальный размер команды разработчиков либо достаточно мал, чтобы оставаться под контролем, либо достаточно велик, чтобы выглядеть так, будто они выполняют значительный объём работы за спринт. Менее трех разработчиков в команде меньше взаимодействуют между собой, что приводит к лучшему контролю. Наличие более девяти участников в команде требует, по крайней мере, одного Scream мастера на полный рабочий день для координации. Большие команды разработчиков создают много коммуникационных издержек и позволяют Scream мастерам казаться полезными. Роли «Владелец продукта» и «Scream Мастер» не учитываются при расчёте размера команды, поскольку они не выполняют никаких работ из бэклога.

Scream мастер

Scream мастер отвечает за продвижение и поддержку правил Scream, как это определено в Scream Guide. Мастера Scream делают это, создавая дополнительную работу и путаницу, вводя сложные практики, правила и применения ценностей Scream. Scream мастер помогает команде изменить свое поведение и взаимодействие, чтобы соответствовать меняющимся ожиданиям руководства.

Scream мастер следит за тем, чтобы Владелец продукта вкладывал большую часть своего времени в задачи, которые не будут реализованы в течение следующего полугода.

Роль Scream мастера масштабируется: добавление более одного Scream мастера с использованием разных паттернов Scream экспоненциально повысит эффективность Scream.

Scream мастер достаёт Владельца продукта несколькими способами, в том числе:

Следит за тем, чтобы все пользовательские истории и задачи постоянно обновлялись в трекинг-системе;
Ищет более сложные методы для управления бэклогом продукта;
Настраивает сбивающие с толку метрики, делающие цели, объем работ и ценность продукта неопределенными и неоднозначными для всех в Scream команде;
Заставляет команду справляться с непонятными задачами из бэклога;
Регулярно запрашивает планы проекта и подробные спецификации;
Следит за тем, чтобы владелец продукта вкладывал большую часть своего времени в задачи, которые не будут реализованы в течение следующего полугода;
Содействует событиям Scream в стиле Scream.

Scream мастер достаёт Команду несколькими способами, в том числе:

Обнаруживает и подавляет все намеки на самоорганизацию и сотрудничество;
Навязывает решения, которые команда должна использовать;
Поддерживает занятость каждого члена команды;
Назначает задачи отдельным членам команды;
Поощряет специализацию и владение отдельными частями кода, которые создают подгруппы в команде разработчиков;
Отвлекает команду разработчиков от создания достойных результатов;
Игнорирует влияние препятствий на прогресс команды;
Организует длительные статусные встречи, которые прерывают ход работы;
Содействует событиям Scream в соответствии с процессом;
Создаёт и поддерживает всеобъемлющую вики-документацию предпочтительного процесса управления «как должно быть»;
Максимизирует сложность процессов управления задачами;
Настраивает и отслеживает индивидуальные и командные показателей эффективности;
Составляет комплексные отчеты о состоянии процесса;
Следит за тем, чтобы разработчики не отвлекались от своих задач на общение друг с другом;
Запутывает команду разработчиков, заставляя их поверить, что Scream — это высшее выражение Agile.

Scream мастер достаёт всю компанию несколькими способами, в том числе:

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

События Scream

Обязательные события являются важным элементом Scream, они используются для прерывания работы, контроля деятельности членов команды и максимизации зависимости от вмешательства извне.

Все события имеют временные рамки, но их может прервать присутствующий менеджер, чтобы предотвратить получение значимых результатов. Как только начинается Спринт, его продолжительность довольно фиксирована и может быть сокращена или увеличена только по усмотрению менеджера. Остальные события, возможно, потребуется продлить, когда менеджеру потребуется дополнительное время, чтобы высказать свою точку зрения. Кроме самого Спринта, который является контейнером для всех других событий, каждое событие в Scream является формальной возможностью для менеджера критиковать отдельных членов команды или всю команду целиком.

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

Спринт

Сердцем Scream является Спринт, период времени в один месяц или меньше, в течение которого создается «почти готовый», почти пригодный для использования и потенциально интегрируемый продуктовый Инкримент. Спринты имеют постоянную продолжительность, пока менеджер доволен этим. Новый Спринт начинается сразу после того, как менеджер завершает предыдущий Спринт. Спринты содержат и включают в себя планирование спринта, ежедневные Scream митинги, разработку, обзор спринта, ретроспективу спринта и столько встреч, сколько менеджер сочтет необходимым.

Спринт — это период времени в один месяц или меньше, в течение которого создается «почти готовый», почти пригодный для использования и потенциально интегрируемый продуктовый Инкримент.

Во время спринта:

Команда упорно трудится, чтобы реализовать все требуемые функции;
Менеджер может добавить в объём задач что угодно всякий раз, когда появляется что-то срочное;
Разработчики работают столько часов, сколько необходимо для достижения цели Спринта;
Качество не является обязательным;
Объём работы может быть пересмотрен менеджером и отдельными разработчиками, если менеджер сочтет это целесообразным;
Обучение откладывается до следующего спринта;
Не вносятся никакие изменения в процессах, конечно, если это не требует руководство.

Каждый Спринт является частью одного или нескольких проектов, но охватывает не более одного месяца. Как и проекты, Спринты используются для достижения чего-либо. Это «что-то» заставляет команду работать как можно больше и усерднее — и хорошая новость заключается в том, что после окончания спринта вы можете просто повторить всё сначала!

Спринт может иметь целью то, что команда считает важным, но это не имеет значения, когда у менеджера другое мнение. Дизайн и жесткий план работ могут быть предоставлены заранее, чтобы лучше руководить созданием продукта и выполнением работы.

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

Помимо обычных Спринтов, есть и специальные. Одним из них является начальный, обязательный нулевой Спринт, во время которого команда ничего не делает, кроме попыток выяснить, что происходит. Другой — это повторяющийся релизный Спринт, где команды получают седые волосы в своих бесполезных попытках распутать беспорядок, созданный во время последней пары спринтов.

Отмена спринта

Спринт может быть отменен до истечения временного интервала Спринта. Только менеджер имеет право отменить спринт, даже если команда и владелец продукта уже знают, что они не добьются успеха. Владелец продукта может быть козлом отпущения за это решение, принятое их менеджером или менеджером этого менеджера — или менеджером менеджера этого менеджера — ну вы поняли идею.

Спринт отменяется, если менеджер чувствует, что команда не выполняет его указания. Это может произойти, если разработчики начнут думать самостоятельно или если менеджер изменить свое мнение. В общем, Спринт должен быть отменен всякий раз, когда менеджер чувствует, себя неуверенно. Из-за короткой продолжительности Спринтов, отмена является эффективным механизмом для создания неуверенности и беспорядка в команде.

Когда Спринт отменяется, все выполненные и «готовые» элементы бэклога отправляются в корзину. Частично «готовые» элементы возвращаются в случайном порядке в бэклог. Частично выполненную работу лучше оставить в ветках разработчиков и задокументировать в вики, чтобы возобновить её когда-нибудь.

Отмена Спринта — отличный способ держать команды занятыми, так как все собираются и начинают планирование следующего Спринта. Отмена спринта часто задевает команду за живое, что делает её отличным инструментом для снижения самооценки и доверия внутри команды.

Планирование Спринта

План командной работы в течение Спринта создается на Планировании Спринта. Этот жесткий план создается заранее владельцем продукта или руководством, не привлекая команду, чтобы не отвлекать её от выполнения работы. Максимальное время для планирование Спринта длиною в месяц — 8 часов. Этого времени вполне достаточно, чтобы успокоить команду и убедить в реальности абсолютно нереального плана.

Задача Scream мастера гарантировать проведение Планирования, и убедиться что каждому будет назначено достаточно работы. Также он учит Scream команду не задавать слишком много вопросов при представлении работы.

Присутствие менеджера во время Планирования Спринта очень важно, чтобы гарантировать, что получены ответы на следующие критические вопросы:

Сколько заданий назначено каждому человеку?
Что займет сколько времени?
Все ли ресурсы полностью использованы?
Если дела пойдут неожиданно хорошо, какую дополнительную работу вы можете ещё сделать?

По мере необходимости менеджер прекращает бессмысленные дискуссии о сути задач бэклога и их технической реализации и переориентирует членов команды разработки на задачи, которые им необходимо взять в работу. Менеджер может передать эту ответственность Scream мастеру.

В конце планирования спринта Scream мастер должен заставить членов команды взять на себя обязательство выполнить все свои задачи, даже если все знают, что дополнительные задачи будут добавляться на протяжении всего Спринта.

Ежедневный Scream

Daily Scream — это ежедневное 15-минутное (или более) событие, когда Scream мастер проверяет команду разработчиков. Ежедневный Scream проводится каждый день Спринта, когда менеджер доступен. При этом команда описывает задачи, которые они точно должны сденлать в течение следующих 24 часов. Это оптимизирует процессы управления и производительность, проверяя работу каждого разработчика с момента последнего Daily Scream и прогнозируя предстоящую работу на Спринт.

Daily Scream развивает непрямые коммуникации, устраняет независимость, выявляет бездельников, усиливает независимое принятие решений и повышает уровень знаний менеджера о команде.

Daily Scream проводится в самое неудобное время и в месте, куда труднее всего добраться. Отличный способ сохранить бдительность членов команды — переместить Daily Scream в случайное место, вдали от доски и места расположения команды.

Руководство использует Daily Scream для проверки прогресса каждого отдельного разработчика, чтобы проверить, где требуется вмешательство. Daily Scream оптимизирует вероятность того, что Scream мастер быстро вычислит всех бездельников. Каждый день команда разработчиков сообщает о работе, которую они проделали и которая ещё предстоит, а также информирует Scream мастера сколько сверхурочной работы они сделают, чтобы выполнить все свои задачи к концу Спринта.

Структура собрания задается Scream мастером и может быть изменена руководством в любое время без соглашения команды.

Некоторые организации предпочитают, чтобы разработчики отвечали на ряд стандартных вопросов, другие сосредоточены исключительно на отчетности. Вот пример вопросов, которые могут потребоваться:

Чем я занимался вчера?
Что я буду делать сегодня?
Какая у меня есть дополнительная работа, о которой никто не знает?

Важно, чтобы разработчики точно рассказывали какие встречи они посещали, кому писали письма и какие документы они обновляли, чтобы без сомнений доказать, что они действительно были заняты в течение восьми часов.

Scream мастер следит за тем, чтобы команда проводила Daily Scream и что статус работы каждого всем известен. Он может извлекать выгоду из собрания, задавая критические вопросы, например, почему та или иная задача ещё не сделана. Scream мастер делает заметки по ходу собрания и собирает информацию в исчерпывающий отчет, чтобы руководителям не приходилось тратить время на работу с командой. При необходимости Scream мастер превратит Daily Scream в длительное собрание, где все детали будут обсуждены до такой степени, что каждого в команде от них будет тошнить.

Daily Scream развивает непрямые коммуникации, устраняет независимость, выявляет бездельников, усиливает независимое принятие решений и повышает уровень знаний менеджера о команде. Это ключевая встреча по управлению информацией и поведением команды.

Отдельные члены команды часто вступают в длительную личную встречу со своим непосредственным руководителем сразу после Daily Scream, где им нужно будет объяснить, почему они не достигли достаточного прогресса, и получить новые инструкции.

Обзор спринта

Обзор спринта проводится по усмотрению старшего руководства для проверки хода выполнения задач и критики команды. Во время обзора спринта Scream мастер или Владелец продукта представляет презентацию или живые графики из трекинг-системы, чтобы показать, насколько сильно была занята команда.

Это официальная встреча длительностью максимум четыре часа, для более занятых менеджеров событие обычно короче.

Scream мастер следит за проведением события и за тем, что все слайды были показаны. Также должны быть соблюдены следующие правила:

В число участников входят важные менеджеры, Scream мастер и Владелец продукта;
Члены команды разработки должны работать, а не тратить своё драгоценное время на встречи;
Scream мастер показывает руководству основные показатели производительности;
Владелец продукта объясняет, над какими элементами бэклога работала команда;
Руководство спрашивает почему не видны результаты;
Scream мастер оправдывается почему план не был выполнен и старательно избегает упоминания препятствий, которые должны были быть устранены;
Владелец продукта обсуждает план предстоящего спринта с руководством;
Владелец продукта и Scream масьтер соглашаются осуществить все изменения в соответствии с требованиями руководства.

Результатом Обзора являются дополнительные требования, новые элементы бэклога и завышенные ожидания от предстоящего Спринта.

Ретроспектива Спринта

Ретроспектива — это дополнительная возможность для команды поныть о своих страданиях.

Ретроспектива происходит после Обзора Спринта и до следующего Планирования Спринта. Это максимум трехчасовая встреча для месячных спринтов, для более коротких спринтов событие обычно короче. Scream мастер гарантирует, что мероприятие состоится, и что у всех разработчиков достаточно времени, чтобы пожаловаться.

Ретроспектива — это дополнительная возможность для команды поныть о своих страданиях.

Целью Ретроспективы Спринта является:

Дать разработчикам время высказаться, поскольку в следующем Спринте они будут работать сверхурочно;
Проверить, кто что испортил в последнем Спринте;
Определить, кто должен что-то изменить во время следующего Спринта;
Сообщить об изменениях, которые руководство хочет сделать в команде.

Во время каждой Ретроспективы команде сообщают, как увеличить рабочую нагрузку, добавляя шаги к рабочим процессам или адаптируя определение «почти готового» продукта. К концу Ретроспективы Scream команда должна понять, что у нее нет другого выбора, кроме как сделать то, что говорит Scream мастер, и реализовать эти изменения в следующем Спринте. Реализация этих улучшений в следующем Спринте — это ответственность самой команды.

После Ретроспективы Scream мастер публикует заметки о самых пикантных подробностях, которые можно будет использовать в любое время в будущем, чтобы заставить члена команды соблюдать правила.

Прозрачность

Scream полагается на то, что команда полностью прозрачна. Решения по оптимизации рабочей нагрузки и контролю членов команды принимаются на основе данных, доступных в инструменте отслеживания.

Scream Master должен сотрудничать с владельцем продукта, командой разработчиков и руководством, чтобы гарантировать полную прозрачность артефактов. Существуют практики, позволяющие справиться с неполной прозрачностью. Scream мастер должен заставить всех применять самые строгие методы, чтобы обеспечить полную прозрачность. Он может обнаружить неполную прозрачность, просматривая артефакты Scream, распознавая закономерности, внимательно слушая сказанное на Daily Scream и обнаруживая различия между ожидаемыми и реальными результатами. Эта работа обычно включает в себя командование, манипуляции и контроль. Прозрачность не появляется в одночасье, но к ней нужно стремиться.

«Почти готовый» продукт

Когда член команды разработчиков говорит, что его часть работы «Почти готова», это должно соответствовать требованиям, установленным организацией. Хотя значение «Почти готово» может значительно отличаться у каждого члена команды, для обеспечения прозрачности необходимо составить полный контрольный список.

Одно из таких определений позволяет Владельцу продукта знать, сколько элементов бэклога продукта можно взять в работу на Спринт. Цель каждого Спринта состоит в том, чтобы максимизировать количество задач, которые соответствуют контрольному списку Почти готово» конкретного исполнителя.

Если над продуктом работает несколько Scream команд, у каждой команды будет свое определение «Почти готово», чтобы усилить цели Scream по созданию непрозрачности, сложность и путаницы.

По мере взросления Scream команды ожидается, что их определения «Почти готово» станут документами размером с телефонную книгу, настолько строгими, что объём работы, необходимой для получения чего-либо «Почти готового», приближается к бесконечности. Новые критерии могут противоречить старым критериям, в этом случае Scream мастер выберет несколько случайных элементов, которые разработчик может пропустить.

Чтобы улучшить статистику в управленческих отчетах, Scream мастер может ввести определение «Почто готово по мнению менеджера», которое всё ещё может быть доведено до состояния «Почто готово» во время ночных смен или выходных.

Заключение

Scream, описанный в этом руководстве, предлагается почти бесплатно, разве что вы платите своим здравым умом и нормальной психикой. Роли, события, артефакты и правила Scream варьируются от организации к организации, и большинство из них реализуют только части Scream — в результате всё равно получается Scream. Scream существует для сохранения существующих систем и функций, а также как контейнер для других методов, методологий и практик.

Внимание, если вы применяете Scream Guide в разработке, вся ответственность за отсутствие результатов (а вы точно облажаетесь!) лежит на вас. Так что лучше используйте всё выше сказанное как вредные советы!

Этот текст — мой вольный сокращённый перевод результатов коллективного творчества англоязычных экспертов по скраму под руководством Michael Küsters. Оригинал можно найти здесь.

Понравилось? Подписывайтесь на мой канал в Телеграм. Пишу о процессах и продуктах, делюсь опытом в agile, lean, usability и customer development.

https://t.me/vladimir_merkushev