Клиент с консервативной политикой UAT

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

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

Я ищу хорошие идеи о том, как структурировать спринты Scrum в таком климате / среде. Опять же, пожалуйста, не предлагайте изменить компанию, потому что это выходит за рамки данного обсуждения. Это скорее вопрос «работы в реальном мире с клиентами». Им нравятся agile-практики, управление невыполненными работами, усовершенствование, планирование спринтов, планирование релизов и все остальные прелести Scrum. Нам просто нужно добавить эту 1 неделю UAT и отказа в конец, и я ищу способы приспособиться к этому.

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

Я не уверен, что именно вы пытаетесь улучшить здесь. Прерывания? Соблюдение руководства по Scrum? Я также не уверен, каковы причины сбоев, о которых сообщается после UAT. Связаны ли они с качеством промежуточной среды? Если вы поделитесь более подробной информацией, я обновлю свой ответ.
Спасибо. Цель состоит в том, чтобы иметь меньший риск для родов. Таким образом, в идеале он должен включить цикл UAT в спринт, но найти, что делать разработчикам, чтобы избежать простоев, когда релиз представляет собой версию с низким уровнем дефектов. Причина, по которой UAT представляет собой проблему, заключается в том, что проект является расширением устаревшей системы, которая имеет множество взаимозависимостей. Затем необходимо определить, существовала ли проблема ранее, была ли она вызвана новым кодом или возникла где-то ниже по течению, потому что A вызвал B, затем A вызвал C, но B прямо или косвенно изменил состояние C менее чем за очевидный способ.
Scrum дает наибольшую рентабельность инвестиций, когда нет технического долга, такого как непредсказуемые устаревшие системы. В таких случаях, если Scrum считается лучшим подходом, я бы посоветовал сначала сделать его более надежным. В то же время вы написали, что Scrum не является необходимостью, поэтому мой ответ был больше о решении проблемы, а не о решении проблемы в рамках Scrum.

Ответы (5)

TL;DR

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

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

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

Экстернализация цикла обратной связи UAT

Естественно, это приводит ко многим сбоям, о которых сообщает UAT, и элементы отклоняются и отправляются обратно в разработку.

Это проблема, но это экстерналия . У вас есть внешний процесс, который увеличивает накладные расходы процесса (и, следовательно, затраты) на вашу прибыль. Правильный способ справиться с этим — сделать эти затраты видимыми для заинтересованных сторон.

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

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

Расширьте Sprint для UAT с видимыми затратами

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

Стоимость простоя разработчика определяется внешним процессом. Ваша задача не в том, чтобы создавать загруженную работу или увековечивать «ошибку 100%-го использования». Команда может использовать эту неделю для обновления сервера CI, исправления рабочих станций, обучения без отрыва от производства или просто чтения хорошей книги. Дело в том , что этот цикл UAT имеет стоимость разработки (будь то работа, не связанная с продуктом, или итеративная работа), которая является частью организационной структуры. Просто сделайте эту стоимость полностью видимой.

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

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

Мне нравится делать затраты видимыми, это потенциально самое важное здесь.

Для протокола: когда Команда Разработки не может предоставить потенциально выпускаемый инкремент в конце Спринта, это серьезное отклонение от Scrum. Давайте отложим этот вопрос в сторону.

Что вы можете сделать:

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

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

  • научить владельца продукта представлять точку зрения конечных пользователей на максимально возможном уровне
Мне нравится расширение. Если вам повезет, и вы получите немного денег, у дебов будет время на уборку дома, чтобы подготовиться к следующей итерации.
Это была моя первая склонность. Следующим вопросом будет то, как объяснить руководству третью неделю. Они хотели бы убедиться, что эти разработчики в основном заняты порученной работой. Что вы предлагаете, если релиз бездефектный? Шипы на жуках? Дополнительные истории были бы слишком рискованными, потому что им, вероятно, потребуется полный цикл UAT (3-я неделя спринта), поэтому на этой 3-й неделе должен быть какой-то лимит WIP с точки зрения того, что он может испускать и получать через UAT. .
@PittsburghDBA На самом деле я заслужил пощечину за то, что написал :) Я был недостаточно ясен, поэтому позвольте мне исправиться. Включая тесты UAT в Sprint, я не собирался делать их все в конце, на прошлой неделе. Конечные пользователи (или те, кто их выполняет) должны быть как можно скорее вовлечены в процесс любым возможным способом.
@PittsburghDBA Свободное время ваших разработчиков может быть потрачено на улучшение вашей промежуточной среды. Было ли у них время, чтобы глубоко погрузиться в этот вопрос? Из того, что вы написали, у меня сложилось впечатление, что сбои, выявленные во время UAT, являются признаком среды разработки, а не недопонимания относительно элементов бэклога продукта.

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

Делай сейчас

Сосредоточьтесь на выводе Команды Разработки, который потенциально может быть отправлен. Это новая часть программного обеспечения, которую они производят каждый спринт, направляется в UAT и всегда должна проходить. (Если он всегда будет успешным, то бизнес увидит меньшую ценность в UAT.)

1) Создайте определение «Готово», которое представляет уровень качества, при котором вы потенциально готовы к выпуску.

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

Это приблизит вас к ценностям и принципам Scrum, не мешая более широкой организации.

Среднесрочная перспектива

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

3) Привлеките конечных пользователей и заинтересованных лиц к обзору спринта и соответствующим образом адаптируйте невыполненную работу.

4) Пригласите UAT на обзор спринта.

5) Вставьте в свой код инструменты для сбора данных телеметрии, например Application Insights, чтобы действительно понять поведение ваших пользователей.

Долгая цель

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

Это проницательно. Не знаю почему, но меня всегда удивляет, по крайней мере, немного, скорость организационных изменений.
Определение «сделано» соответствует тому, что я собирался сказать в отдельном ответе: если есть ожидаемое препятствие, которое будет возникать в каждом спринте, возможно, стоит адаптировать ваше определение «сделано» к этой реальности. Scrum не требует, чтобы ваш потенциально готовый к отправке инкремент действительно был отправлен! В вашем определении готовности может быть сказано, что ее необходимо разработать, протестировать и признать готовой к UAT , и на этом ваш процесс может остановиться. Обратная связь от UAT затем попадает в журнал невыполненных работ для следующего спринта, и когда инкремент успешно проходит UAT, вы не торопитесь, чтобы выпустить его.
«Определение готовности» Вероятно, здесь это непрактично, консервативные заинтересованные стороны не примут никакого определения готовности. Стоит попробовать, но это не удастся, когда позже они будут настаивать на том, что что-то не сделано.

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

Это было бы наиболее естественным путем, но в большинстве случаев политика требует немедленного исправления истории кандидата на выпуск, поэтому у нас есть переполнение с точки зрения планирования спринта. Затем выпуск начнется как можно скорее с новыми исправлениями, снова прошедшими UAT. Это нарушает нормальную схему схватки.
@PittsburghDBA, « политика требует немедленного исправления истории кандидата на выпуск », на что направлена ​​такая политика? Т.е. чем это обосновано? Ясно, что это нарушает ваш процесс/успех, так что должен быть плюс? Как и вы, я живу в реальном мире, с реальными клиентами и их требованиями. Хотя чаще всего нам приходится принимать то, о чем они нас просят, мы, тем не менее, должны стремиться как можно тщательнее исследовать их мотивы и проблемы с ними, чтобы мы могли предложить решение. Поэтому, если вы не знаете, почему действует эта политика, спросите.

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

Если эти задержки затрагивают клиента, вам необходимо решить проблему, связанную с тем, что ваша команда не может создать продукт, отвечающий потребностям клиента. Следующим моим шагом будет обращение с тестировщиками UAT как с клиентами. Вы сказали, что они не являются частью SCRUM-команды, но они могут быть клиентами. Ни одна группа тестирования не любит сбои в программном обеспечении, возможно, вы можете работать с ними, чтобы найти способы выявить то, что им важно, на более ранних этапах процесса. Если они заказчики, участвующие в процессе, они могут почерпнуть из этого идеи. Они могут сказать: «Вы знаете, этот инструмент, который вы использовали для проверки работоспособности вашего программного обеспечения до того, как мы его протестировали… думаете, мы могли бы его использовать?» Тогда вы обеспечили ценность, которую они никогда не ожидали получить.

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

Спасибо за это. Я также подумывал об увеличении частоты выпуска, чтобы они могли выполнять UAT для завершенных историй как можно скорее, а затем, ближе к концу спринта, UAT больше сосредоточился бы на интеграционных и системных тестах.
Клиент с консервативной политикой UAT
СпросиСетьПолитика конфиденциальности1y, 0v