Что такое тестирование бизнес процессов

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

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

Возможно, пользователи не следовали новым процедурам, что создавало проблемы. Или же они не смогли усвоить обучающие материалы или разобраться в полученной документации. Помните ли вы, как люди говорили что-то вроде: «Раньше было лучше»? Итак, как можно избежать проблем такого рода?

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

Бизнес-тестирование (также известное как тестирование на приемлемость для пользователей, User acceptance testing — UAT) обычно проводится людьми, которые будут использовать продукт на практике. Это гарантирует, что предлагаемые изменения действительно будут работать ДО их внедрения.

Денис Кудряшов. Тестирование бизнес-логики на примере Camunda BPM

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

Как использовать инструмент

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

Шаг 1. Учитесь на примерах других проектов

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

Шаг 2. Выберите объект тестирования

Определите необходимые объекты тестирования, рассмотрев следующие моменты:

• Точки передачи — учитывайте все моменты передачи между различными системами и различными группами людей. Вы часто будете сталкиваться с проблемами в этих областях.
• Ключевые риски проекта — определите ключевые риски проекта, используя инструмент «Анализ и менеджмент рисков». Этот анализ поможет определить области, на которых необходимо сосредоточиться.
• Сквозные процессы — по возможности тестируйте изменения процесса и системы от начала до конца, включая тесты для каждого варианта процесса.
• Оценка воздействия — рассмотрите потенциальное воздействие на запуск результатов вашего проекта без их тестирования. Приведут ли ошибки к дополнительным затратам, потере клиентов или задержкам? Будут ли эти ошибки приемлемы для бизнеса? Уделяйте приоритетное внимание тестированию в зонах повышенного риска.
• Другие варианты — какие еще варианты у вас есть? Например, если вы пересматриваете программу корпоративного обучения в классе, можно проконсультироваться с ключевыми сотрудниками при ее разработке. Запустив пилотный проект с первой группой обучающихся, а затем внеся изменения для последующих групп, можно в достаточной мере управлять рисками, что позволит избежать проведения бизнес-тестов.

Шаг 3. Определите необходимые атрибуты процесса тестирования

Продумайте следующие элементы тестирования:

Моделирование бизнес-процесса тестирования ПО в ELMA

Бюджет — возможно, вам придется включить в бюджет все виды расходов, например:

• аренду помещения;
• компьютерное оборудование;
• расходы на печать учебных материалов;
• расходы на участников;
• дополнительный штат сотрудников или гонорары подрядчиков.

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

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

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

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

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

• Документация — подберите документацию, необходимую вашим тестировщикам. Например, при тестировании систем часто используется последовательность «тестовых сценариев». Тестировщики выполняют их посредством индивидуальных ролей и действий в рамках сквозного процесса. Затем вы можете сгруппировать тестовые сценарии, чтобы протестировать весь процесс.

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

Шаг 4. Определите длительность тестирования

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

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

Обратите внимание на то, что тестирование обычно проводится ближе к концу проекта. Таким образом, если в проекте возникали задержки, может возникнуть необходимость сократить время тестирования. Четко определите основные компоненты вашего подхода к тестированию (подробнее о подходах к планированию читайте в нашей статье об анализе критического пути и диаграммах PERT. Помните, что при неудовлетворительных результатах проекта после его внедрения никто не поблагодарит вас за экономию на тестировании!

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

Шаг 5. Выберите форму отчетности

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

Внесение изменений на основе результатов бизнес-тестирования часто вызывает стресс!

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

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

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

Источник: dialog.guide

3.2. Тестирование бизнес-процесса

В общем случае тестирование представляет собой набор про­цедур и действий, предназначенных для демонстрации коррект­ной работы объекта в заданных режимах и внешних условиях. Цель тестирования — выявить наличие ошибок или убедительно продемонстрировать ихотсутствие, что возможно лишь в отдель­ных тривиальных случаях.

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

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

Для целей тестирования объект удобно представлять в виде ориентированного графа G — (N, £), где N = Nx, N2, —, Nm) — множество узлов (вершин), соответствующих функционалу объ­екта; Е — (Еи Е2,. Е„) — множество ребер (дуг), соответствую­щих передачам управления между функциями.

Путем (маршрутом) называется последовательность вершин и дуг Р= (Nh EU2, N2, £2 j. Ек.и, Nk), где каждая дуга Eii+l вы­ходит из Nt и входит в N’t+b причем TV, не обязательно начальный узел. Ветвью называется путь Р, в котором Nx — либо начальный узел, либо узел ветвления, Nk — узел ветвления либо заверша­ющий узел, все остальные JV,- не являются узлами ветвления.

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

Как прави­ ло, эти критерии устанавливают требование, по крайней мере, однократной проверки всех функций (критерий С0), всех его вет­ вей (критерий Сх) либо всех полпутей специального вида. Самым распространенным критерием тестирования является критерий, требующий по крайней мере однократной проверки каждой из ветвей объекта (критерий С,). Например, тестирование при при­ емке программного обеспечения для ВВС США производится на основании этого критерия. По ряду независимых оценок исполь- зование критерия С, обеспечивает обнаружение до 90% ошибок. ■-.-■■

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

Например, любое ЛПР^южет приказать своему подчиненному изменить традиционный маршрут испол-аения би?нее-процесса (типичный пример приказа такого рода — «к этот Документ передайте не Ивану Ивановичу, как обычно, а Петру Петровичу»). В то же время даже для последовательных арограмм задача тестирования является трудноразрешимой. Из-эестно, что полное и исчерпывающее ее тестирование практичес­ки невозможно, так как требует огромных трудозатрат. Таким об­разом, перефразировав известное утверждение Дейкстры (касаю-чееся программного обеспечения), можно сказать, что любой 1нзнес-процесс содержит хотя бы одну ошибку — просто пока «ще небыли созданы условия для ее проявления.

В качестве примера можно привести реальный случай, прои­зошедший на одном из молокозаводов Москвы. Схема отгрузки ■олокопродуктов в магазины включала прием денежного залога зпару, принадлежащую молокозаводу. При возврате тары залог возвращался. Поскольку величина залога была незначительной, «однократно возвращалась сломанная тара, нередкими были вучая ее утери, что создавало определенные проблемы при

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

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

Наиболее типичными для планируемых бизнес-процессов современного предприятия ошибками являются ошибки, связан­ные с информационными ресурсами (ошибки в потоках данных). Примерами таких ошибок являются:

• создание информационных объектов (ИО) и/или их атрибутов, не используемых в дальнейшей деятельности;
• отсутствие и/или неполнота ИО и/или их атрибутов;
• дублирование ИО и/или их атрибутов и, как следствие, их не- „ согласованность и противоречивость и др.

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

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

Источник: studfile.net

5 вопросов про e2е-тестирование

Для запуска большой системы может быть недостаточно функционального и интеграционного тестирования. За обилием технических моментов можно упустить важный для бизнеса аспект, который может заставить отложить запуск вроде бы готового продукта (услуги, предложения). Мы говорим про тестирование бизнес-процесса (end-to-end-тестирование или просто e2e). Рекомендуем проводить его целиком, не фрагментируя на спринты и релизы систем, пройти от и до на тестовой среде без риска для пользователей и инфраструктуры.

887 просмотров

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

герой м/с «Футурама»
Когда и кому нужно end-to-end-тестирование

У PO и QA есть инструменты, которые позволяют понимать состояние продукта и процессов. Они тестируют, снимают метрики, планируют и автоматизируют независимую поставку изменений пользователю, чтобы сократить time-to-market и быть готовыми реализовать любые потребности бизнеса.

Рассмотрим поставку бизнес-ценностей на примере Scaled Agile Framework, где взаимодействует много внутренних и внешних систем и сервисов, есть вендоры, разный технологический стек, состав команд, функциональность, а значит и субъективный взгляд на бизнес-ценности, когда каждая команда всё видит «со своей колокольни».

Зачастую бизнес-ценность не укладывается в компетенцию одной команды и даже одной системы. Назовем такую ценность capability (высокоуровневое функциональное решение, которое реализуется за один цикл). Кто отвечает за реализацию capability в нескольких системах и командах? Чтобы это не стало общей ответственностью, у capability должна быть ведущая команда. И ей требуется новый инструмент — end-to-end-тестирование (e2e), которое обеспечит поставку ценности.

E2e проверяет работу бизнес-процесса, проходящего через разные системы, например, от регистрации клиента до закрытия сделки. Кажется, всё просто: определили системы, команды и срок запуска, запланировали и провели. Но давайте разберемся, так ли это.

кадр из м/ф «Вовка в Тридевятом царстве»
Внедрение e2e: как не наступить на грабли

Главная проблема внедрения нового инструмента – ресурсы. А точнее оценка и планирование e2e-тестирования при отсутствии практики. Ведь если у нас всё хорошо, то лишних ресурсов нет ни в одной команде, которые реализуют capability. Клиенту важно знать, что всё готово к запуску бизнес-процесса.

И вот QA-специалистов просят оценить задачу «на тестирование» capability, которое реализуется, например, в течение четырех спринтов в трех командах и четырех системах. При этом оценить нужно свою часть тестирования, учитывая имеющиеся ресурсы. Хорошо, если оценивает QA-лид, который имеет опыт тестирования разных систем.

При этом PO и аналитики уже проработали зависимости и знают, кто будет участвовать в e2e. Хорошо, если у всех есть опыт е2е-тестирования, всё учтено, и бизнес знает, чего хочет или всегда готов к диалогу. К сожалению, так бывает не всегда.

Рассмотрим ситуацию, когда команда системы «Г», которая поддержала зависимость по capability, проводит подготовку к квартальному планированию. Так может выглядеть диалог PO и QA:

• У нас планируется e2e по сделкам в армянских драмах. Давайте оценим.
• А что нужно проверить? – робко интересуется QA.
• Что сделка в драмах закрывается.
• А чем это отличается от других сделок? – не унимается QA.
• Валютой.

QA думает: «Боже, я каждый день на тесте закрываю сделок на 10 млн рублей и на 12 в тенге. Тут что-то не так», – а сам спрашивает:

• А для чего e2e?
• Сайт локализуют для Армении и их команда – ведущая в e2e.
• У них в команде есть QA? Нужен будет его контакт.
• Да, конечно.
• Наша доработка по новым валютам уже на проде за фичатогглом (feature toggle – переключатель, настройка доступности функционала на проде). Пусть будет 2 сторипойнта с учетом коммуникаций и оформления отчета.

Дальше всё будет так, как бывает, когда нет тест-плана: забыли включить в тестирование одну из систем, начали е2е до того, как исправили баги и не закрыли сделки. В итоге, в системе «Б» весь спринт проходился раз за разом один и тот же сценарий. В следующем спринте тестирование завершили. Об успешном «сквозном» тестировании сообщили на демо.

Что сделали не так?

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

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

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

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

ЛАЙФХАК: о тест-дизайне capability можно написать отдельный материал, но опыт показывает, что оптимально использовать попарное и парное тестирования. Первое позволит учесть максимум требований в разных системах. При этом покрытие будет достаточным, так как тестирование релизов проводится параллельно. Парным тестированием (именно QA из разных систем) следует пройти хотя бы один сценарий. Свежий взгляд позволит заметить то, что могли забыть или пропустить.

Подготовка: как сделать эффективнее

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

ЛАЙФХАК: если организовать встречу с клиентом сложно, то это может быть созвон QA-специалистов, работающих в разных системах. Объединив знания о продукте, они смогут получить необходимые сведения для дальнейшего планирования.

Главное – у QA ведущей команды должна собраться информация, которая нужна для проведения тест-дизайна и постановки цели тестирования:

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

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

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

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

Как доступы могут сэкономить ресурсы

Прекрасно, когда есть все доступы. Можно ввести данные в систему «А» и в ней же, как пользователь, видеть результат, после обработки данных в «Б» и «В». Затем взять тестовое устройство и под другой ролью в системе «Г» продолжить и завершить процесс. В итоге проверить его артефакты в «А» и «Д». Это e2e-тестирование выполняет один специалист — без потерь на коммуникации и синхронизацию между QA из разных команд.

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

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

Запуск: без чего не обойтись

Итак, мы практически подготовили тест-план, получили понимание о бизнес-процессе и представление о цели тестирования. На этом этапе есть сценарии, участники, их роли. На квартальном планировании мы расставили и обсудили зависимости, оценили задачи на разработку, e2e и настройку стендов, возможно даже запланировали «окно», когда настройки нельзя ломать. Теперь мы знаем:

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

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

ЛАЙФХАК: тест-план не обязательно представляет из себя документ. Можно создать чат, задачу или страницу в confluence для фиксации договоренностей и обмена артефактами, или в системе управления тестами, например, в Test Rail. Важно не пренебрегать коммуникациями, чтобы не только следовать плану, но и вовремя его корректировать.

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

С таким планом даже отменившееся e2e превратится в работу, которая не выполнена по конкретной причине. Без плана может получиться ничего не стоящий отчет.

Подведем итоги

Своевременное подключение QA позволит не потерять бизнес-ценность в ходе e2e-тестирования.

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

Погружение QA в бизнес-процесс позволит запланировать e2e оптимальным образом:

• определить необходимые команды
• определить степень их участия и подготовительные мероприятия
• распределить ресурсы с помощью получения доступов
• договориться о критериях завершенности.

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

На уровне команд: ресурс одной не будет тратиться на тестирования функциональности в другой, так как разграничены степень участия и определены критерии начала (готовности). Прописанные критерии завершенности (Definition of Done, DoD) позволят понять, в какой момент общая задача готова и начинаются доработки и исправления в отдельной команде.

На выходе владельцы продукта получают информацию, как о состоянии отдельного продукта, так и готовности всего capability к запуску.

Больше интересных кейсов — на нашем сайте.

Источник: vc.ru