Тренинг «Управление требованиями с помощью вариантов использования»: как это было?

В июне 2013 года в учебном центре Luxoft состоялся тренинг по управлению требованиями с помощью вариантов использования (requirements management with use cases). Программа тренинга размещена здесь. beamteamru_2013-06_goals-expectationsВ начале тренинга участниками (они являются заказчиками проекта «Тренинг») в адрес исполнителя (тренера, меня) были озвучены ожидания от тренинга (это является примером процесса выявления потребностей заказчика). В ответ исполнителем (мной) были озвучены ограничения (constraints) этого «проекта» по времени и содержанию, приведённые в карточке тренинга – это пример процесса управления ожиданиями заказчика (stakeholder expectations management). В ходе «ереговоров» стороны пришли к соглашению по качеству и содержанию проекта «Тренинг»: какие дополнительные темы добавляем к рассмотрению, какие базовые темы, напротив, изучаем с меньшей детализацией (меньшим качеством).

Озвученные ожидания участников (они же – «потребности заказчика», из них 1-9 составляют baseline):

  1. систематизировать знания;
  2. узнать больше «всего»;
  3. что делать с упущенными требованиями;
  4. облегчить/формализовать процесс в «госах»;
  5. reverse engineering;
  6. управление изменениями и границами/содержанием (scope);
  7. согласование с заказчиком и другими службами;
  8. когда не нужны use cases, и что применять в этом случае;
  9. UML;
  10. практика UML;
  11. отличие от Scrum.

Ограничения и реализация:

  1. Систематизировать знания – выполнено, как и на любом тренинге.
  2. Узнать больше «всего» – старались обсуждать и смежные темы, однако были ограничены во времени при довольно объёмной основной программе тренинга.
  3. Облегчить/формализовать процесс в «госах». Выполнение любых проектов в государственном секторе – это объёмная тема, требующая отдельного курса или семинара, но мы обсудили, каким образом можно
    • формализовать процесс управления требованиями,
    • выявлять потребности (см. Методы сбора требований),
    • вовлекать заинтересованные стороны (заказчика, пользователей, команду),
    • оформлять потребности и требования,
    • согласовывать базовый набор функционала (а если точнее, то features. Чем они отличаются от функций системы?),
    • управлять изменениями требований (change requests),
    • следить за границами/содержанием проекта (scope),
    • планировать итерации и много другое.
  4. Что делать с упущенными требованиями – правильный хороший процесс с вовлечением всех необходимых заинтересованных влияющих сторон сводит количество таких требований к минимуму. Здесь важно не путать уточнение ранее выявленных ещё не детализированных требований и появление совершенно новых требований.
  5. Reverse engineering – обсудили, что он более интересен на следующем этапе RUP «Объектно-ориентированный анализ и проектирование (req-003)» (Object-oriented analysis and design). Полезным инструментом для осуществления прямых и обратных проходов между артефактами процесса (потребности, требования, функции, варианты использования, классы, атрибуты и операции, компоненты, подсистемы и пр.) является «трассировка».
  6. Управление изменениями и границами/содержанием (scope) – рассмотрено подробно.
  7. Согласование с заказчиком и другими службами – обсудили методы и необходимость выявления как можно большего количества заинтересованных сторон, выбора стратегии работы с ними, раннего вовлечения в процесс создания системы и артефактов проекта.
  8. Когда не нужны use cases, и что применять в этом случае – рассмотрено подробно.
  9. UML – посещение курса «Основы визуального моделирования с помощью UML (req-001)» является предусловием участия в тренинге по use case’ам. Однако мы кратко ознакомились с материалами вводной презентации к этому курсу, а также, встречая в материалах тренинга какую-либо диаграмму нотации UML, мы рассматривали её подробнее.

Дополнительно в следующие дни были добавлены пожелания (пример процессов управления ожиданиями заказчика, управления изменениями и управления содержанием проекта «Тренинг»):

  1. Практика UML – данный конкретный тренинг не рассчитан на использование нотации UML, поскольку в общем случае варианты использования на 80% состоят из текста. В ходе тренинга мы кратко рассмотрели диаграммы, с помощью которых могут изображаться потоки use case’ов. Это диаграммы: activity, sequence (interaction), communication (interaction).
  2. Отличие от Scrum – на нюансах различий, к сожалению, остановиться не удалось ввиду ограниченности во времени. Посещение курсов «SDP-001 Обзор методологий разработки программного обеспечения» (MSF, RUP, eXP, Scrum) и «SDP-002 Основы методологии IBM Rational Unified Process для разработки ПО» является предусловием участия в тренинге по use case’ам.

Как проходит тренинг? Выполнение упражнений

Примерно треть времени тренинга отводится на выполнение практических заданий. Участники тренинга делятся на группы по 4-5 человек, при этом в каждом следующем задании группы будут сформированы другим составов. Таким образом, на каждое упражнение формируются уникальные команды, что способствует развитию навыков общения и командной работы, которые очень важны для аналитиков. Результат выполнения задания команды изображают на досках (флипчартах) и защищают перед другой командой, отстаивая свою точку зрения — развитие навыков презентации и защиты идей. Ниже размещены фотографии, сделанные в ходе тренинга.

Выявление корневых причин проблемы и проверка пригодности предлагаемого решения:

beamteamru_2013-06_analize-problem

Выявление заинтересованных лиц (stakeholders) и актёров (actors):

beamteamru_2013-06_identify-stakeholders-actors

Определение границ системы – выявление актёров и вариантов использования:

beamteamru_2013-06_identify-use-cases

Создание набросков (outline) вариантов использования:

beamteamru_2013-06_outline-use-cases

Мозговой штурм:

beamteamru_2013-06_brainstorming-1

beamteamru_2013-06_brainstorming-2

Голосование за варианты оформления детальной текстовой спецификации вариантов использования:

beamteamru_2013-06_choose-style

Отзывы участников тренинга

Общее впечатление участников от тренинга:

  • Первый опыт, полезен, занимателен.
  • Хорошее, но хотелось бы увеличить на него время.
  • Интересно и полезно.
  • Положительное.
  • Очень доволен, узнал много нового, стал лучше понимать use cases.
  • Отличный тренинг, спасибо!

Наиболее полезным для участников тренинга оказалось:

  • Весь курс целиком, как один из вводных моментов в сборе и анализе требований.
  • Систематизирование знаний по разработке и управлению требованиями, процессы управления требованиями (3).
  • Практические задания (2), жизненные примеры.
  • Большое количество обсуждений процессов управления требованиями в группах, коммуникации внутри групп.
  • Разбор близких к реальным проектам ситуаций с разных сторон (пример с системой электронной торговли на бирже).
  • Методология RUP, её артефакты и способы их разработки (2).
  • Случаи, когда нужны и когда НЕ нужны use cases.
  • Мозговой штурм – замечательно!

Темы, которые участникам тренинга хотелось бы разобрать более детально:

Рекомендации и комментарии участников тренинга

Рекомендации к учебным материалам:

  • Перевести материалы на русский язык (3 из 8 участников) – UML, RUP и смежные дисциплины целесообразно изучать на английском языке, поскольку различные коллективы переводчиков, зачастую не являющихся экспертами в разработке ПО, переводят одни и те же термины по-разному, чем порождают двусмысленности и недопонимания. Самый простой, но важный прецедент неправильного перевода описан здесь.
  • Выдавать ученикам электронную версию материалов/слайдов – материалы защищены авторским правом учебного центра.
  • Объединить раздаточный материал в единое целое с маркерами – рекомендация учтена, материалы объединены в 3 больших комплекта: теория, задания, ответы.

Рекомендации к организации тренинга:

  • Увеличить время тренинга на 1-2 дня для более детального обсуждения ряда вопросов, т.к. многие темы хотелось бы разобрать более детально (6/8).

Дополнительно участникам интересны тренинги по следующим темам:

Comments

comments

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *