Понимание ролей в гибкой разработке / Всегда ли PO прав?

Пока PO достаточно ответственен, чтобы взять на себя вину в случае отказа продукта, это не должно вызывать беспокойства. Команда проекта будет обеспокоена, если PO свалит всю вину за неудачу продукта на разработчиков и проектировщиков. Будут разногласия во мнениях. Когда PO требует, чтобы что-то было сделано определенным образом, единственный способ предотвратить это, если эксперты в команде думают иначе, — это сообщить, что может быть и что есть, и максимально подробно объяснить различия и за и против. Любой гибкой команде требуется время для стабилизации и достижения хорошей скорости.

Тестирование

Работа по тестированию в agile-проекте ложится на всех членов команды. Имеет смысл иметь в команде специального инженера-испытателя. Но когда они начинают перегружаться работой, другие члены команды, особенно разработчики. Фактическая проверка, внесение изменений и их тестирование должны быть частью процесса проверки кода. Это может быть немного больше усилий, но это приводит к повышению качества и меньшему количеству циклов тестирования/исправления/тестирования с преданными QA людьми.

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

Задача владельца проекта — сообщить команде, что должна делать программа, а не как. В частности, для экстерналов нередко бывает, что ПО может дать несколько советов о том, как должны быть определенные вещи. Но последнее слово о том, как что-то работает, должно быть за экспертами команды. Например, если PO предлагает поместить 1 ТБ данных в Excel, команда должна отказаться и вместо этого использовать подходящую базу данных.

В случае с UX это становится немного сложнее. Внешний вид приложения зависит от того, что и как. Часто это больше связано со вкусом и изученными моделями использования. Здесь это помогает сделать юзабилити-тестирование. Если вы не можете провести надлежащий внешний юзабилити-тест, найдите людей внутри компании, которые соответствуют ожидаемым пользователям, и покажите им приложение. Результаты юзабилити-тестирования должны превалировать как над разработчиками, так и над заказчиком.

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

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

Одна роль, о которой я не упоминал в вопросе, — это роль Scrum Master (SM). Роль СМ двояка:

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

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

Почему нет решения? Решение очевидно. Если у товарища по команде так много дел, что он становится узким местом, вы помогаете ему . Это означает, что за тестирование отвечает вся команда разработчиков, как и должно быть.

Но разве у UX-команды нет никаких прав в agile-команде?

На самом деле, они не делают. Потому что в Scrum нет такого понятия, как «команда UX». Есть PO со своим видением, и есть команда разработчиков, способная реализовать это видение. Предполагая, что команда разработчиков состоит из экспертов по UX, тогда, когда истории будут доработаны, может возникнуть оживленная дискуссия о том, должна ли функция содержать конкретный UX, но, в конце концов, PO решает, как они хотят, чтобы продукт выглядел. Задача команды разработчиков — помочь с этим решением, представив опыт и указав «затраты» (или время разработки) каждого варианта. Но если PO хочет, чтобы продукт мигал розовым, то это их решение.

Я не буду цитировать остальные ваши вопросы построчно, но позвольте мне спросить вас кое-что: имеет ли команда разработчиков право голоса, сколько уходит на спринт? Потому что это единственная проблема, которую я вижу в том, что вы описываете.

Планирование спринта — это совместный процесс. PO не может включить в спринт что-то, с чем не согласна команда разработчиков. Для начала обычно спринты настраиваются автоматически в зависимости от скорости . По сути, вы смотрите, что вам удалось в последних спринтах, и основываете на этом свой текущий спринт. Итак (очень упрощенно), если вы сделаете только 4 истории из 10, следующий спринт вы начнете только с 4 и, надеюсь, закончите все. И тогда команда разработчиков и PO могут это скорректировать. Но только вместе . Узкие места или нехватка рабочей силы — это не проблема команды разработчиков. Они будут работать в меру своих возможностей. Что продукт не готов так быстро, как это нужно заказчику? это ЗПпроблема. И если они не могут получить больше ресурсов от руководства, руководству придется мириться с тем, что продукт опаздывает.

В Scrum не так-то просто разобраться. Это выглядит просто, но это больше, чем просто руководство. Я бы посоветовал вам найти хорошего Scrum-коуча или очень опытного Scrum-мастера, который поможет вам пройти этот переход. Вам также необходимо одобрение руководства. В действиях, а не в словах. Если у вас этого нет (а вы намекнули на это), вы обречены на провал. Scrum — это не массовое движение. Вы не можете использовать Scrum против своего руководства. Потому что это совместный процесс, и если руководство не играет в мяч, это не даст качественных результатов. И это вернется на круги своя, когда руководство увидит плохие результаты и скажет: «Видишь, это не работает», хотя на самом деле они были теми, кто в первую очередь привел к провалу.

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

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

Нет понимания управления для гибкой разработки

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

Заказ на поставку, который не учит руководство тому, что вам нужно больше людей и ресурсов

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

Неоднозначный взгляд на PO, но также и на гибкие отделы.

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

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

Скрам-команда/Скрам-мастер: команда отвечает за работу над наиболее приоритетными темами из бэклога продукта. Они также несут ответственность за определение того, сколько времени занимают задачи разработки, и за организацию работы в команде. Все члены команды должны быть техническими специалистами, и каждый должен уметь выполнять задачи разработки. Это включает в себя тестирование и задачи, связанные с контролем качества. Многие организации нанимают «тестировщиков» отдельно от «разработчиков» (часто менее оплачиваемых), и, похоже, это имеет место в вашей организации. С точки зрения реальной гибкой команды это различие не должно быть сделано, и разработчик должен иметь возможность писать тесты для ПО, которое разрабатывает его команда. В идеале стимулировать следует всю команду, а не отдельных ее членов.

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

Скрам-команда не должна состоять более чем из 5-10 человек. Если он больше, его следует разбить на несколько команд.

Действительно ли ЗП всегда прав?

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

Может ли ПО также решить навредить команде?

Это абсурдный вопрос, и ответ должен быть очевиден.

Ретро не работает, потому что нет решений. Другие основные проблемы не могут быть решены.

Ретроспективная обратная связь должна быть в основном для внутренней организации Scrum-команды, но если есть предложения руководству, они должны быть задокументированы и отправлены в письменной форме ответственным менеджерам (с CC высшим менеджерам, если никакой реакции/ответа не происходит).

Команда чувствует себя преданной как со стороны PO, так и со стороны руководства. Это приводит к гневным реакциям.

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

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

В дополнение к непосредственному чтению agile-манифеста я рекомендую посмотреть речь прагматичного Дэйва «Agile is Dead» или прочитать его запись в блоге . С этим и небольшим количеством здравого смысла, вероятно, нет необходимости в тренере или консультанте по Scrum.