Перешли на scrum, теперь разработчики занимаются только QA

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

Agile точно такой же.

Лучше всего было бы объяснить альтернативную стоимость — разработчики (как правило) стоят больше, чем выделенное обеспечение качества. Тем не менее, может случиться так, что ваши методы разработки некачественные, и вы создаете слишком много работы по контролю качества, и это «разработчики, подрабатывающие как контроль качества», делает две вещи.

1. заставить вас решить отставание по контролю качества
2. гарантируя, что вы не добавляете к отставанию по контролю качества

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

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

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

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

Утверждение, что QA является «частью схватки», на самом деле не имеет большого значения и здесь не очень уместно. Суть проблемы в том, что необходимо выполнить дополнительную работу по обеспечению качества.

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

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

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

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

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

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

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

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

Как я уже упоминал в комментарии к первоначальному вопросу, я думаю, что это способ руководства заявить о том, что он использует Agile, но на самом деле увековечивает Waterfall. В частности,

Мы тестируем новые варианты использования, о которых никто не думал

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