Ниже приведен отрывок из нашей книги « Скрам: новичок ниндзя» , написанной М. Дэвидом Грином. Копии продаются в магазинах по всему миру, или вы можете купить их в электронном виде здесь .
Скрам-команда не работает в вакууме. Обычно есть организация, которая существует вокруг Scrum, и которая поддерживает усилия команды Scrum с ресурсами, необходимыми для выполнения работы. Между командой разработчиков и остальной частью организации необходимо поддерживать двусторонние отношения, чтобы каждый мог извлечь выгоду из этого процесса.
Подобно тому, как организация и ее иерархия не должны иметь никакого влияния на ритуалы, артефакты и роли схватки, у скрама нет формального мнения о том, как устроена внешняя организация. Scrum может успешно существовать в жестко многоуровневой компании с четко определенными названиями и ролями так же легко, как она может работать в режиме «холокоста» (организация без какой-либо формальной цепочки командования). До тех пор, пока рабочая группа обеспечена необходимыми ресурсами и может оправдать свое существование, получая результаты, которых хочет организация, отношения должны поддерживаться.
Иногда существуют разные мнения о том, как ресурсы должны быть предоставлены команде. Гибкий подход к решению этой проблемы состоит в том, чтобы попробовать один способ, заметить, насколько хорошо он работает, и повторить, чтобы найти то, что наиболее продуктивно.
В частности, есть несколько ключевых ресурсов, в которых большинство групп разработчиков, занимающихся веб-разработкой и разработкой мобильных приложений, нуждаются, которые формально не определены как часть разборок.
Конструкторы
Важным вкладом в любой веб или мобильный проект является дизайн. Дизайнеры помогают установить взаимодействие с пользователем, последовательность и визуальную согласованность проекта. С тенденцией к проектному мышлению как процессу, дизайнеры стали элементарными на всех этапах разработки продукта, от начального определения проблемы до каркасного моделирования, создания руководств по стилю, создания графических ресурсов, проверки визуальной согласованности и тестирования пользовательского опыта.
Дизайнеры тесно сотрудничают с владельцами продуктов при разработке новых историй. В большинстве случаев выбор дизайна движет идеей, и большая часть инноваций в том, как продукт развивается итеративно, приходит от дизайнера. Но дизайнеры также должны быть доступны членам команды, когда возникают вопросы о макете и стиле. Иногда дизайнеры должны быть готовы бросить все и создать активы или принимать решения, которые имеют решающее значение для разблокировки разработчиков в середине истории. Переключение между концептуальным мышлением и детальным, практическим производством может сделать роль дизайнера очень сложной.
Некоторые команды предпочитают интегрировать дизайнеров в команду и включать их во все ритуалы. Преимущество этого подхода заключается в том, что дизайнер постоянно осведомлен о том, как работает команда, и может дать немедленную обратную связь, участвуя в создании истории, а также в оценке и разработке. Дизайнер, который выбирает работу в составе команды, должен быть готов принять участие в процессе схватки, как и любой другой член команды.
Однако, в отличие от большинства членов команды разработчиков, проектировщик обычно не обучен и не склонен работать инженером или работать с другими инженерами в процессе разработки. Кроме того, навыки и обязанности дизайнера могут не подойти для совместной работы с инженерами, не обученными дизайну. Из-за этого к дизайнеру, который интегрирован в команду, возможно, придется относиться иначе, чем к другим ресурсам команды. Иногда это может создать ощущение дисбаланса, оставляя роль дизайнера плохо интегрированной.
Другой подход, который используют многие команды, заключается в создании расширенной последовательности спринта с отдельным спринтом дизайна, который предшествует спринту разработки. Это помогает изолировать работу дизайнеров от работы инженеров, в то же время сохраняя дизайнеров интегрированными в процесс схватки в качестве членов команды.
Использование подхода спринт дизайна может быть эффективным, но оно ограничивает ловкость схватки. Поскольку спринты проектирования происходят раньше, чем спринты разработки, команда эффективно работает с шагом в два раза больше. Это означает, что способность владельца продукта корректировать требования должна быть вытеснена дополнительным спринтом, поэтому изменения должны планироваться намного раньше. Для некоторых команд это может быть хорошим решением, если они готовы принять компромисс.
Третий метод, который стоит рассмотреть, — это поддерживать отдельную команду разработчиков и рассматривать их как ресурс. К дизайнерам из команды дизайнеров могут быть привлечены идеи, создание историй, разработка активов, тестирование потока пользователей или все, что нужно процессу Scrum. Поскольку дизайнеры не зависят от процесса схватки, они могут посещать ритуалы в качестве гостей, но не обязаны быть активными участниками.
Команда разработчиков, которая работает как независимый ресурс, может выбрать структурирование себя, используя другой гибкий подход, известный как канбан . Канбан похож на схватку, но вместо того, чтобы работать в спринтах с контрактными результатами с заранее определенными интервалами, команда канбана берет на себя определенное количество незавершенного производства. Команды Kanban могут принимать новые истории от владельца продукта без предварительного планирования, при условии, что ресурсы команды никогда не предназначены для выполнения задач, превышающих объем работы, которую они способны выполнять устойчиво.
Примечание: Канбан
Детали kanban более сложны, чем то, что мы рассмотрели здесь, но это еще один подход, который стоит рассмотреть для организации работы, включающей постоянный поток услуг. В частности, Канбан очень эффективен для управления рабочим процессом таких организаций, как Операции и Служба поддержки клиентов, где существует постоянный поток похожих историй, которые необходимо решать, и которые часто требуют быстрого реагирования на приоритетной основе.
QA Engineers
Обеспечение качества является обязанностью каждого члена команды, но в большинстве организаций есть профессионалы, специально обученные методам создания и управления тестовыми наборами. Для работы в Интернете и на мобильных устройствах это может быть сложным и сложным процессом, включающим инструменты, имитирующие поведение широкого спектра устройств и браузеров, и автоматизацию, позволяющую следовать как распространенным, так и необычным путям через продукт.
Инженеры QA могут быть изолированы в своей собственной группе, работающей независимо от команды, занимающейся разработкой продукта. В этом случае координация с командой имеет решающее значение. Если QA не принимается во внимание на раннем этапе, команда разработчиков может поспешить завершить рассказы до демонстрационной встречи спринта, а затем в последний момент свалить нагрузку на команду QA, чтобы истории были готовы к демонстрации.
В отличие от дизайнеров, QA-инженерам иногда дают отдельный спринт для тестирования. Это позволяет избежать попыток быстрой проверки историй в конце каждого спринта, но при этом вводит тот же вид пониженной гибкости, что и отдельный спринт дизайна. Кроме того, когда приходит время для демонстрации историй, большая часть команды уже перешла к более новым историям, и детали работы предыдущего спринта могут быть не свежими в их умах.
Самая большая проблема с изоляцией QA от разработки заключается в том, что инженеры могут свободно выбирать следующую статью из своего списка, прежде чем предыдущая статья будет проверена. Часто в веб- и мобильном контексте истории будут основываться друг на друге тонкими способами, даже если истории технически независимы. Это может привести к ситуациям, когда работа над новой историей должна быть переделана на основании несоответствий, обнаруженных при тестировании предыдущей истории.
В идеале, QA следует рассматривать как часть определения команды «выполнено» для любой истории. Это означает, что инженеры QA должны начать писать тесты для истории в то же время, когда разработчики создают код. Цикл QA для истории должен быть частью спринта, и разработчики, работающие над историей, не должны оставлять ее, чтобы начинать что-то новое, пока QA не будет завершено.
В некоторых командах инженеры QA интегрированы в команду напрямую. Это обеспечивает ряд преимуществ. Навыки и подготовка инженеров по разработке и контролю качества дополняют друг друга, и люди в обеих ролях могут получить профессиональную выгоду от объединения друг с другом, чтобы больше узнать о методах и подходах, которые они используют. Команда с интегрированными инженерами по обеспечению качества также естественно рассматривает тестирование и валидацию как часть усилий по созданию законченной истории, и обеспечивает, чтобы истории были рассчитаны по размеру и были запланированы соответствующим образом, чтобы включить это.
операции
Люди, которые поддерживают работу сетей и занимаются технической поддержкой компании, часто входят в один и тот же инженерный отдел, в котором находится команда разработчиков продукта. Из-за этого некоторые компании пытаются интегрировать людей из этих команд в свой процесс схватки. Но структура организации не должна влиять на потребности скрам-команды.
Если нет веских причин, может быть плохой практикой пытаться интегрировать инженеров по эксплуатации в команду разработчиков. Несмотря на то, что сотрудники отдела эксплуатации являются квалифицированными инженерами, обязанности, которые они выполняют, должны зависеть от процесса разработки продукта. Поддержание сетей, работающих компьютеров и серверов в сети постоянно и сложно, иначе как разработка продукта. Может быть опасно путать эти роли [1] .
Всегда важно информировать Операции о ходе разработки продукта, чтобы можно было рассмотреть любые изменения в продукте, которые могут повлиять на надежную доступность услуг и ресурсов. Хорошая команда разработчиков включает инженеров и владельцев продуктов, которые могут понять, когда изменения могут повлиять на нагрузку на систему или сеть, и обратятся к мнению квалифицированных инженеров по эксплуатации, чтобы помочь с планированием истории.
Примечание: операции и парное программирование
Может быть нецелесообразно отвлекать специалистов по эксплуатации от их обязанностей по объединению в разработку, хотя разработчикам может быть полезно время от времени взаимодействовать с инженерами по операциям, чтобы улучшить их понимание проблем, влияющих на доступность продукта.
Менеджеры
Одним из преимуществ scrum является то, что у команд есть возможность самоорганизоваться и найти лучший способ итеративной разработки продукта, тестирования, внесения изменений и улучшения по мере продвижения. Это означает, что команда берет на себя ответственность за то, что она делает, и организует себя вокруг цели завершить работу наиболее эффективным способом. В результате, иногда менеджеры могут быть смущены своей ролью в скрам организации.
Самоорганизующаяся природа scrum не имеет ничего общего с иерархией компании, которая назначает менеджера на другую роль и набор обязанностей по отношению к сотруднику. Scrum не должен иметь мнения об иерархии организации, так же как иерархия организации не должна влиять на процесс scrum.
В любой компании управление играет жизненно важную роль. Менеджеры несут ответственность за наем, увольнение, распределение ресурсов и представление сотрудников по всей организации. Без менеджеров сотрудникам было бы не к кому обратиться в случае, если есть проблема вне процесса разборки, которую необходимо решить. Менеджеры часто несут ответственность за продуктивность команды, в том числе за представление отчетов о результатах руководителям высшего звена и демонстрацию ценности процесса схватки во время его работы.
Менеджеры также могут участвовать в качестве разработчиков в команде Scrum. Часто люди на руководящих должностях в инженерном деле также имеют более глубокий опыт решения некоторых проблем, с которыми может столкнуться команда. Эти менеджеры могут выступать в качестве архитекторов или старших разработчиков и могут иметь ценные знания, которыми могут поделиться. В команде scrum менеджер рассматривается как один из разработчиков, и ему не предоставляются никакие другие полномочия, кроме как любому разработчику в команде.
Совет: менеджеры как разработчики
В некоторых организациях роль менеджера рассматривается с пренебрежением. Мы все видели образ заостренного босса из мультфильмов Дилберта. Одним из преимуществ scrum является то, что ему неважно, как менеджер работает вне процесса scrum, если для поддержки непрерывного процесса scrum предоставлено достаточно ресурсов. Эффективная команда Scrum должна действовать независимо от этих предвзятых мнений, но возможность работать с менеджером в качестве партнера в команде Scrum также может помочь улучшить коммуникации вне Scrum.
Сотрудники в команде, которые чувствуют себя некомфортно из-за того, что общаются со своим менеджером как коллега, или менеджеры, которые чувствуют себя некомфортно из-за того, что их авторитет в рамках схватки ограничен, должны обсудить эту проблему с мастером схватки. Сильный мастер схватки будет иметь опыт в решении вопросов, связанных с управлением и властью, и как это относится к схватке.
Остальной мир
Скрам-команда не работает в вакууме. За пределами скрам-команды есть организация, которая нуждается в разработке продукта по любой причине. Частью обязанностей мастера схватки является распространение ценности схватки для всей компании. Наряду с этим возникает ответственность за обеспечение того, чтобы scrum действительно служил потребностям компании и составляющих процесса scrum.
Среди этих составляющих — высшее руководство компании, пользователи разрабатываемого продукта, клиенты, которые, возможно, заказали создание продукта — будь то внутри компании или за ее пределами — и другие группы внутри компании.
Снаружи схватка может показаться загадкой. Несмотря на акцент на прозрачность, терминология scrum может сбить с толку людей, которые не знакомы с тем, что на самом деле означают эти термины. Может показаться, что артефакты и графики, создаваемые Scrum, означают, что их просто нет. Любая путаница со стороны команды Scrum может повлиять на стабильность Scrum, как с точки зрения распределения ресурсов, так и потока историй в процессе.
пользователей
Одна из наиболее очевидных составляющих команды Scrum — это набор пользователей, для поддержки которых разрабатывается продукт. Пользователь должен быть виден практически в каждой истории, даже если история не влияет на интерфейс интерфейса веб-сайта или не отображается на экране мобильного устройства. Административные пользователи — это пользователи. Контент-менеджеры, которые заполняют продукт, являются пользователями. Любой, кто взаимодействует с продуктом, является пользователем.
Для пользователя тот факт, что продукт был разработан с использованием процесса схватки, не имеет значения. Тем не менее, пользовательское тестирование является важной частью итеративной разработки. Большая часть разборок происходит в организациях, которые используют методы бережливого развития. Это означает, что нужно начинать с минимально жизнеспособного продукта, а затем повторять, как показывает тестирование пользовательского опыта.
Инструментарий, обеспечивающий эффективный учет и отслеживание взаимодействия с пользователем, обычно важен для веб- и мобильных продуктов, разработанных с использованием подхода scrum. Без инструментов для отслеживания кликов, жестов, целей и взаимодействия с критическими функциями у владельца продукта будет меньше точек данных для справки, когда придет время решать, над какими историями наиболее важны дальнейшие работы. Целью Scrum является поддержка гибкого процесса, который позволяет быстро регулировать направление продукта в зависимости от реальных потребностей пользователя.
Клиенты
Заказчик продукта, разрабатываемого с помощью Scrum, может быть клиентом компании или внутренним отделом внутри компании. Независимо от этого, непосредственное взаимодействие с клиентом является обязанностью владельца продукта. Сильный владелец продукта защитит команду от клиента и защитит клиента от чувства отсоединения.
Клиенты могут или не могут знать, что они хотят. Зачастую у клиента появляется идея, и ее необходимо проработать в процессе схватки. Это может означать несколько раундов работы с дизайнерами и, возможно, несколько итераций в процессе разработки продукта. В результате желаемый путь от видения к реальности может оказаться не таким прямым, как может пожелать клиент. Владельцы продукта вмешиваются, информируя и удовлетворяя клиента, в то же время проясняя взгляд клиента до такой степени, что команда может оценить его и работать над ним продуктивно.
Хороший владелец продукта — это сильная линия защиты между командой и хаосом прямого взаимодействия с клиентом. Это нелегкая задача, так как клиент либо оплачивает счета, либо работает в другом отделе той же компании. Может понадобиться поддержка сильного мастера схватки, чтобы помочь защитить команду схватки. Если команда чувствует, что получает слишком большое прямое влияние со стороны клиента — который не проходит через владельца продукта должным образом — они должны смело привлекать мастера схватки, чтобы помочь улучшить процесс.
Руководители и другие сотрудники
Скрам-мастер является одновременно тренером и евангелистом, когда дело доходит до остальной части компании. Мастера Scrum должны уметь эффективно представлять силу и ценность схватки и объяснять ее словами, которые не зависят от пользовательского словаря схватки. Этот процесс будет привлекать интерес не только других сотрудников, но и руководителей, которые будут справедливо обеспокоены предоставленной стоимостью.
К счастью, scrum генерирует много данных. Среди артефактов схватки будет реальная информация о том, сколько работы команда может выполнить за данный промежуток времени, сколько историй было завершено, какие функции были созданы, работающее программное обеспечение для демонстрации и отзывы команды владельцы продукта и клиенты. Мастер схватки может выбрать составление отчетов для разных аудиторий, проведение обедов в коричневых пакетах для объяснения схваток или приглашение людей на ритуалы схватки, чтобы самим увидеть, что происходит.
В то время как менеджеры несут ответственность за обеспечение ресурсами, необходимыми для поддержки своих сотрудников, мастер скрамов отвечает за получение поддержки и организационную поддержку процесса скрам. Если схватка идет хорошо, каждый в команде будет евангелистом. Поощряйте участников scrum, чтобы другие сотрудники знали, как это работает. Позитивные из уст в уста о компании хорошо для карьеры всех в команде Scrum, а также стабильность процесса схватки.