🤔 I.N.V.E.S.T. как пилюля от боли недопонимания

Сегодня хочу еще немного затронуть проектное управление, давай поговорим с тобой про I.N.V.E.S.T. принцип.

I.N.V.E.S.T. используется как фильтр для задач, чтобы не тащить в текущий спринт «все подряд». По сути это: Independent, Negotiable, Valuable, Estimable, Small, Testable таски, которые помогают градировать нам нагрузку и понимать чего от нас хотят, так как ты постоянно будешь сталкиваться с кейсами: "я не понимаю куда мы движемся", "я хочу все и вся", "не ясно, что надо сделать" и т.д.

В AppSec, как и везде, часто прилетает «сделайте безопасную безопасность». Это не задачи, а реальная головная боль. I.N.V.E.S.T. помогает превратить боль в нормальные user‑story и технические задачи, то есть:

• понятные команде

• дающие измеримый эффект

• которые реально можно закрыть за спринт

• и проверить, что они сработали

Как это работает?

• I — Independent

История должна жить отдельно: можно взять и сделать без половины департамента

Пример плохой: «Сделать безопасный логин, регистрацию, восстановление пароля и профили»

I.N.V.E.S.T.: «Добавить rate limiting на POST /login с логированием блокировок»

• N — Negotiable

История, как приглашение к разговору, где детали можно уточнить с командой до начала спринта

Если задача звучит как «строго по ГОСТу XXX, без вариантов» — это уже скорее политика, а не user story

• V — Valuable

Должно быть понятно, кому и какую ценность даёт история: пользователю, бизнесу, безопасности

Пример: «Включить ещё один сканер» — не ценность.

I.N.V.E.S.T.: «Сократить критические уязвимости в проде, добавив Quality Gate на уровне CI» - становится ценностью

• E — Estimable

Команда должна понимать объём: хотя бы порядок — день, три, спринт

Если история звучит как «внедрить DevSecOps», её сначала нужно дорезать до кусочков, которые можно оценить (например, «подключить SAST к проекту X») и если не провести ревью или анализ, а тебе говорят «посчитай что то там сам и предложи», - это совсем плохо

• S — Small

История должна помещаться в один спринт и, желательно, занимать не больше 25–50% спринта на команду

Всё, что звучит как «переписать модуль авторизации» — режем на отдельные шаги: логин, MFA, блокировки, аудит

• T — Testable

У истории должны быть чёткие критерии приёмки: как поймём, что она сделана - ранее писал про Win Conditions/ Fail Conditions

То есть, - «Сделать безопаснее» - не тестируется, а «при 5 неверных логинах аккаунт блокируется на 15 минут, событие уходит в SIEM» — тестируется

Как корректно подходить к задачам?

Берёшь любую хотелку и прогоняешь через INVEST:

• Независима ли она от всего остального?

• Можно ли её обсудить и переформулировать перед спринтом?

• Понятно ли, какую пользу она приносит?

• Команда может её оценить?

• Влезает ли она в один спринт?

• Можем ли мы чётко тестом/ мониторингом проверить результат?

Если хоть на один пункт ответ «нет» — история ещё сырая, и её лучше дорезать, прежде чем тянуть в спринт

Шаблон

## Заголовок

[AppSec] Кратко и конкретно: что делаем и где

## User story

Как <роль/ клиент> хочу <что именно> чтобы <какая измеримая польза/риск>

Примеры:

- Как владелец сервиса auth-service хочу ограничить число попыток логина чтобы снизить риск перебора паролей и захвата аккаунтов.

- Как AppSec-инженер хочу включить блокирующий Quality Gate по критическим уязвимостям чтобы не выпускать в прод новые критические дыры.

## Контекст (Define)

- Текущее поведение/ проблема:

- Сейчас ...

- Затронутые системы/ сервисы:

- auth-service, gateway, ...

- Риски/ инциденты/ мотивация:

- Были X инцидентов/ найдено Y уязвимостей ...

## Критерии INVEST

- **Independent**

- **Valuable**

- **Estimable & Small**

- **Testable**

## Критерии приёмки (Testable)

Формат Given/ When/ Then или список

## Технические заметки (Negotiable)

- Предлагаемый подход (можно менять по итогам обсуждения):

- Ограничения и допущения:

## Метрики / контроль (Control)

- Что и как измеряем после внедрения:

- Где смотрим:

#pmi #reco #specialty #appsec #humanres #paper