Понимание Scrum

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

Рассмотрим спринт в течение 4 недель, а отставание - 10 предметов. Пусть начинается спринт. Если разработчики работают над некоторыми элементами отставания в течение первых 10 дней, я не знаю, потребует ли тестирование (как SIT, так и UAT) ТОЛЬКО оставшиеся 10 дней для завершения работы. И теперь наш спринт не имеет времени для исправления ошибок в последнюю минуту, и только несколько ошибок могут быть исправлены в ПЛАНИРОВАННОЙ СПРИНТЕ.

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

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

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

Мне нужны некоторые рекомендации, ссылки или тематическое исследование, чтобы убедиться, что наша команда следит за надлежащим процессом Scrum. Любая помощь будет оценена.

Ответ 1

В идеальной команде Scrum тестеры и разработчики часть команды, и тестирование должно происходить параллельно разработки, фазы перекрываются, а не последовательно (делают вещи последовательно внутри Sprint - это анти-шаблон, известный как Scrumerfall). И, между прочим, вопреки некоторым мнениям, выраженным здесь, окончательная реализация Scrum создает истории DONE DONE, поэтому тестирование - включая IST, UAT - должно выполняться во время Sprint.

И нет, тестерам не нужно дождаться, когда элементы резервного продукта (PBI) будут полностью реализованы, чтобы начать выполнять свою работу, они могут начать писать сценарии приемочных испытаний, автоматизировать их (например, с помощью FitNess), настроить тестовые данные set и т.д. (это занимает некоторое время, особенно если бизнес сложный), как только начинается Sprint.

Конечно, это требует очень тесного сотрудничества и освобождения интерфейсов или скелетов UI на ранней стадии, что облегчит работу тестировщиков, но, тем не менее, тестировщикам не нужно ждать полной реализации PBI. И на самом деле, приемочные тесты должны использоваться разработчиками как индикатор DONEness ( "Я знаю, что я закончил, когда проходят приемочные тесты" ) ¹.

Я не говорю, что это легко, но то, что делают зрелые (то есть Lean) Scrum-реализации и зрелые команды Scrum.

Я предлагаю прочитать Scrum And XP из траншей Хенриком Книбергом, это очень хорошее практическое руководство.

_{¹ Как пишет Мэри Поппендик, работа тестеров должна быть предотвращать дефекты (существенные), а не находить дефекты (отходы).суб >}

Ответ 2

Вы определенно не хотите делать все развитие в первой половине спринта и во всех тестах во второй половине. Это только меньший водопад.

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

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

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

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

Ответ 3

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

Ответ 4

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

Это только в конце концов, как только вы определили скорость команды (т.е. сколько историй, которые можно разумно выполнить в спринте), вы можете начать оценивать даты и вещи для крупных проектов.

Ответ 5

Прежде всего, не каждый Sprint выпускает Big Release (если вообще). Для первых спринтов вполне приемлемо создавать ранние прототипы/альфа-версии, которые, как ожидается, не будут содержать ошибок, но все же способны продемонстрировать что-то для клиента. Это может быть даже не особенностью - он может быть просто скелетным пользовательским интерфейсом, чтобы пользователь мог видеть, как он будет выглядеть и работать.

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

Ответ 6

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

Ответ 7

Попробуйте сделать непрерывную интеграцию. Команда должна войти в эту привычку и непрерывно интегрироваться. Кроме того, автоматическая компоновка unit test, созданная и выполняемая после каждой проверки/доставки, должна обеспечивать определенный уровень доверия к вашей базе кода. Эта практика обеспечит, чтобы команда всегда работала и работала в нормальном состоянии. Также это позволит интегрировать и проверить систему в начале спринта.

Определение и создание (автоматизированное) приемочных испытаний позволит людям с первичными навыками QA/тестирования заняться и участвовать прямо с начала спринта. Убедитесь, что это сделано в сотрудничестве с Product Owner (s), чтобы все были на одной странице и были задействованы.

Ответ 8

Мы начали наш гибкий проект с разработчиков сначала (много обучения в Enterprise Framework и т.д.) в первом спринте. Затем мы добавили QA медленно во второй спринт. В конце спринта 2 QA начал тестирование. Закрытие в конце спринта 3 QA подняло темп и где более или менее вместе с разработчиками. Из спринтов 4 и вне QA более или менее выполняется с тестированием, когда разработчики завершили рассказы. Элементами, которые обычно оставляют для тестирования, являются большие слоны, которые включают репликацию данных между новой и старой системой. И это скорее "проверка данных в порядке", а не фактические тесты.

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

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

Я вижу, что Паскаль пишет о зрелых командах спринта + определение Done. И гибкость всегда фокусируется на "доставке сразу после того, как спринт достиг своего конца". Однако - я не уверен, действительно ли очень много команд в мире делают это? Мы, по крайней мере, еще не там:)

Ответ 9

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

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

Определите DoD в начале проекта и продолжите его уточнение. Одновременно работайте над одной задачей и ограничивайте незавершенную работу. Работайте в порядке приоритета и сократите количество отходов в вашей системе. Не отправляйтесь на подробное предварительное планирование и откладывайте свои лучшие решения до наименее ответственного момента. Внедрите технические компетенции, такие как BDD и Automation.

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