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

33

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

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

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

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

Минусы:

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

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

Минусы:

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

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

holdenmcgrohen
источник
9
Вы, кажется, влюбляетесь в миф
Натан Купер
1
@holdenmcgrohen Как делаются оценки - планирование покера или что-то еще?
Робби Ди
3
Тестеры должны писать тестовые случаи в первый день. Все, что им нужно сделать, это истории. Если у разработчиков есть значительное время простоя во время спринта, это означает, что вы не принимаете достаточно историй. Плюс, предположительно, если ваши тестеры хороши, они заставляют ваших разработчиков заниматься сообщениями об ошибках ближе к концу спринта. Кроме того, в идеале, у вас есть несколько лучших историй в отставании, так что в худшем случае разработчики могут работать с одной из лучших пар в отставании.
Gort the Robot
1
@holdenmcgrohen, мы также сталкиваемся с подобной проблемой в нашем проекте. Мы начали добавлять истории Stretch (не должны быть обязательно ) как часть спринта и выбираются только тогда, когда у разработчиков нет задач. Теперь этот подход помогает нам поддерживать занятость тестера в первые дни следующего спринта.
user6005214
1
Помните , что в большинстве спринтов вы выбираете подмножество задач из отставанию . Если вы выполнили все свои обязательства, вы получите преимущество на следующем спринте, начав работать над большим количеством элементов из бэклога - так же, как если вы перебегаете, вы вытягиваете меньше элементов из бэклога в следующем спринте. может закончить те, которые не были закончены. Дамп догмы; Осознайте, что цель инструмента - служить вам, а не служить вам.
Кешлам

Ответы:

49

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Уважайте свою команду, чтобы делать то, что они считают лучшим. Я бы сказал, что если вы смотрите много видео о кошках, то либо у вас плохие разработчики, либо вы плохо относитесь к ним.
  • Связь. Если ваши разработчики общаются друг с другом, с тестировщиками, с менеджментом, с заказчиком, то, вероятно, у всех должно быть хорошее представление о том, что будет дальше, а если нет, то они могут просто спросить.
Encaitar
источник
Да, да и да. Найди ответ во всех отношениях.
Дэвид Арно
Хороший ответ - последний абзац нуждается в работе. Поднимите и объясните вопросы здесь, а не указывайте на какой-нибудь том.
Робби Ди
1
Что ваши разработчики делали на этапе тестирования водопада? - Я не хотел сравнивать схватку с watefall, а скорее с подходами, подобными канбану, где всегда есть список дел, которые уже оценены и расставлены по приоритетам. Жалоба Scrum содержит функции, которые не были должным образом изучены группой, поэтому, если один разработчик (у которого в настоящее время нет функций для работы) решит начать реализацию одного из них в середине спринта, это может привести к неожиданным последствиям. ,
holdenmcgrohen
@ holdenmcgrohen достаточно справедливо. Мои оценки всегда ужасны, и я стараюсь их учитывать, поэтому мне всегда нравится что-то делать дальше. Я думаю, что ежедневные дежурства и спаривание могут помочь в этом, если ваши разработчики не останутся в одиночестве слишком долго, они не смогут слишком долго уходить.
Encaitar
@Encaitar Отличный материал +1
Робби Ди
20

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

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

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

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

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

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

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

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

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

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

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

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

Брайан Оукли
источник
1
+1. Гибкие процессы требуют провисания. Чтобы оптимизировать систему, вам часто приходится де-оптимизировать подпроцессы. В этом случае вы сказали это лучше всего с помощью «оптимизации команды». Все остальное является признаком ошибки использования.
CodeGnome
В начале своей карьеры я столкнулся с некоторыми компаниями, которые ожидали, что кандидат будет работать со всеми PHP, Java, C #, настольными приложениями (VB), QA (автоматизированные, ручные), Photoshop, CSS и так далее. В то время индустрия считала эти компании менее профессиональными из-за специализации. Интересно, получит ли тот же шаблон признание (даже необходимость) под Agile.
kuldeep.kamboj
1

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

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

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

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

Робби Ди
источник
8
Прочитайте Руководство по Скраму . Возможно, вы найдете то, в чем говорится, что можно разделить команду разработчиков на тестеров и разработчиков (подсказка, вы не будете).
Натан Купер
3
В документе не говорится, что у вас есть члены команды разработчиков со специализацией, но вы не можете разделить группу на «куры».
Натан Купер
5
Для опущенных избирателей, какую часть Agile-тренинга вы пропустили, где указано, что вы должны принять стратегию, которая работает для вашей команды ? Команда Робби Ди переняла то, что им помогало в их уникальных обстоятельствах с их уникальным проектом и экологическими ограничениями. У каждой компании есть экологические барьеры и «ущерб», которые необходимо обойти. Это кажется вполне приемлемым подходом к вопросу, который был задан . Вопрос не был в том, как организовать тестировщиков и тестирование в вашей спринтерской команде.
maple_shaft
4
Нет. ОП специально спрашивал о Scrum. Вы не можете делать все что угодно и называть это Scrum. Это может быть или не быть гибким, но то, что части вашей кросс-функциональной «команды» рассматриваются как внешние ресурсы или как что-то отличное от первоклассных членов команды разработчиков, не является Scrum.
CodeGnome
2
@CodeGnome абсолютно прав, и затрагивает вопрос, который я всегда поднимаю: Agile - это философия, Scrum - это реализация этой философии. Два не одно и то же, и соблюдать отдельные правила. (Да, Scrum появился первым, но позже был модернизирован для реализации Agile)
-2

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

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

nvoigt
источник
6
Т-образные люди - это одно, а тестеры пишут код (если мы не говорим об автоматизации тестирования) - это совсем другое.
Робби Ди
2
Это просто предполагает, что только тестеры имеют время простоя в спринте? У разработчиков также есть простои.
maple_shaft
Я предполагаю, что разработчики могут проводить тестирование без дальнейшего обучения. Где я живу, это часть образования и работы.
nvoigt