Определение связей в продукте и влияние фичи

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

Подозреваю, что BA / Product Manager / Product Owner обладают каким-нибудь тайным кунг-фу (методологией, подходом), который должен позволить эти связи выявлять на ранней стадии и достаточно точно — возможно, какое-то разбиение на сущности, майнд-мапы, что-нибудь еще.

Кто-то работал с таким? Сталкивались с такими проблемами? Как решали?

Гуглил вчера безуспешно часа полтора, на английском и русском языках )

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Гляньте по Traceability Matrix

QA Lead или любой QA в команде может нарисовать легкую табличку Impact Analysis и там все указать, а потом расшарить на Dev Lead для уточнения правильности понимания связей и влияния фич на области системы в целом. Я так делал в E-Commerce проектах, когда новые фичи писались и прикручивались сторонние сервисы.

Це недоліки тестування. Змни глобальних сутностей, які застосовуються в багатьох процесах і/або модулях повинні вести за собою зміни тестів цих процесів і/або модулів. Тест кейси повинні враховувати все (в реальності таке неможливо). Або за стратегією Microsoft реально тестують кінцеві користувачі.

Если изменение в одной части продукта стабильно отваливает другую часть продукта — то тут никакое БАйское кунг-фу не поможет. Тут вопрос к качеству кода и регрессионному тестированию. Немного помочь можно нормальной декомпозицией.
На ранней стадии любая фича должна быть четко зафиксирована за частью функционала — эпиком/модулем, или за несколькими. Если фича влияет на много эпиков, то стори для каждого эпика должны создаваться и тестироваться отдельно.
Пример — «Добавить экспорт всех таблиц». Слово «всех» должно насторожить, но это не всегда настораживает. Идеально, если это изменение кода в одном месте, но тестировать все равно придется во многих (специфичные типы данных и т.д.).
При соблюдении нормальной иерархии эпик-сторя (вертикально), фича-сторя (горизонтально, опционально) объем тестирования сильно проще определить.

Проблема не в том, что что-то стабильно отваливает что-то другое. Я могу попробовать переформулировать вопрос — как эффективно выявлять неявные связи и зависимости в продукте?
"

Если фича влияет на много эпиков

 — и вот тут вопрос, как эффективно выявлять эпики / части / модули / сущности, на которые влияет фича?

... как эффективно выявлять неявные связи и зависимости в продукте?

Если BA / Product Manager / Product Owner со стороны заказчика — то он тоже ведь человек, и что-то может пропустить.

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

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

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

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

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

Если более сложные случаи — можно взять SparX Enterprise Architect, там есть возможность рисовать диаграммы разных типов.

Если проектирование безопасности TCP стека, например, то там уже намного сложнее подход, это — отдельная тема.

Еще, некоторые раньше предлагали использовать requirements management чтобы по ходу разработки можно было отмечать как один requirement зависит от других и отображать эту картинку.

Для обычных проектов также неплохо помогает понимание того какие есть обьекты в БД и как они между собой связаны — нужно иметь эту картину перед глазами.

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

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

Створити і підтримувати документацію

Подписаться на комментарии