Scrum - Чем заняты члены команды во время спринта

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

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

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

1) Пусть члены команды решают, что делать, когда у них нет задач.

Минусы:

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

2) Освободите место в спринте только для разработки и начните тестирование после завершения спринта (когда разработчики начнут работать над функциями из следующего спринта)

Минусы:

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

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

В начале спринта пока нечего тестировать

В самом деле? У вас нет требований для проверки? Нет обсуждений с вашим клиентом? Нет каркасов для оценки? Нет планов испытаний думать о?

в конце спринта, как правило, ничего или очень мало осталось для разработки / исправления

Я никогда не был в этом месте в проекте. Больше нет работы? Всегда есть что-то Все ли ваши тесты полностью автоматизированы? Как выглядит ваш КИ? Может ли уровень доступа к базе данных быть реорганизован для упрощения? И я никогда не работал над чем-либо с пустым списком ошибок и отставанием. Что ваши разработчики делали на этапе тестирования водопада?

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

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

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

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

Еще один момент, поднятый @Cort Ammon в комментариях. Гибкий манифест говорит о сотрудничестве с заказчиком, а не о заключении договора Вы говорите, что:

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

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

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

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

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

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

Однако в каждой команде, в которой я был, всегда много работы. Позвольте мне решить пару ваших конкретных проблем:

В начале спринта пока нечего тестировать,

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

в конце спринта, как правило, ничего или очень мало осталось для разработки / исправления

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

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

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

Освободить место в спринте только для развития,

Этот подход не входит в традиционное определение scrum или agile. Весь смысл Agile в том, что вся команда вовлечена в работу по достижению общей цели. Это означает, что вся работа, необходимая для завершения рассказа, должна быть представлена ​​в спринте - дизайн, разработка, тестирование, документация и т. Д.

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

Цель - это цель команды , но вы пишете так, как если бы у каждого человека были свои цели («завершите мои задачи»). Если кому-то нечего делать, они могут увидеть, над чем в настоящее время работают, и предложить помощь. Или они могут взять следующую задачу или историю и начать работу над ней.

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

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

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

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

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

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