Кто-то в моей компании недавно предложил внести изменения в наш основной продукт, которые, по мнению наших менеджеров, должны инициировать то, что, по моему мнению, моя компания считает полным циклом обеспечения качества (т.е. тестирование всего набора продуктов с нуля). По всей видимости, для обеспечения полного цикла обеспечения качества нашего продукта требуется 12 недель. Моя проблема с этим заключается в том, что мы пытаемся сделать Agile (хотя, по моему мнению, в большей степени недооцененной) разработку. Мы сделаем целый набор спринтов, а затем выпустим релиз, который, я думаю, будет проходить вечно. Вопрос в том, действительно ли, если нашему QA потребуется 12 недель, чтобы выполнить свою работу, не должны ли мы просто отказаться от попыток сделать Agile? Какой смысл пытаться сделать Agile в такой ситуации?
Должны ли мы прекратить попытки делать Agile, если QA занимает 12 недель?
Ответы:
Что ж, прямым ответом на ваш вопрос был бы Му, я боюсь - просто недостаточно подробностей, чтобы сделать обоснованное предположение, стоит ли вам прекратить попытки.
Единственное, в чем я уверен, так это то, что уровень гибкости должен определяться потребностями клиентов / рынка (о которых вы не сообщили).
- Например, как пользователь 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, а не мы, разработчики.
Тестер испытывает головную боль, чтобы убедиться, что неожиданные изменения не ускользнули, потому что, честно говоря, как разработчик, у меня достаточно других вещей, чтобы беспокоиться о том, что для меня важнее. И поэтому им (тестерам) действительно нужны веские доказательства того, что все под контролем с выпуском, который они тестируют для отправки.
О, я чувствую твою боль Чтобы это работало, нужно внести серьезные изменения в команду QA.
Мой совет - разделить команду на три команды:
Функциональное тестирование - быстрое восстановление новых разработок.
Регрессионное тестирование - Полностью протестируйте продукт, прежде чем он выйдет за пределы дома. Это не должно занять 3 месяца, даже после уменьшения размера команды, потому что первая команда найдет большинство ошибок.
Автоматизированное тестирование - Написание полного набора регрессионных тестов для ускорения работы команды регрессионного тестирования.
Третья команда является бонусом, но если у вас не может быть первых двух команд, то вы также можете быть водопадом.
В качестве иллюстрации:
Обратите внимание, что ваша команда QA, вероятно, работает за пределами круга (ATDD), а вы работаете внутри.
Я думаю, что нормально работать таким образом; Если вы можете доказать в своих автоматизированных тестах, что вы выполняете требования клиента по каждому спринту, вы можете позволить QA проводить свои тесты на досуге и приходить к вам с дефектами, которые затем вы можете использовать для следующего спринта.
Похоже, у вас есть проблема «Определение готово».
Учитывая, что ваша группа контроля качества является внешней и участвует только в выпусках клиентов, вы не можете полагаться на них для своевременной обратной связи по вопросам. Это означает, что если вы хотите получить быструю обратную связь, вам придется принести некоторую степень «внутреннего» тестирования для команды.
Относитесь к QA Group так, как будто они не существуют. Действуйте, если ваш релиз в конце спринта будет развернут в вашей наиболее критической среде на следующий день. Программное обеспечение не готово, пока оно не будет готово к покупателям.
QA ничего не должен найти.
Это будет сложнее добраться. У вас, вероятно, будут некоторые вещи, которые пробираются через первые несколько раз. Автоматизированные приемочные тесты и регрессионные тесты - ваши лучшие друзья здесь. TDD поможет вам построить большие части таких комплектов. Вы должны быть в состоянии узнать - быстро - если вы что-то сломали.
Есть ли у вас представитель клиента / владелец продукта, который может увидеть конкретный выпуск до того, как с ним будет проведен QA, и дать вам официальную обратную связь с ним? Если это так, вы можете использовать гибкие методы и использовать большинство их преимуществ, рассматривая QA как вторичный, несколько медленный источник обратной связи. Релиз будет только «официально готов» после того, как с ним закончится QA, но вам не придется ждать их, пока не начнется следующий.
Но если правила компании гласят, что клиент не должен видеть релиз до того, как с ним закончится QA, вы можете забыть о гибкости, пока вам не удастся изменить эти правила.
Процесс, который вы описали, не является гибким процессом. Команды, обладающие высокой степенью ловкости, способны создавать надежные и потенциально выпускаемые сборки для каждого спринта. В большинстве гибких реализаций функция QA встроена в гибкую команду, помогающую достичь этой цели.
Если вы, руководитель проекта, владелец продукта и разработчики не работаете вместе, и у вас нет плана улучшения (ретроспективы), тогда назовите свой процесс как-нибудь еще и двигайтесь дальше. Похоже, что проблемы вашей команды не по вине менеджеров или QA. Похоже, они реагируют на некоторые системные проблемы, возникающие в организации по разработке. Еще не все потеряно, если команда готова взять на себя ответственность и начать работать с заинтересованными сторонами.
Вы можете попробовать три вещи. Во-первых, убедитесь, что у каждого участника есть четко определенные роли и что каждый человек понимает свою ответственность. Во-вторых, стабилизируйте сборку и затем получите подтверждение от QA без внесения дополнительных изменений. Три, институт автоматизации тестирования. Команда QA будет любить вас за это.
Жаль, что обратная связь занимает так много времени, но я не думаю, что стоит остановиться на Agile. В конце спринта (или пары) вы выпускаете продукт, который, как вы уверены, может быть представлен на рынке. Для вашей команды Agile дает возможность сосредоточиться на выполняемой работе и обеспечить возможность выпуска продукта. Когда QA находит проблемы, я предлагаю создать отчеты об ошибках для этих проблем и решить их в следующем спринте (если они имеют достаточно высокий приоритет).
Наши полевые испытания продукта занимают целых 8 недель плюс то, что мы зависимы от внешних производителей. Тем не менее, делая Agile, мы можем сосредоточиться на работе и выпускать новую версию очень быстро, когда это необходимо.
Проблема лежит (на ваш взгляд) с отделом контроля качества, может ли проблема быть решена там? Вы обсуждали это?
Что делают люди, отвечающие за контроль качества, пока вы выполняете несколько спринтов? Похоже, они чувствуют необходимость проверять все после каждого изменения (вот почему они ждут целую кучу изменений).
Команда разработчиков гибкая, а остальная часть компании - нет.
Кто бы ни отвечал за контроль качества, либо не знает, что он / она делает, либо он выполнил трюк с умом джедая на высшем руководстве, и ему позволено провести приятное время. Как QA может занять больше времени, чем разработка?