2013-10-23: SECR. Мастер-класс Ивара Якобсона Use-Case 2.0
Строка 24: | Строка 24: | ||
{{wl-publish: 2013-10-24 01:30:28 +0400 | MaksTsepkov }} | {{wl-publish: 2013-10-24 01:30:28 +0400 | MaksTsepkov }} | ||
− | + | [[Category:Конференции]] |
Версия 22:11, 16 мая 2014
Очень понравился мастер-класс Use-Case 2.0, который проводили Ивар Якобсон (Ivar Jakobson) и Иэн Спенс (Ian Spence) в рамках SECR-2013. Ивар и Иэн рассказывали о развитии механизма Use Case, которое он прошел за более, чем 25 лет истории (первая идея — 1987), и расширившее его применение в разных направлениях так, что он по-прежнему адекватен современным потребностям разработки.
- Scaling Up with use cases. From small team to large project.
- Scaling out — not only req, also analysis, design, UX and so on.
- Zoom in — focused on essential, show big picture.
И это была не просто лекция, в которую иногда превращаются мастер-классы от мэтров. Был интерактив и практическая работа над заданиями в группах. Да, местами было повторение известных практик, знакомых большинству присутствующих, например, оценки, а местами достаточно сложные и интересные вещи были даны пунктиром из-за недостатка времени, но мастер-класс в целом я бы оценил высоко. Было последовательно показано применение Use Case при работе с требованиями.
Существенно новой для меня была конструкция Use Case Slice, деление Use Case в процессе работы. Суть в следующем. У нас есть цельный Use Case со всеми альтернативными сценариями. Естественным образом мы их приоритизируем, выделяя важные и примерно относя к релизам. Для этого можно использовать технику MoSCoW: Must/Should/Could/Want. Но вот когда мы говорим, что Use Case — must, это вовсе не означает, что таковыми являются все его сценарии. Мы делим Use Case на пакеты сценариев, кусочки, которые и называются slice. Они должны быть некоторым образом закончены, должна быть возможность их поименовать, их реализация должна давать некоторое business value и быть относительно независимой. И далее планирование релизов и итераций идет уже в терминах slice, которые приоритизируются и реализуются по отдельности. Естественно, с учетом зависимости, и в первый slice идет base flow, с учетом minimum viable value.
Но при этом Use Case сохраняется, он обладает целостностью более высокого порядка. А разработчики, проектируя реализацию (design), знают о других кусочках Use Case, которые надо будет сделать в будущем и учитывают их. Важно, что хотя декомпозиции на slice в конечном итоге подвергаются все Use Case, она выполняется по мере необходимости, а не изначально.
Вообще этот принцип детализации по необходимости применяется очень активно. И не только к декомпозиции Use Case, но и к различным артефактам, например, описанию Use Case и связанных с ним историй. И не в форме благих пожеланий к постепенной детализации, а через определение трех-четырех уровней детализации с формальными критериями и рекомендациями, для каких целей какие из них предназначены и на каких этапах появляются. При этом они не должны быть одинаковы по проекту, потому что Use Case и другие объекты имеют различную важность и сложность, и детализация должна быть им соразмерна.
В частности, была показана матрица техник для уровней описания Use Case в зависимости от критичности (относительно неверной работы) и частоты использования. Ожидаемо, что для критичных Use Case надо гораздо детальнее определять Test Case. А вот описание самого кейса больше зависит частоты использования: для ежедневных эффективнее краткое описание с активной коммуникацией, а вот для редко используемых, например, связанных с концом года, нужны подробные описания.
Помимо декомпозиции Use Case на slice были рассказаны следующие техники.
- Преобразование Use Case Slice в Test Case, которыми каждый slice снабжается и которые также могут иметь разный уровень детализации. Кстати, base flow может быть разложен на два или более slice, отличающихся именно Test Case: сначала делаем реализацию для единичных хороших данных, а потом — наращиваем вариативность и мощность.
- Преобразование нефункциональных требований в Use Case Slice со своими Test Case. При этом выбором Use Case, в которых это появится, заодно определяется область применения таких требований. Это можно делать не только с производительностью и масштабируемостью, но и с удобством использования (Test Case — 5 человек без обращения к помощи выполнили задание не более чем за…).
- Использование Use Case для больших компонентных систем, преобразование больших Use Case в соответствии с декомпозицией на Use Case для отдельных систем.
- Использование Use Case для требований на инфраструктурные аспекты кода, такие как аудит, лог изменений или безопасность.
А еще мастер-класс был элегантной демонстрацией Essence, разработанного SEMAT. Не в виде отдельных слайдов, а как практическое использование. Понятия — Use Case, Use Case Slice, Story — были представлены как альфы, для них описаны состояния, и уровни детализации для артефактов. Например, Use Case имеет состояния goal established → story structure understood → simplest story fulfilled → sugnificant story fulfilled → all stories fullfiled; а Use Case Slice — состояния scored → prepared → analyzed → implemented → verified, и для некоторых приводились checklist перехода. А уровни детализации, применяемые для историй и описаний, — sketch — base essential — enhansed — expanded — future expanded — с раскрытием каждого уровня и областями применения.
На этом я кончаю рассказ. Надо отметить, что на сайте Ивара доступна для скачивания после регистрации книга Use-Case 2.0 с материалами мастер-класса.