Должны ли мы прекратить попытки делать Agile, если QA занимает 12 недель?

24

Кто-то в моей компании недавно предложил внести изменения в наш основной продукт, которые, по мнению наших менеджеров, должны инициировать то, что, по моему мнению, моя компания считает полным циклом обеспечения качества (т.е. тестирование всего набора продуктов с нуля). По всей видимости, для обеспечения полного цикла обеспечения качества нашего продукта требуется 12 недель. Моя проблема с этим заключается в том, что мы пытаемся сделать Agile (хотя, по моему мнению, в большей степени недооцененной) разработку. Мы сделаем целый набор спринтов, а затем выпустим релиз, который, я думаю, будет проходить вечно. Вопрос в том, действительно ли, если нашему QA потребуется 12 недель, чтобы выполнить свою работу, не должны ли мы просто отказаться от попыток сделать Agile? Какой смысл пытаться сделать Agile в такой ситуации?

Дэвид Хосье
источник
36
Я бы рискнул сказать, что если QA занимает 12 недель, то вы не «делаете Agile».
SingleNegationElimination
9
Если команда не несет ответственности за качество кода, который она производит, я бы тоже не назвал это гибким ..
merryprankster
1
@merryprankster Не могли бы вы уточнить свой ответ? Вы хотите сказать, что бессмысленно не иметь QA в составе команды и проверять качество как часть спринта? Или вы имеете в виду, что команда должна самостоятельно проверять качество до такой степени, что контроль качества должен быть практически бесполезным? Или, может быть, другое значение? Я не знаю правильных ответов здесь. Я просто ищу любой совет, который я могу получить, чтобы исправить ситуацию, которая, по моему мнению, ужасно сломана. Спасибо.
Дэвид Хосье
2
Я имею в виду, что команда должна владеть процессом качества. Они будут делать то, что нужно, чтобы убедиться, что качество достаточно хорошее. Это делает цикл обратной связи максимально коротким и делает его более личным. Качество не является внешней собственностью, это неотъемлемая часть развития.
merryprankster
2
Это становится чатом, так что это будет мой последний комментарий. Да, я согласен, что в реальном мире вы ограничены вашей средой. Кроме того, вы должны иметь возможность выбирать и выбирать способы работы. Тем не менее, я думаю, что это не правда, что гибкость чата - это гибкость во всех отношениях, а наоборот: ловкость требует дисциплины . Одним из важных аспектов гибкой разработки является сокращение петель обратной связи. Если у вас есть фаза QA вне итерации, обратная связь задерживается. Если команда не обращается к QA как к части итерации, они не являются гибкими. Команда может решить, как они проводят QA - это гибко - но команда должна это сделать.
merryprankster

Ответы:

21

Что ж, прямым ответом на ваш вопрос был бы Му, я боюсь - просто недостаточно подробностей, чтобы сделать обоснованное предположение, стоит ли вам прекратить попытки.

Единственное, в чем я уверен, так это то, что уровень гибкости должен определяться потребностями клиентов / рынка (о которых вы не сообщили).

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

Еще одна вещь, которую следует учитывать, - это какой уровень качества необходим для удовлетворения потребностей ваших клиентов / рынка?

  • Например, в компании, в которой я когда-то работал, мы обнаружили, что нам нужна новая функция в продукте, лицензированном у какого-либо поставщика программного обеспечения. Без этой функции мы сильно пострадали, так что да, мы действительно хотели, чтобы они были гибкими и доставляли обновления в течение месяца.
     
    И да, они оказались гибкими, и да, они выпустили это обновление через месяц (если их цикл обеспечения качества составляет 12 недель, то они, вероятно, просто пропустили его). И наша функция работала отлично - думаю, мы должны были быть совершенно счастливы? нет! мы обнаружили ошибку регрессии showtopper в некоторых функциональных возможностях, которые раньше работали просто отлично, поэтому нам пришлось столкнуться со старой версией.
     
    Прошел еще месяц - они выпустили еще одну новую версию: наша функциябыл там, но была та же ошибка регрессии: опять же, мы не обновились. И еще месяц, и еще один.
     
    В итоге мы смогли модернизироваться только через полгода, так много для их ловкости.

Теперь давайте посмотрим немного ближе на эти 12 недель, которые вы упомянули.

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

Например, вы рассматривали способы улучшить тестируемость вашего продукта?

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

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


обновление на основе разъяснений в комментариях

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

Отпускаемый релиз я вижу. Гектометр Хммм. Подумайте о том, чтобы добавить в свой Agile коктейль один или два снимка Lean . Я имею в виду, что если это не является потребностью клиента / рынка, то это будет означать лишь пустую трату (тестирование) ресурсов.

Я, например, не вижу ничего криминального в том, чтобы рассматривать «Спринт-энд-релиз» как просто контрольно-пропускной пункт, который удовлетворяет команду.

  • dev: да, это выглядит достаточно хорошо, чтобы пройти тестерам; QA: да, это выглядит достаточно хорошо для случая, если необходимо дальнейшее тестирование на отправку - и тому подобное. Команда (dev + QA) довольна, вот и все.

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

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

  • Я обычно думаю об этом с точки зрения Ferrari (как регулярный итеративный) против Land Rover (как Scrum).
     
    При движении по шоссе (и ваш проект, кажется, достиг этой дороги ), Ferrari чертовски бьет из Land Rover.
     
    Это бездорожье, где нужен джип, а не спортивная машина - я имею в виду, если ваши требования нерегулярны и / или если командная работа и опыт управления не так хороши, вам придется выбирать Scrum - просто потому, что регулярные попытки помогут вам застрял - как Ferrari застрянет на бездорожье.

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

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

  • Для этой стратегии следует иметь в виду проверяемую проверку того, что изменения локализованы там, где ожидается. Даже если это дойдет до побитового сравнения файлов для компонентов, которые не изменились, сделайте это, иначе вы не получите его. Дело в том, что за качество релизов отвечает QA, а не мы, разработчики.
     
    Тестер испытывает головную боль, чтобы убедиться, что неожиданные изменения не ускользнули, потому что, честно говоря, как разработчик, у меня достаточно других вещей, чтобы беспокоиться о том, что для меня важнее. И поэтому им (тестерам) действительно нужны веские доказательства того, что все под контролем с выпуском, который они тестируют для отправки.
комар
источник
1
Я думаю, что это, вероятно, лучший ответ в свете нашей нынешней ситуации. Для меня одна из самых важных частей Agile - выпуск в конце каждого спринта. Это подразумевает несколько вещей. Во-первых, должен быть проведен уровень тестирования, чтобы избежать ошибок, если вы думаете, что можете выпустить сборку для клиента. Во-вторых, при условии, что первое утверждение верно, возможно ли, что QA дублирует большую работу, которая должна была быть уже сделана во время разработки? Я думаю, что есть что-то, к чему можно обратиться, как в нашем QA, так и в нашей команде разработчиков (я разработчик).
Дэвид Хосье
Однако я не помню, чтобы мы когда-либо выпускали сборку для клиента после спринта. Кроме того, какова наша клиентская база, они не хотят часто выпускать полную версию продукта. Наши клиенты не спешат обновляться. Самый важный момент, который вы указали, заключался в том, что вы не использовали agile, если требования не являются agile. Я думаю, что это место. Когда мы начали работать гибко, мы подключились, и обстоятельства имели смысл. Но с тех пор все кардинально изменилось, и мы цепляемся за процесс, в котором он может больше не иметь смысла.
Дэвид Хосье
3
Наш полный продукт состоит из множества мелких деталей, которые могут быть обновлены независимо друг от друга. Я думаю, что наши клиенты очень хотят обновлять эти небольшие компоненты гораздо чаще. Мне кажется, что, возможно, нам следует сосредоточиться на выпуске и проверке этих небольших компонентов в конце спринтов. Мы могли бы сократить цикл обратной связи благодаря более целенаправленному подходу и быстрее доставлять прибыль клиентам. Тогда мы могли бы сделать полный выпуск продукта в какой-то момент, который обернет все мелкие кусочки. Тогда QA будет меньше делать, так как большинство уже проверено в предыдущих спринтах.
Дэвид Хосье
1
+1 Мне нравятся ваши примеры разных потребностей рынка. Можно привести более крайние примеры. Например, программное обеспечение контроллера для управления запусками космических ракет. Клиент может быть доволен обновлениями каждые пять лет (законы физики не сильно меняются), но одна ошибка регрессии может стоить сотни миллионов долларов .
MarkJ
14

О, я чувствую твою боль Чтобы это работало, нужно внести серьезные изменения в команду QA.

Мой совет - разделить команду на три команды:

Функциональное тестирование - быстрое восстановление новых разработок.

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

Автоматизированное тестирование - Написание полного набора регрессионных тестов для ускорения работы команды регрессионного тестирования.

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

прецизионный самописец
источник
+1 Автоматизированное тестирование - регрессионные тесты - главный кандидат.
Джошуа Дэвис,
Я думаю, что это очень хороший ответ. Я на самом деле не знаю, как организована команда QA или как они проходят тестирование. Наша команда QA находится в Индии, и я думаю, что это немаловажная часть проблемы. Из того, что я понимаю, их планы тестирования не публикуются, так что каждый может их просмотреть и проверить. Кроме того, из-за разницы во времени поворот времени между разработчиками и QA является ужасным. То, что должно занять час разговора за чьим-то столом, превращается в дни электронных писем или комментариев JIRA.
Дэвид Хосье
13

В качестве иллюстрации:

введите описание изображения здесь

Обратите внимание, что ваша команда QA, вероятно, работает за пределами круга (ATDD), а вы работаете внутри.

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

Роберт Харви
источник
2
Проблема в том, что вы получаете отчеты о дефектах от работы, выполненной 4-6 спринтов назад (при условии 2-3-недельных спринтов). В зависимости от политик и процедур обеспечения качества компании, им может потребоваться подписать спринт, прежде чем он будет передан заказчику. Так что, да, у вас есть потенциальные товары, которые можно отгружать после каждого спринта, но менее 25% из них попадут в QA (при условии, что, когда они закончат тестирование одного кандидата, они начнут тестировать самого последнего кандидата), так что вы сможете показывать покупателю продукт каждый раз несколько недель, но они могут получить только один раз в 12 недель, и это будет старше, чем они только что видели.
Томас Оуэнс
Правильно. Я только что обсуждал это с коллегой. Я бы сказал, что мы даже не делали правильных релизов в конце каждого спринта. Мы делаем сборку в конце каждого спринта, потому что Agile говорит, что вы должны это делать, но мы не собираемся, чтобы кто-либо когда-либо видел эту сборку. Я не знаю, получит ли QA эти сборки или нет, но могу заверить, что ни один клиент не увидит сборку в конце спринта. Только одна сборка потенциально официальная, и это та, что была в последнем спринте. На мой взгляд, это совсем не Agile вообще. Благодаря этому рабочему процессу Agile - это всего лишь способ организации работы.
Дэвид Хосье
Более того, я не помню, чтобы когда-либо получал отзывы от QA до окончания сборки из последнего спринта, как я упоминал выше. Это подтверждает вашу точку зрения. Я думаю, что это может привести к ситуациям, когда решения, которые принимаются в спринте 1, оказываются ошибочными, но это ошибочное решение не полностью реализуется, пока вся последующая работа не будет выполнена поверх этого ошибочного решения. Это, конечно, может привести к огромному количеству переделок.
Дэвид Хосье
8

Похоже, у вас есть проблема «Определение готово».

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

Относитесь к QA Group так, как будто они не существуют. Действуйте, если ваш релиз в конце спринта будет развернут в вашей наиболее критической среде на следующий день. Программное обеспечение не готово, пока оно не будет готово к покупателям.

QA ничего не должен найти.

Это будет сложнее добраться. У вас, вероятно, будут некоторые вещи, которые пробираются через первые несколько раз. Автоматизированные приемочные тесты и регрессионные тесты - ваши лучшие друзья здесь. TDD поможет вам построить большие части таких комплектов. Вы должны быть в состоянии узнать - быстро - если вы что-то сломали.

Шон Макмиллан
источник
3

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

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

Майкл Боргвардт
источник
3

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

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

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

GuyR
источник
Вы на 100% правы. Ваши три предмета - хороший совет. Я могу повлиять только на столько изменений, как на одного разработчика, но я могу попытаться привести пример и посмотреть, не хотят ли некоторые люди из QA прийти на прогулку. Мое самое большое разочарование заключается в том, что больше никого не волнует, что, очевидно, является огромным препятствием на пути к успешному повороту. Большинство людей в команде просто рады продолжить статус-кво; по крайней мере, это мое впечатление.
Дэвид Хосье
2

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

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

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

refro
источник
Ваш ответ вызвал хороший разговор между мной и коллегой. Основным моментом вашего ответа, который меня поразил, было: «В конце спринта (или пары) вы выпускаете продукт, который, как вы уверены, может быть выпущен на рынок». Я никогда не вспоминаю о выпуске продукта в конце спринта, пока после того, как мы не завершили целую серию спринтов, они прошли QA, и у нас было несколько раундов исправления ошибок. В этом отношении я думаю, что мы используем Agile просто для того, чтобы разбить и организовать нашу рабочую нагрузку и ничего больше. Мы не получаем никаких выгод от Agile.
Дэвид Хосье
@ Давид: я согласен с тобой.
Кристофер Махан
1

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

Тогда вы по-прежнему можете быстро реагировать на самые важные проблемы и исправлять многие, если не все, еще до того, как они закончатся!

Хьюго
источник
-2

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

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

Кто бы ни отвечал за контроль качества, либо не знает, что он / она делает, либо он выполнил трюк с умом джедая на высшем руководстве, и ему позволено провести приятное время. Как QA может занять больше времени, чем разработка?

JeffO
источник