Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Дорогой читатель, в этом посте мы с тобой рассмотрим 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.
