Как скрам-мастер должен решать я или команда решает, нужен ли им тестировщик?

Много комментариев делается о размере команды и ролях в ней, поэтому я пропущу это.

Мой совет (с большинством вопросов, проблем или чего-то еще): обратитесь к команде.

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

Не говорите о команде и их потребностях, разговаривайте с командой

Как скрам-мастер должен решать я или команда решает, нужен ли им тестировщик?

Так говорят традиционные менеджеры проектов, а не скрам-мастера.

Если члены вашей команды считают, что тестер поможет, и им нужен тестер, им следует иметь тестировщика. Команда решает.

Это прямо отвечает на ваш вопрос в заголовке. Теперь я скажу несколько вещей о том, что вы упоминаете в остальной части вашего поста.

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

Похоже, что команда отлично справляется с тестированием без нее, и это направление организации, то есть каждая команда должна совместно проводить тестирование. Что я предпочитаю.

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

Я уверен, что команда согласится на наличие тестировщика, но это идет вразрез с созданием кросс-функционалистов.

Кросс-функциональность не означает, что все делают все. Кросс-функциональность в Scrum означает, что команда обладает всеми навыками, необходимыми для создания продукта. Команда в целом. Это не означает, что разработчикам также нужно выполнять работу тестировщика. Могут, но это не должно быть обязательным. Подумайте об этом, User Researcher, который не занимается ни программированием, ни тестированием, также мешает созданию кросс-функционалистов. Что вы собираетесь сделать сейчас, чтобы создать кросс-функционалистов?

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

Скрам-мастер несет ответственность за то, чтобы команда следовала Scrum, но добавление тестировщика в команду не противоречит Руководству по Scrum .

Тем не менее, руководство по Scrum рекомендует сохранять размер команды до 9 или меньше, поэтому стоит обсудить это с командой. Хорошим подходом было бы следить за проблемами, связанными с размером команды, такими как сбои связи.

Я уверен, что команда согласится на наличие тестировщика, но это идет вразрез с созданием кросс-функционалистов.

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

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

Возможно, будет полезно переформулировать вопрос. Вместо этого мы можем спросить: « Есть ли у моей команды навыки в области качества, необходимые для создания приращения продукта? » Вы можете подумать, что знаете ответ на этот вопрос, и, возможно, вы даже правы. Впрочем, это вопрос к команде.

В Руководстве по Scrum о команде разработчиков говорится следующее:

Они самоорганизуются. Никто (даже Скрам-мастер) не говорит Команде Разработки, как превратить Бэклог Продукта в Инкременты потенциально выпускаемой функциональности;

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

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

Красный флаг, который у меня есть о потребности в другом человеке, двоякий:

1. Мы не должны путать людей с навыками. Команде нужно умение. Простое добавление людей для каждого навыка может дорого обойтись и может усилить узкие места.

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

Теория против практики

Хорошо, все это было очень много теории и размышлений. Итак, каков практический ответ? Если бы я был на вашем месте, я бы предпринял следующие шаги:

1. Определите, есть ли проблема с качеством. Поделитесь своими наблюдениями с командой. Помогите им проверить ожидаемый уровень качества с PO и организацией (и с клиентом, если это возможно).

2. Если ответ «Да, есть проблема с качеством», определите, какие навыки и поведение необходимы для ее решения. Опять же, это упражнение, которое мы проводим вместе с командой.

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

4. Освободите место для этого. Вот где ваша работа усложняется. Если № 3 не обнаружит что-то подходящее, вашей команде может понадобиться помощь других команд, других частей организации или множество других вещей, даже если вам не нужен еще один человек (а если вам это нужно, есть процесс, который нужно начать для это тоже).

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

   Я надеюсь, что это не слишком грубо, но для того, чтобы это произошло, в команде есть Scrum Master. Это большая часть того, что заставляет Scrum работать. И как это сделать, практически невозможно указать в ответе Stack Exchange (извините).

5. Делайте потрясающие продукты! Отмечайте хорошо выполненную работу.

Эта статья Майка Кона во многом отвечает на мой вопрос:

https://www.mountaingoatsoftware.com/blog/self-organizing-teams-are-not-put-together-randomly

«Руководство осуществляет тонкий контроль над самоорганизацией

В оригинальной статье, описывающей Scrum, Такеучи и Нонака назвали «тонкий контроль» одним из шести его принципов. Они перечисляют кадровые решения как ключевую ответственность руководства.

Выбор подходящих людей для проектной команды при одновременном наблюдении за изменениями в групповой динамике и добавлении или исключении членов при необходимости [является ключевой обязанностью руководства]. «Мы бы добавили в команду более старшего и более консервативного члена, если бы баланс слишком сильно сместился в сторону радикализма», — сказал один из руководителей Honda. «Мы тщательно выбираем участников проекта после долгих размышлений. Мы анализируем разные личности, чтобы увидеть, поладят ли они.

Привлечение нужных людей в Agile-команду

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

Включите все необходимые дисциплины в Agile-команды

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

Сочетание уровней технических навыков в Agile-командах

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

Баланс знаний предметной области в Agile-командах

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

Ищите разнообразие в Agile-командах

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

Подумайте о настойчивости при формировании Agile-команд

Членам гибкой команды требуется время, чтобы научиться хорошо работать вместе. Поэтому стремитесь сохранить вместе членов команды, которые хорошо работали вместе в прошлом. При формировании новой команды подумайте, как долго ее члены смогут работать вместе, прежде чем некоторые или все будут рассредоточены по другим делам».

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

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

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

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

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