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