Персональные инструменты
 

2013-10-23: SECR. Мастер-класс Ивара Якобсона Use-Case 2.0

Материал из CustisWiki

Перейти к: навигация, поиск
(Новая страница: «Очень понравился [http://2013.secr.ru/lang/ru/courses/use-case-2-0-the-lightness-of-user-stories-with-the-power-of-modeling мастер-класс…»)
 
м
Строка 1: Строка 1:
Очень понравился [http://2013.secr.ru/lang/ru/courses/use-case-2-0-the-lightness-of-user-stories-with-the-power-of-modeling мастер-класс Use-Case 2.0], который проводили Ивар Якобсон (Ivar Jakobson) и Иэн Спенс (Ian Spence) в рамках SECR-2013. Ивар и Иэн рассказывали о развитии механизма Use Case, который он прошел за более, чем 25 лет истории (первая идея - 1987), и который расширил его применение в разных направлениях так, что он по-прежнему адекватен современным потребностям разработки.  
+
Очень понравился [http://2013.secr.ru/lang/ru/courses/use-case-2-0-the-lightness-of-user-stories-with-the-power-of-modeling мастер-класс Use-Case 2.0], который проводили Ивар Якобсон (Ivar Jakobson) и Иэн Спенс (Ian Spence) в рамках SECR-2013. Ивар и Иэн рассказывали о развитии механизма Use Case, который он прошел за более, чем 25 лет истории (первая идея — 1987), и который расширил его применение в разных направлениях так, что он по-прежнему адекватен современным потребностям разработки.
 
* Scaling Up with use cases. From small team to large progect.
 
* Scaling Up with use cases. From small team to large progect.
* Scaling out - not only req, also analysis, design, UX and so on.
+
* Scaling out — not only req, also analysis, design, UX and so on.
* Zoom in - focused on essential, show big picture.
+
* Zoom in — focused on essential, show big picture.
И это была не просто лекция, в которую иногда превращаются мастер-классы от мэтров. Был интерактив и практическая работа над заданиями в группах. Да, местами было повторение известных практик, знакомых большинству присутствующих, например, оценки, а местами достаточно сложные и интересные вещи были даны пунктиром из-за недостатка времени, но мастер-класс в целом я бы оценил высоко. Было последовательно показано применение use case при работе с требованиями.  
+
И это была не просто лекция, в которую иногда превращаются мастер-классы от мэтров. Был интерактив и практическая работа над заданиями в группах. Да, местами было повторение известных практик, знакомых большинству присутствующих, например, оценки, а местами достаточно сложные и интересные вещи были даны пунктиром из-за недостатка времени, но мастер-класс в целом я бы оценил высоко. Было последовательно показано применение use case при работе с требованиями.
  
Существенно новой для меня была конструкция use case spice, деление use case в процессе работы. Суть в следующем. У нас есть цельный use case со всеми альтернативными сценариями. Естественным образом мы из приоритизируем, выделяя важные и примерно относя к релизам. Для этого можно использовать технику MoSCoW: Must/Should/Could/Want. Но вот когда мы говорим, что use case - must, это вовсе не означает, что таковыми являются все его сценарии. Мы делим use case на пакеты сценариев, кусочки, которые и называются spice. Они должны быть некоторым образом закончены, их должно быть можно поименовать, их реализация должна давать некоторое business value и быть относительно независимой. И далее планирование релизов и итераций идет уже в терминах spice, которые приоритизируются и реализуются по-отдельности. Естественно, с учетом зависимости, и в первый spice идет base flow, с учетом minimum viable value.  
+
Существенно новой для меня была конструкция use case spice, деление use case в процессе работы. Суть в следующем. У нас есть цельный use case со всеми альтернативными сценариями. Естественным образом мы из приоритизируем, выделяя важные и примерно относя к релизам. Для этого можно использовать технику MoSCoW: Must/Should/Could/Want. Но вот когда мы говорим, что use case — must, это вовсе не означает, что таковыми являются все его сценарии. Мы делим use case на пакеты сценариев, кусочки, которые и называются spice. Они должны быть некоторым образом закончены, их должно быть можно поименовать, их реализация должна давать некоторое business value и быть относительно независимой. И далее планирование релизов и итераций идет уже в терминах spice, которые приоритизируются и реализуются по-отдельности. Естественно, с учетом зависимости, и в первый spice идет base flow, с учетом minimum viable value.
  
Но при этом use case сохраняется, он обладает целостностью более высокого порядка. А разработчики, проектируя реализацию (design), знают о других кусочках use case, которые надо будет сделать в будущем и учитывают их. Важно, что хотя декомпозиции на spice в конечном итоге подвергаются все use case, она выполняется по мере необходимости, а не изначально.  
+
Но при этом use case сохраняется, он обладает целостностью более высокого порядка. А разработчики, проектируя реализацию (design), знают о других кусочках use case, которые надо будет сделать в будущем и учитывают их. Важно, что хотя декомпозиции на spice в конечном итоге подвергаются все use case, она выполняется по мере необходимости, а не изначально.
  
Вообще этот принцип детализации по необходимости - он применяется очень активно. И не только к декомпозиции use case, но и к различным артефактам, например, описанию use case и связанных с ним историй. И не в форме благих пожеланий к постепенной детализации, а через определение трех-четырех уровней детализации с формальными критериями, и рекомендациями, для каких целей какие из них предназначены, и на каких этапах появляются. При этом они не должны быть одинаковы по проекту, потому что use case и другие объекты имеют различную важность и сложность, и детализация должна быть им соразмерна.
+
Вообще этот принцип детализации по необходимости — он применяется очень активно. И не только к декомпозиции use case, но и к различным артефактам, например, описанию use case и связанных с ним историй. И не в форме благих пожеланий к постепенной детализации, а через определение трех-четырех уровней детализации с формальными критериями, и рекомендациями, для каких целей какие из них предназначены, и на каких этапах появляются. При этом они не должны быть одинаковы по проекту, потому что use case и другие объекты имеют различную важность и сложность, и детализация должна быть им соразмерна.
  
В частности, была показана матрица техник для уровней описания use case в зависимости от критичности (относительно неверной работы) и частоты использования. Ожидаемо, что для критичных use case надо гораздо детальнее определять test case. А вот описание самого кейса больше зависит частоты использования: для ежедневных эффективнее краткое описание с активной коммуникацией, а вот для редко используемых, например, связанных с концом года, нужны подробные описания.  
+
В частности, была показана матрица техник для уровней описания use case в зависимости от критичности (относительно неверной работы) и частоты использования. Ожидаемо, что для критичных use case надо гораздо детальнее определять test case. А вот описание самого кейса больше зависит частоты использования: для ежедневных эффективнее краткое описание с активной коммуникацией, а вот для редко используемых, например, связанных с концом года, нужны подробные описания.
  
 
Помимо декомпозиции use case на spice были рассказаны следующие техники.
 
Помимо декомпозиции use case на spice были рассказаны следующие техники.
* Преобразование use case spice в test case, которыми каждый spice снабжается, и которые также могут иметь разный уровень детализации. Кстати, base flow может быть разложен на два или более spice, отличающихся именно test case: сначала делаем реализацию для единичных хороших данных, а потом - наращиваем вариативность и мощность.
+
* Преобразование use case spice в test case, которыми каждый spice снабжается, и которые также могут иметь разный уровень детализации. Кстати, base flow может быть разложен на два или более spice, отличающихся именно test case: сначала делаем реализацию для единичных хороших данных, а потом — наращиваем вариативность и мощность.
* Преобразование нефункциональных требований в use case spice со своими test case. При этом выбором use case, в которых это появится, заодно определяется область применения таких требований. Это можно делать не только с производительностью и масштабируемостью, но и с удобством использования (test case - 5 человек без обращения к помощи выполнили задание не более чем за...)
+
* Преобразование нефункциональных требований в use case spice со своими test case. При этом выбором use case, в которых это появится, заодно определяется область применения таких требований. Это можно делать не только с производительностью и масштабируемостью, но и с удобством использования (test case — 5 человек без обращения к помощи выполнили задание не более чем за…)
 
* Использование use case для больших компонентных систем, преобразование больших use case в соответствии с декомпозицией на use case для отдельных систем
 
* Использование use case для больших компонентных систем, преобразование больших use case в соответствии с декомпозицией на use case для отдельных систем
 
* Использование use case для требований на инфраструктурные аспекты кода, такие как аудит, лог изменений или безопасность.
 
* Использование use case для требований на инфраструктурные аспекты кода, такие как аудит, лог изменений или безопасность.
  
А еще мастер-класс был элегантной демонстрацией Essence, разработанного SEMAT. Не в виде отдельных слайдов, а как практическое использование. Понятия - use case, use case spice, story - были представлены как альфы, для них описаны состояния, и уровни детализации для артефактов. Например, use case имеет состояния goal established → story structure understood → simplest story fulfilled → sugnificant story fulfilled → all stories fullfiled; а use case spice - состояния scored → prepared → analyzed → implemented → verified, и для некоторых приводились checklist перехода. А уровни детализации применяемые для историй и описаний - sketch - base essential - enhansed - expanded - future expanded, с раскрытием каждого уровня и областями применения.
+
А еще мастер-класс был элегантной демонстрацией Essence, разработанного SEMAT. Не в виде отдельных слайдов, а как практическое использование. Понятия — use case, use case spice, story — были представлены как альфы, для них описаны состояния, и уровни детализации для артефактов. Например, use case имеет состояния goal established → story structure understood → simplest story fulfilled → sugnificant story fulfilled → all stories fullfiled; а use case spice — состояния scored → prepared → analyzed → implemented → verified, и для некоторых приводились checklist перехода. А уровни детализации применяемые для историй и описаний — sketch — base essential — enhansed — expanded — future expanded, с раскрытием каждого уровня и областями применения.
  
На этом я кончаю рассказ. Надо отметить, что на сайте Ивара доступна для скачивания после регистрации книга [http://www.ivarjacobson.com/Use_Case2.0_ebook/ Use-Case 2.0] с материалами мастер-класса.  
+
На этом я кончаю рассказ. Надо отметить, что на сайте Ивара доступна для скачивания после регистрации книга [http://www.ivarjacobson.com/Use_Case2.0_ebook/ Use-Case 2.0] с материалами мастер-класса.
  
{{wl-publish: 2013-10-24 01:34:04 +0400 | MaksTsepkov }}
+
{{wl-publish: 2013-10-24 01:30:28 +0400 | MaksTsepkov }}
 
+
{{replicate-from-custiswiki-to-lib}}[[Категория:SECR-2013]]
[[Категория:Конференции]]
+

Версия 01:10, 24 октября 2013

Очень понравился мастер-класс Use-Case 2.0, который проводили Ивар Якобсон (Ivar Jakobson) и Иэн Спенс (Ian Spence) в рамках SECR-2013. Ивар и Иэн рассказывали о развитии механизма Use Case, который он прошел за более, чем 25 лет истории (первая идея — 1987), и который расширил его применение в разных направлениях так, что он по-прежнему адекватен современным потребностям разработки.

  • Scaling Up with use cases. From small team to large progect.
  • Scaling out — not only req, also analysis, design, UX and so on.
  • Zoom in — focused on essential, show big picture.

И это была не просто лекция, в которую иногда превращаются мастер-классы от мэтров. Был интерактив и практическая работа над заданиями в группах. Да, местами было повторение известных практик, знакомых большинству присутствующих, например, оценки, а местами достаточно сложные и интересные вещи были даны пунктиром из-за недостатка времени, но мастер-класс в целом я бы оценил высоко. Было последовательно показано применение use case при работе с требованиями.

Существенно новой для меня была конструкция use case spice, деление use case в процессе работы. Суть в следующем. У нас есть цельный use case со всеми альтернативными сценариями. Естественным образом мы из приоритизируем, выделяя важные и примерно относя к релизам. Для этого можно использовать технику MoSCoW: Must/Should/Could/Want. Но вот когда мы говорим, что use case — must, это вовсе не означает, что таковыми являются все его сценарии. Мы делим use case на пакеты сценариев, кусочки, которые и называются spice. Они должны быть некоторым образом закончены, их должно быть можно поименовать, их реализация должна давать некоторое business value и быть относительно независимой. И далее планирование релизов и итераций идет уже в терминах spice, которые приоритизируются и реализуются по-отдельности. Естественно, с учетом зависимости, и в первый spice идет base flow, с учетом minimum viable value.

Но при этом use case сохраняется, он обладает целостностью более высокого порядка. А разработчики, проектируя реализацию (design), знают о других кусочках use case, которые надо будет сделать в будущем и учитывают их. Важно, что хотя декомпозиции на spice в конечном итоге подвергаются все use case, она выполняется по мере необходимости, а не изначально.

Вообще этот принцип детализации по необходимости — он применяется очень активно. И не только к декомпозиции use case, но и к различным артефактам, например, описанию use case и связанных с ним историй. И не в форме благих пожеланий к постепенной детализации, а через определение трех-четырех уровней детализации с формальными критериями, и рекомендациями, для каких целей какие из них предназначены, и на каких этапах появляются. При этом они не должны быть одинаковы по проекту, потому что use case и другие объекты имеют различную важность и сложность, и детализация должна быть им соразмерна.

В частности, была показана матрица техник для уровней описания use case в зависимости от критичности (относительно неверной работы) и частоты использования. Ожидаемо, что для критичных use case надо гораздо детальнее определять test case. А вот описание самого кейса больше зависит частоты использования: для ежедневных эффективнее краткое описание с активной коммуникацией, а вот для редко используемых, например, связанных с концом года, нужны подробные описания.

Помимо декомпозиции use case на spice были рассказаны следующие техники.

  • Преобразование use case spice в test case, которыми каждый spice снабжается, и которые также могут иметь разный уровень детализации. Кстати, base flow может быть разложен на два или более spice, отличающихся именно test case: сначала делаем реализацию для единичных хороших данных, а потом — наращиваем вариативность и мощность.
  • Преобразование нефункциональных требований в use case spice со своими test case. При этом выбором use case, в которых это появится, заодно определяется область применения таких требований. Это можно делать не только с производительностью и масштабируемостью, но и с удобством использования (test case — 5 человек без обращения к помощи выполнили задание не более чем за…)
  • Использование use case для больших компонентных систем, преобразование больших use case в соответствии с декомпозицией на use case для отдельных систем
  • Использование use case для требований на инфраструктурные аспекты кода, такие как аудит, лог изменений или безопасность.

А еще мастер-класс был элегантной демонстрацией Essence, разработанного SEMAT. Не в виде отдельных слайдов, а как практическое использование. Понятия — use case, use case spice, story — были представлены как альфы, для них описаны состояния, и уровни детализации для артефактов. Например, use case имеет состояния goal established → story structure understood → simplest story fulfilled → sugnificant story fulfilled → all stories fullfiled; а use case spice — состояния scored → prepared → analyzed → implemented → verified, и для некоторых приводились checklist перехода. А уровни детализации применяемые для историй и описаний — sketch — base essential — enhansed — expanded — future expanded, с раскрытием каждого уровня и областями применения.

На этом я кончаю рассказ. Надо отметить, что на сайте Ивара доступна для скачивания после регистрации книга Use-Case 2.0 с материалами мастер-класса.


Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Блог:Максима Цепкова/2013-10-23: SECR. Мастер-класс Ивара Якобсона Use-Case 2.0»