В июне 2013 года в учебном центре Luxoft состоялся тренинг по управлению требованиями с помощью вариантов использования (requirements management with use cases). Программа тренинга размещена здесь. В начале тренинга участниками (они являются заказчиками проекта «Тренинг») в адрес исполнителя (тренера, меня) были озвучены ожидания от тренинга (это является примером процесса выявления потребностей заказчика). В ответ исполнителем (мной) были озвучены ограничения (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 человек, при этом в каждом следующем задании группы будут сформированы другим составов. Таким образом, на каждое упражнение формируются уникальные команды, что способствует развитию навыков общения и командной работы, которые очень важны для аналитиков. Результат выполнения задания команды изображают на досках (флипчартах) и защищают перед другой командой, отстаивая свою точку зрения – развитие навыков презентации и защиты идей. Ниже размещены фотографии, сделанные в ходе тренинга.

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

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

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

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

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

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

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

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

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

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

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

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

• Опрос требований у заказчика – по этой теме может быть проведён отдельный тренинг. Почитать о методах выявления требований можно здесь, а шаблон контекстно-независимого интервью можно найти тут.
• Системы управления требованиями – CASE-средства. Luxoft предлагает отдельный курсы по Sparx Enterprise Architect.
• Сравнительный анализ со Scrum’ом (достоинства, недостатки). Luxoft предлагает 2 отдельных курса по этой теме: “SDP-001 Обзор методологий разработки программного обеспечения” и “SDP-004 Основы методологии Agile для разработки ПО“.
• Вопросы управления содержанием/границами проекта (scope management).
• Вопросы калькуляции с заказчиком и разработчиком.
• Ещё больше практики.
• Проектирование UI. Luxoft предлагает по этой теме отдельный курс “Проектирование пользовательских интерфейсов“.

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

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

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

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

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

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

• Управление проектами – специализированные тренинги с углубленными изучением.
• Как работать с нефункциональными требованиями (в частности performance).
• UML основы.