Scrum - разработчики, работающие вне Sprint

12

Скрам Команда

3 х Разработчики
2 х Тестеры
1 х аналитик автоматизации тестирования

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

В настоящее время мы делаем двухнедельные спринты.

В начале спринта все заняты, разработчики начинают работу по разработке, а тестеры готовят тесты (пишут тестовые примеры и т. Д.)

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

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

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

Считается ли это проблемой в схватке? Есть ли этому решение? Скрам работает только с многофункциональными командами?

Я хотел бы узнать опыт других людей с этим, если это возможно :)

agile scrum

— FML
источник

3

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

— Роберт Харви

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

— Blrfl

3

Практично ли создание гибридной пары / тестовый гибрид? В некотором смысле процесс такой же, как и цикл модульного тестирования; написать немного теста немного. У нас не было этого формально, но тестеры имели обыкновение приходить к нам напрямую, поскольку была найдена ошибка или два. Мы не общались через официальные сообщения об ошибках. К тому моменту, как «мой тестер» закончил тестирование, я уже починил. Быть веб-приложением сделало исправление исправления эффективным. Но, по крайней мере, эксперимент. И, честно говоря, даже если это не лучше или хуже, MGT будет воспринимать меньше индивидуального времени ожидания.

— Радар Боб

3

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

— Барт ван Инген Шенау

2

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

— Эрик Кинг,

16

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

Во-первых, я хотел бы отметить пару вещей, которые я считаю важными:

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

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

Для меня очень хорошо работают эти два инструмента:

Подчеркните принцип, что вся команда несет ответственность за выполнение работы. Откажитесь от историй «dev done», так как они дают разработчикам возможность сказать «больше не моя проблема», что не является конструктивным и явно ложным. Если команда не передает историю, которую они приняли, то это не вся команда, которая предоставила.
Чтобы занять время как разработчиков, так и QA, соедините их . На сегодняшний день это лучший способ обмена опытом и знаниями в предметной области, который вы можете выбрать. Разработчики могут помочь тестировщикам автоматизировать их задачи. Тестировщики могут показать разработчикам, где важно тестировать код, потому что он хрупкий. Оба сотрудничают и работают быстрее, чем нет.

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

— Sklivvz
источник

1

Спасибо за ваш ответ. Мне очень нравится идея объединения разработчика и QA ресурса. Я собираюсь предложить это на нашей следующей встрече, и мы надеемся, что мы сможем испытать это в следующем спринте. Я обновлю вопрос и дам вам знать, как это происходит!

— fml

@Sklivvz Это происходит чаще, чем когда есть отдел QA. Это происходит каждый раз, когда QA - это роль, которую могут выполнять только «определенные люди». Вместо того, чтобы незанятый ресурс забрал «следующую» высокоприоритетную задачу, разработчик бездействует, а затем выполняет больше работы, пока QA постоянно реагирует на вывод разработчика.

— Эдвин Бак

1

Если бы это не было ясно выше, «следующей высокоприоритетной задачей было бы» сокращение отставания QA, чтобы элементы могли быть отправлены », а не следующая высокоприоритетная задача разработки из отставания

— Эдвин Бак

1

Советы, такие как ответственность всей команды, в то время как звучит хорошо, на самом деле не служат команде. Это говорит о том, что все являются взаимозаменяемыми, и это недостаток всех, кто не ввязывается. Это неправильно. Каждый человек в SDLC играет определенную роль и провел ГОДЫ, оттачивая свои навыки. Попросить инженера-программиста провести тестирование наносит ущерб качеству, поскольку у него нет необходимого опыта для проверки качества, и, скорее всего, он предпримет нерешительную попытку. Даже если инженер QA наставляет их, наставничество отнимает время у тестирования и заставляет работать еще дольше.

— Чак Конвей

1

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

— Sklivvz

2

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

мы всегда развиваем следующую работу спринтов в текущем спринте

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

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

— Мартин Маат
источник

3

Проблема с такими утверждениями, как "Ого! Это технически невозможно в Scrum" и "... новые творческие способы, которые изобретают организации, чтобы саботировать Scrum", заключается в том, что они подразумевают, что существует правильный способ "делать Scrum". Чтобы быть правильным, Scrum должен быть наглядным, то есть ставить процессы перед людьми. Скрам, следовательно, не является гибким процессом, если есть правильный способ сделать это.

— Дэвид Арно

@ Дэвид Арно Это хорошо, вы говорите, что любая методология по определению не является гибкой. Даже проворный манифест. Только непредсказуемый хаос был бы проворен. Но подождите .. кто говорит мне быть хаотичным? Серьезно сейчас: Agile Adagium "люди до процессов" существует для разрешения конфликтов. Если нужно выбирать, нужно делать то, что имеет смысл, а не обязательно то, что говорят правила. Мне кажется, команда ОП могла бы без проблем пройти книгу «Скрам». И, возможно, они понимают, что ключевой вопрос - насколько они прозрачны.

— Мартин Маат

1

@DavidArno на самом деле, это только подразумевает, что есть определенные неправильные способы делать Scrum, и это кажется спорным. Например, все, что противоречит Agile Manifesto, кажется объективно неверным.

— Sklivvz

1

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

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

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

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

— Брайан Оукли
источник

0

Я думаю, что ключевая проблема здесь заключается в следующем:

большинство разработчиков считают, что тестирование ниже их

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

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

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

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

— Владимир Стокич
источник

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

— JeffO

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

— Владимир Стокич

0

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

Но на практике всегда есть какая-то специализация. Программное обеспечение может быть сложным, у члена команды разные навыки и т. Д. Разделение команды на разработчиков и тестировщиков - это только один (очень распространенный) пример специализации.

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

По моему опыту, вы могли бы сделать несколько вещей:

Не делайте команду слишком маленькой. Например, если у вас есть 4 разработчика и 4 тестировщика, гораздо проще перенести задачу на другого разработчика или тестировщика, чем при использовании только 3/2, как в этом примере.
Попробуйте разделить большие задачи. Если у вас есть более мелкие задачи, вы будете более гибкими.
Определите некоторые дополнительные задачи, которые можно выполнить, если осталось время.

Эти предложения могут не соответствовать теории SCRUM на 100%, но сначала вы должны продолжать работать над разработкой. SCRUM - это просто набор инструментов.

— Bernie
источник

0

Похоже, вам нужно десинхронизировать вашу команду. Как это:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

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

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

— Лукас
источник