Дорогой читатель, в этом посте мы с тобой рассмотрим 6 аббревиатур и подумаем когда их применение уместно.

Но для начала небольшой ликбез.

Операциональность

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

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

Различительная способность

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

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

Ключевая идея

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

Два описанных выше определения часто вступают в конфликт. Один человек говорит в терминах того, как он думает (теоретик), а другой в терминах того как он чувствует или своего опыта (практик).

В итоге иногда гвозди забиваются микроскопами.

Вернемся к исходной повестке.

INVEST

Теория

INVEST - критерий правильности User story.

• I - independent, независимость. Поставляем без влияния других историй;

• N - negotiable, обсуждаемость. Сами решим как ее лучше сделать;

• V - valuable, ценность. Сделав ее нанесем ценность бизнесу;

• E - estimable, оцениваемость. Сможем дать оценку по сложности/срокам;

• S - small, компактность. Сделаем за одну итерацию;

• T - testable, проверяемость. Понимаем как проверить или оттестировать.

Практика

Позволяет проверить, хорошо ли сформулирована user story на старте.

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

SMART

Теория

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

• S - specific, конкретность. Делаем что-то определенное;

• M - measurable, измеримость. Сможем измерить факты, подтверждающие достижение цели;

• A - achievable, достижимость. Сможем ее достичь, так как цель реальная;

• R - relevant, важность. Делаем не просто так, а в раках стратегии и приоритетности для бизнеса;

• T - time bound, ограничение по времени. Знаем когда закончим выполнение цели.

Практика

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

Применяем, когда хотим сформулировать понятную цель на уровне тактики и сделать ее обоснованной, а не с потолка. Подходит только для целей.

SC

Теория

SC - показатель, который позволяет судить об успешности выполнения деятельности.

SC - Success Criteria, критерии успеха.

Практика

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

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

CoS и AC

Теория

CoS - критерий приемки конечным потребителем результата.

CoS - Conditions of Satisfaction, тоже самое что AC - Acceptance Criteria.

Практика

Применяем, когда хотим понять как будет приниматься конкретный результат работы. Например, сделали вы карту. Список действий, которые пользователь сделает, чтобы проверить что карта работает как ему надо и есть AC.

DoD

Теория

DoD - критерий готовности рабочего элемента/инкримента. Набор действий, которые необходимо совершить над задачей, чтобы ее можно было считать готовой.

DoD - Definition of Done.

Практика

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

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

Список таких действий для каждого типа задач и есть DoD. Он может отличатся для бага и user story.

DoR

Теория

DoR - критерий готовности рабочего элемента/инкримента к выполнению работы конкретной командой/сервисом.

DoR - Definition of Ready.

Практика

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

Идем к стейкхолдерам и говорим, что не будем делать задачу, пока по ней нет AC и тестировщики из другой команды и будут свободны.

Список таких действий и есть DoR.