Коллеги, добрый день. По ряду причин я должен использовать Use case для описания реализации проекта по разработке большой системы. К сожалению, до настоящего момента у меня не было опыта использования Use case для проектов, реализуемых по Scrum. Основная проблема с которой я столкнулся – что считать Product backlog Item (PBI) и как трассировать по отношению к Use case (UC)? Ниже представлены мои рассуждение. Буду признателен за критику, совет и помощь.
User story vs Use case
Первый вопрос, который надо было решить - использовать User story или Use case. После некоторых размышлений на тему, а также после прочтения книги Алистера Коберна «Современные методы описания функциональных требований к системам», книгу Майка Кона «Пользовательские истории»истатьи на эту темуя пришел к некоторым выводам:
1. User story нам не подходят т.к. сложно понять поведение большой системы через формат записи User story.
2. User story не обладают механизмами таксономии и их сложно группировать по каким то признакам. В результате возникает груда записей, которым логически мало связаны друг с другом. В этом плане возможности Use case значительно выше и позволяют построить логически связанное описание. Очевидно, что без иерархии нам не обойтись.
3. При этом оказалось, что без User story не сделать Use case т.к. нужен первоначальный драйвер, который позволит быстро их подготовить. После подготовки Use case их можно было выкинуть.
4. Отличие хорошо написанных user story от хорошо написанных use case не велико. Формально Use case имеет более глубокую детализацию, что неплохо, когда в проекте работает больше 6 разработчиков и сложные заказчики. Об этом говориться в книгах обоих авторов, приведенных выше.
Цель, которую мы приследуем - нам нужен логичный, обозримый и целостный формат описания системы, а также взаимодействия с внешними системами. В связи с этим нами было принято решение использовать Use case.
Что и как?
Второй вопрос, который нам предстояло решить, как описать требования. Мы учли возможность использовать Use case для "Общего понимания", цели которого могут быть достигнуты за несколько шагов, а есть уровень вполне конкретных целей пользователя, которые могут быть описаны в одном кейсе. При этом кейсы могут быть логически связаны друг с другом гиперссылками. В книге Корбена первые представлены "уровнем неба", вторые "уровнем моря". По сути у нас может быть один кейс уровня небо, содержащий несколько кейсов уровня Моря. Реализация кейса уровня неба может быть достигнута через реализацию всех кейсов уровня моря. Нас это вполне устраивает т.к. позволяет достичь поставленной цели - логичный, обозримый и целостный формат описания системы.
Пример (заведомо максимально упрощенный):
==================================
UC_1 Пользователь получает деньги в банкомате
Уровень: небо
Сценарий:
1. Пользователь проходит процедуру авторизациивведя пин код и сумму к выдаче.
2. Пользователь завершает операцию,получив деньги и карту.
Примечание: Подчеркивание означает наличие расширения.
==================================
Что бы достигнуть этой цели нужно для начала пройти авторизацию. Мы описываем это в следующем Use case:
==================================
UC_2 Процедура авторизации
Уровень: море
Необходимое условие: Пользователь вставил карту
Сценарий:
1. Система авторизует пользователя.
2. Система запрашивает процессинговый центр разрешение на операцию и разрешение выдачи запрошенной суммы.
3. Система сообщает банкомату результат процедуры авторизации.
==================================
Следующий кейс завершает задачу:
==================================
UC_3 Завершение операции
Уровень: море
Необходимое условие: успешное завершение UC_2 (пользователь авторизован, запрошенная сумма разрешена к выдаче).
Сценарий:
1. Система возвращает карту пользователю.
2. Система осуществляет подсчет купюр и их выдачу.
2. Система обменивается данными с процессинговым центром для фиксации результата выдачи денег.
==================================
Формирование PBL на основании use case
Последний вопрос, на который нам надо было ответить, как сформировать Product backlog (PBL) с использованием представленных выше кейсов. Мы рассмотрели несколько вариантов.
Вариант, который сразу отпал - взять в качестве PBI 1й уровень (UC_1 Пользователь получает деньги в банкомате) нельзя т.к. это однозначно может не уложиться в спринт т.е. слишком эпично и нереализуемо в рамках одного спринта. Далее мы рассмотрели другие варианты:
Вариант 1
В качестве PBI взять UС_2 и UС_3. Получится PBL, содержащий:
1. Процедура авторизации
2. Завершение операции
Плюсы: Простота трассировки. В качестве задач для реализации PBI элемента мы можем использовать шаги кейса. Описание, содержащееся в Use case, достаточно полное для понимания требований и критериев приемки.
Минусы: Задача может быть слишком большая для спринта. При этом этот минус легко нивелировать разбив этот Use case на несколько меньшего размера.
Вариант 2
В качестве PBI взять шаги 2го и 3го use case. Получится PBL, содержащий:
1. Система авторизует пользователя.
2. Система запрашивает разрешение на операцию и размер максимальной суммы выдачи.
3. Система сообщает банкомату результат процедуры авторизации.
4. Система возвращает карту пользователю.
5. Система осуществляет подсчет купюр и их выдачу.
6. Система обменивается данными с процессинговым центром для фиксации результата выдачи денег.
Плюсы: Хорошая атомарность, поддающаяся оценке.
Минусы: Сложно трассировать с конкретным Use case. Сложно отслеживать последовательность реализации (критический путь). С точки зрения невилирования проблем можно использовать таксономию, что может также создать дополнительные сложности.
Вариант 3
Отталкиваяс от имеющихся Use case подготовить свой набор PBI элементов, не связанный наприямую с UC. Получится PBL, содержащий:
1. Процудура авторизации.
2. Взаимодействие с процессинговым центром.
3. Завершение операции.
Плюсы: есть возможность удобного атомарного разделения задач.
Минусы: трассировка элементов PBL с конкретными UC очень сложная.
Взвесив все плюсы и минусы, я пришел к выводу, что лучше использовать 1й вариант и стараться дробить use case до уровня реализации в рамках одного спринта. Таким образом у нас будут Use case общего характера (уровня неба) и use case, подлежащие реализации (уровень моря).
User story vs Use case
Первый вопрос, который надо было решить - использовать User story или Use case. После некоторых размышлений на тему, а также после прочтения книги Алистера Коберна «Современные методы описания функциональных требований к системам», книгу Майка Кона «Пользовательские истории»истатьи на эту темуя пришел к некоторым выводам:
1. User story нам не подходят т.к. сложно понять поведение большой системы через формат записи User story.
2. User story не обладают механизмами таксономии и их сложно группировать по каким то признакам. В результате возникает груда записей, которым логически мало связаны друг с другом. В этом плане возможности Use case значительно выше и позволяют построить логически связанное описание. Очевидно, что без иерархии нам не обойтись.
3. При этом оказалось, что без User story не сделать Use case т.к. нужен первоначальный драйвер, который позволит быстро их подготовить. После подготовки Use case их можно было выкинуть.
4. Отличие хорошо написанных user story от хорошо написанных use case не велико. Формально Use case имеет более глубокую детализацию, что неплохо, когда в проекте работает больше 6 разработчиков и сложные заказчики. Об этом говориться в книгах обоих авторов, приведенных выше.
Цель, которую мы приследуем - нам нужен логичный, обозримый и целостный формат описания системы, а также взаимодействия с внешними системами. В связи с этим нами было принято решение использовать Use case.
Что и как?
Второй вопрос, который нам предстояло решить, как описать требования. Мы учли возможность использовать Use case для "Общего понимания", цели которого могут быть достигнуты за несколько шагов, а есть уровень вполне конкретных целей пользователя, которые могут быть описаны в одном кейсе. При этом кейсы могут быть логически связаны друг с другом гиперссылками. В книге Корбена первые представлены "уровнем неба", вторые "уровнем моря". По сути у нас может быть один кейс уровня небо, содержащий несколько кейсов уровня Моря. Реализация кейса уровня неба может быть достигнута через реализацию всех кейсов уровня моря. Нас это вполне устраивает т.к. позволяет достичь поставленной цели - логичный, обозримый и целостный формат описания системы.
Пример (заведомо максимально упрощенный):
==================================
UC_1 Пользователь получает деньги в банкомате
Уровень: небо
Сценарий:
1. Пользователь проходит процедуру авторизациивведя пин код и сумму к выдаче.
2. Пользователь завершает операцию,получив деньги и карту.
Примечание: Подчеркивание означает наличие расширения.
==================================
Что бы достигнуть этой цели нужно для начала пройти авторизацию. Мы описываем это в следующем Use case:
==================================
UC_2 Процедура авторизации
Уровень: море
Необходимое условие: Пользователь вставил карту
Сценарий:
1. Система авторизует пользователя.
2. Система запрашивает процессинговый центр разрешение на операцию и разрешение выдачи запрошенной суммы.
3. Система сообщает банкомату результат процедуры авторизации.
==================================
Следующий кейс завершает задачу:
==================================
UC_3 Завершение операции
Уровень: море
Необходимое условие: успешное завершение UC_2 (пользователь авторизован, запрошенная сумма разрешена к выдаче).
Сценарий:
1. Система возвращает карту пользователю.
2. Система осуществляет подсчет купюр и их выдачу.
2. Система обменивается данными с процессинговым центром для фиксации результата выдачи денег.
==================================
Формирование PBL на основании use case
Последний вопрос, на который нам надо было ответить, как сформировать Product backlog (PBL) с использованием представленных выше кейсов. Мы рассмотрели несколько вариантов.
Вариант, который сразу отпал - взять в качестве PBI 1й уровень (UC_1 Пользователь получает деньги в банкомате) нельзя т.к. это однозначно может не уложиться в спринт т.е. слишком эпично и нереализуемо в рамках одного спринта. Далее мы рассмотрели другие варианты:
Вариант 1
В качестве PBI взять UС_2 и UС_3. Получится PBL, содержащий:
1. Процедура авторизации
2. Завершение операции
Плюсы: Простота трассировки. В качестве задач для реализации PBI элемента мы можем использовать шаги кейса. Описание, содержащееся в Use case, достаточно полное для понимания требований и критериев приемки.
Минусы: Задача может быть слишком большая для спринта. При этом этот минус легко нивелировать разбив этот Use case на несколько меньшего размера.
Вариант 2
В качестве PBI взять шаги 2го и 3го use case. Получится PBL, содержащий:
1. Система авторизует пользователя.
2. Система запрашивает разрешение на операцию и размер максимальной суммы выдачи.
3. Система сообщает банкомату результат процедуры авторизации.
4. Система возвращает карту пользователю.
5. Система осуществляет подсчет купюр и их выдачу.
6. Система обменивается данными с процессинговым центром для фиксации результата выдачи денег.
Плюсы: Хорошая атомарность, поддающаяся оценке.
Минусы: Сложно трассировать с конкретным Use case. Сложно отслеживать последовательность реализации (критический путь). С точки зрения невилирования проблем можно использовать таксономию, что может также создать дополнительные сложности.
Вариант 3
Отталкиваяс от имеющихся Use case подготовить свой набор PBI элементов, не связанный наприямую с UC. Получится PBL, содержащий:
1. Процудура авторизации.
2. Взаимодействие с процессинговым центром.
3. Завершение операции.
Плюсы: есть возможность удобного атомарного разделения задач.
Минусы: трассировка элементов PBL с конкретными UC очень сложная.
Взвесив все плюсы и минусы, я пришел к выводу, что лучше использовать 1й вариант и стараться дробить use case до уровня реализации в рамках одного спринта. Таким образом у нас будут Use case общего характера (уровня неба) и use case, подлежащие реализации (уровень моря).