Я руководитель проекта в команде, состоящей из сотрудников, которые были наняты специально для обеспечения качества или разработки до того, как организация приняла Agile/Scrum. Просто для справки: я пришел в организацию после внедрения схватки.
Проблема, с которой мы сталкиваемся, заключается в том, что в разное время во время спринта члены команды объявляют, что у них нет работы. Есть еще много вещей, которые еще не «сделаны», но либо кто-то уже работает над ними, либо они не находятся в той фазе, за которую человек считает себя ответственным — у разработчиков нет работы, потому что все находится в QA или наоборот. . Раньше они просто вытягивали больше элементов из бэклога продукта — никаких командных обязательств, никаких обсуждений, им разрешалось просто добавлять что-то еще в спринт. Этому я немедленно положил конец, объяснив это тем, что они брали на себя обязательства за всех остальных в команде, не спрашивая их заранее. Я также должен упомянуть, что команда редко выполняет свои первоначальные обязательства, установленные при планировании, не говоря уже о дополнительных элементах,
Им объяснили идею единой команды, работающей вместе, чтобы все было «сделано», но разработчики говорят, что они не были наняты для QA, а QA говорит, что разработчики просто мешают им, когда они пытаются помочь с задачами QA. и они не понимают, как правильно тестировать с точки зрения контроля качества. Я также объяснил, что разработчики не обязательно должны тестировать, а тестировщики не обязательно должны разрабатывать, но вся команда должна работать (через самоуправление) либо над тем, чтобы «сделать» выделенные элементы, либо над тем, чтобы что-то делать. чтобы принести пользу команде в будущем (обновление документов, обслуживание систем сборки/CI, улучшение автоматизированного тестирования и т. д.). Несмотря на это, мы по-прежнему получаем членов команды, говорящих, что им нечего делать, и они хотят получать новые элементы из резерв продукта.
Я чувствую, что на самом деле они говорят следующее: 1. В этом спринте не осталось ничего, что я ХОЧУ сделать. 2. Я действительно хочу получить фору, чтобы у меня было меньше работы в следующем спринте.
Мне, как руководителю проекта, никто из членов команды не подчиняется напрямую. Я обсудил это с их менеджерами индивидуально, и хотя они согласны с тем, что это проблема, они считают, что не могут форсировать это.
Наиболее прямым следствием этого является то, что QA постоянно отстает. Когда мы начинаем спринт, уже есть несколько элементов, готовых для контроля качества. Пока они работают над этими задачами, вещи накапливаются, и в конце спринта мы получаем гигантский набор задач в QA, а разработчики говорят, что им нечего делать. Конечно, когда элементы не завершаются за спринт, приходит следующий спринт, и проблема становится все хуже и хуже, поскольку QA не успевает.
Кто-нибудь видит здесь какие-либо действия? Заранее спасибо.
Не думаю, что на этот вопрос будет простой ответ.
С моей точки зрения, решающими факторами являются:
У меня есть пара вопросов:
Если бы я был на вашем месте, я бы сначала оценил последствия и убедился, что заинтересованные стороны чувствуют достаточно боли, чтобы поддержать некоторые изменения. (если нет, то нужно обсудить другую проблему).
Затем я начал измерять технический долг. В среднем проскальзываем x QA задач; на решение средней задачи QA уходит X часов. Создайте метрику, сообщающую заинтересованным сторонам/линейному руководству по этой метрике еженедельно/ежемесячно/(период, соответствующий вашим спринтам).
Теперь нам нужно изменить отношение разработчиков и тестировщиков. Они не работают вместе как команда. Во-первых, нам нужно убедиться, что мы, PM, обеспечили мотивацию/лидерство. Объяснили ли мы ценность работы в команде? Есть ли стимулы для командной игры?
QA должен изменить свое отношение. QA не любит помощь, которую оказывают разработчики; это нормально, либо научите их, как оказывать полезную помощь, либо попросите менеджера проекта провести обучение, которое позволит им оказывать полезную помощь. Спросите QA, поможет ли переход на разработку через тестирование? QA, по-видимому, имеет некоторые процессы, которые нуждаются в улучшении. Отключите одного QA и пару разработчиков в автономный режим и попросите их изменить процесс QA, чтобы он (а) стал быстрее, (б) способствовал эффективной командной работе и (в) стал более эффективным. Спросите разработчиков, с кем из QA было легче всего работать? У какого QA лучший код-фу? У этого человека есть навыки, которые нужно передать остальным членам команды.
Разработчики не хотят заниматься контролем качества? Это нормально. Работайте с непосредственным руководителем, чтобы найти разработчиков, обладающих нужными навыками и желающих работать в команде. Спросите отдел контроля качества: «Кто был самым полезным разработчиком в этом спринте?» PM может распознать этого человека и убедиться, что линейное руководство знает, что вы цените этого человека как члена команды и хотите, чтобы этот человек участвовал в будущих проектах. Поведение этого разработчика напрямую связано со способностью ваших проектов укладываться в сроки и оставаться в рамках графика/объема/качества.
В конечном счете, единственный инструмент, который у вас есть, — это желание вашей заинтересованной стороны уложиться в срок. Сорванные сроки причиняют боль заинтересованным сторонам; ваша задача — перенаправить эту боль таким образом, чтобы это мотивировало к изменениям.
Судя по тому, что вы сказали, у вас есть серьезная проблема, которая требует изменений в мотивации, навыках и процессах. Конкретные детали вашей ситуации сделают эти изменения, по крайней мере, на порядок более трудными, чем то, что я беспечно описал выше. Если бы это было так просто, вы бы получали минимальную заработную плату.
Убедитесь, что ваши заинтересованные стороны знают, что есть проблема, что вы предпринимаете действия для ее решения и что вы не ожидаете, что проблема будет решена в этом или следующем спринте. Лучшее, что вы можете им пообещать, это то, что скорость роста технического долга будет замедляться на x% каждый спринт.
Наиболее прямым следствием этого является то, что QA постоянно отстает. Когда мы начинаем спринт, уже есть несколько элементов, готовых для контроля качества. Пока они работают над этими задачами, вещи накапливаются, и в конце спринта мы получаем гигантский набор задач в QA, а разработчики говорят, что им нечего делать. Конечно, когда элементы не завершаются за спринт, приходит следующий спринт, и проблема становится все хуже и хуже, поскольку QA не успевает.
Другой способ взглянуть на это так: ваши разработчики постоянно впереди. В любом случае у вас слишком много ресурсов с точки зрения разработчиков и/или недостаточно ресурсов с точки зрения контроля качества.
Вы можете решить эту проблему, изменив уровни ресурсов. Поговорите со своим спонсором проекта и узнайте, насколько важен общий график проекта с точки зрения бизнеса. Исходя из этого, получите согласие вашего спонсора на:
К сожалению, вы столкнулись с одной из ошибок в Scrum. По умолчанию предполагается, что люди хотят работать вместе, независимо от их предыдущих ролей или амбиций, и они более чем счастливы отказаться от них ради общего блага. Я не уверен, что существует универсальное решение, но вот несколько идей:
Скорее всего, у команды есть проблемы с пониманием основных принципов Scrum. Рекомендуемое решение — тренировать команду, набраться терпения и временно попытаться смириться с текущей ситуацией, пока не будут поняты эти принципы.
Велика вероятность, что разработчики работают быстрее тестировщиков, поэтому можно убрать ненужных тестировщиков и использовать их где-то еще, а можно создать две команды из текущей команды. При таком подходе вы создаете искусственное узкое место — количество тестировщиков — что даст вам больше информации о ситуации.
Поговорите со своим скрам-мастером, потому что именно он должен обострить эту проблему и попытаться найти решения и обучить скрам-команду. Что-то здесь не так.
Я видел настройки, в которых было две сдвинутые итерации: одна итерация для разработки и тестирования и одна только для тестирования — эта началась позже. Идея заключалась в том, что разработчики взяли на себя чрезмерные обязательства и сделали больше работы, чем они могут протестировать за одну итерацию, а дополнительная работа была протестирована только за одну итерацию тестирования. Это не было оптимальным решением, но у всех было чем заняться, и команда(ы) справилась – полностью протестированные пользовательские истории были продемонстрированы Владельцу Продукта.
Вы можете начать узнавать немного больше о Scrumban и постепенно переключаться с подхода, основанного на итерациях, на непрерывный подход, такой как XP + Kanban.
Уже есть отличный ответ от Марка С. Уоллеса, но я решил добавить еще кое-что.
Попробуйте немного сбалансировать систему, используя лимиты незавершенного производства.
На данный момент dev выполняет работу быстрее, чем QA может ее протестировать. Попробуйте установить предел незавершенной работы для процесса разработки, который будет подавать работу в QA со скоростью, с которой они могут ее завершить, вы избежите большого количества резервной работы на этапе QA. Вы также можете добавить ограничение незавершенного производства к шагу контроля качества, чтобы было ясно, когда контроль качества перегружен.
Например, если у вас есть 4 пары разработчиков, попробуйте установить предел незавершенного производства равным 3 на шаге разработки и предел незавершенного производства равным 2 на шаге контроля качества (1 в работе, 1 в очереди).
Это будет означать, что у ваших разработчиков будет свободное время, поскольку только 3 пары могут заниматься разработкой одновременно. Это может показаться плохой идеей, но, как правило, лучше оставить резерв в системе, чем продолжать выполнять работу, которую потом нельзя будет выполнить с помощью последующих шагов.
Разработчики в свободное время могут заниматься такими вещами, как устранение технического долга, всплесков, поддержка в реальном времени, анализ предстоящих историй и т. д., которые по-прежнему продуктивны, но не засоряют этап контроля качества.
Кроме того, заставляя их ничего не делать, чтобы внести свой вклад в спринт, в то время как их коллеги все работают над своими пословицами, чтобы закончить истории, я надеюсь, что профессиональная честность побудит их застрять в том, чтобы помочь с каким-то тестом!
Отличный набор ответов на данный момент. Я просто хочу добавить это:
Рекомендую книгу How Google Tests Software . Эта цитата резюмирует их цель сбалансировать разработку и контроль качества:
Качество не равно тесту. Качество достигается путем помещения разработки и тестирования в блендер и их смешивания до тех пор, пока одно не станет неотличимым от другого.
Это был мой опыт. В моей роли в YouView, где мы создавали пользовательский интерфейс для телевизионной приставки, у нас была отличная команда тестировщиков, но пока мы не сделали их частью команды разработчиков; работая с ними на семинарах по спецификациям до начала разработки и выпуская для них функциональные возможности на раннем этапе и часто для обратной связи, у нас были такие же дисфункциональные отношения, как и те, которые вы описываете.
По моему опыту, установление правильных отношений сотрудничества между разработчиками и тестировщиками имеет основополагающее значение для повышения качества производимого программного обеспечения.
Интересно, насколько сложны ваши средства автоматизированного тестирования. Если это не особенно хорошо, то инвестирование времени и усилий в эту область может принести реальную пользу, поскольку окупаемость будет быстрой и существенной. Вы указываете в одном из своих комментариев, что у вас есть месячный период регрессионного тестирования перед каждым выпуском: это действительно звучит очень важно, и хотя я не знаю вашу среду, кажется, что если бы это можно было сократить за счет агрессивной автоматизации вашего теста циклов, вы получите реальную пользу.
В своей книге «Управление гибкими проектами» Джим Хайсмит много говорит о «безжалостном автоматизированном тестировании» и заявляет: «Опыт показал, что самая большая разница между зрелыми и незрелыми agile-командами заключается в их приверженности безжалостному автоматизированному тестированию». Вы можете не совсем согласиться, но стоит задуматься о последствиях этого утверждения.
Другая тема из той же книги касается привлечения нужных людей. Это трудно сделать, и еще труднее выполнить, но у вас, кажется, есть некоторые проблемы с вашими людьми. Возможно, это еще одна ключевая область, на которой следует сосредоточиться, по крайней мере, в краткосрочной перспективе.
Удачи...
Я думаю, вы обнаружите, что это структурная проблема, не связанная с индивидуальным отношением или пониманием схватки. Всякий раз, когда я сталкивался с разработчиками, которые не хотят проводить тестирование, с тестировщиками, которые хотят, чтобы им принесли код на блюдечке, и так далее, это происходит потому, что они делают то, что им говорят, или то, что подразумевается обстоятельствами их работы.
Если разработчики не хотят тестировать, это может быть их менеджер или корпоративная культура. «Разработчики стоят больше, чем тестировщики, поэтому они должны заниматься разработкой, а не тестированием». Я слышал это от самих разработчиков, от их менеджеров, руководителей проектов и руководителей высшего звена. «QA в конечном итоге отвечает за качество». Я слышал это от тестировщиков, их менеджеров, руководителей проектов и руководителей высшего звена.
До тех пор, пока высшее руководство вашей организации по разработке (и выше) не сможет создать командно-ориентированную организацию, вы будете сражаться в этой битве.
В вашем случае менеджеры по персоналу кажутся сочувствующими. В этом случае я бы предложил проверить их поддержку... попросить их пересмотреть ожидания всех сотрудников в сторону более командного сотрудничества, а не индивидуального выполнения ролей. Вы можете перечислить ожидания, и они продают это. Или, если нет, вы приблизились к источнику проблемы и можете иметь другие доступные ресурсы для ее решения.
Google тестирует так, как они это делают, потому что их корпоративная культура поощряет гибкость сверху вниз. Большинство магазинов, в которых я работал или тренировал, не имеют такой роскоши — в конечном итоге мы повышаем гибкость организации. Медленно, но иногда работает.
Как сказал мой собственный тренер Ричард Лоуренс: сначала попытайтесь достичь рубежа, когда команда последовательно выполняет то, что взяла на себя. Затем строить на нем. Добавлю, что на это может уйти довольно много времени.
МСВ
Ночной человек
Дуг Б.
Охотник на оленей
Ночной человек
Охотник на оленей