Управление требованиями,
Use cases, UML
Требования пользователей, сформулированные в виде текста,
могут трактоваться неоднозначно. В результате команда разработки
слышит ответ: "Да, это то, что написано в ТЗ, но не то, что мы хотели"
На тренинге вы:
могут трактоваться неоднозначно. В результате команда разработки
слышит ответ: "Да, это то, что написано в ТЗ, но не то, что мы хотели"
На тренинге вы:
- научитесь фиксировать требования в виде диаграмм,
- узнаете, как связать требования с архитектурой системы,
- создадите модели требований для своих реальных проектов.
“
7 перпендикулярных красных линий, 2 из них зелёным цветом, 3 прозрачным, 1 в форме котёнка.
На тренинге вы узнаете
- Как требования выявлять, документировать, оценивать, управлять ими и проверять предлагаемое решение.
- Как документировать требования текстом по классификации FURPS+ и в виде моделей вариантов использования (Use-case Model).
- Как работать с требованиями в итеративном процессе.
- Как приоритизировать требования.
- Как использовать атрибуты требований и трассировки для анализа запрашиваемых изменений.
Для кого этот тренинг?
Бизнес-аналитики и методологи
Узнают, спланировать свой день, как найти больше времени и успевать больше, как возвращаться домой с чувством удовлетворения.
Руководители и менеджеры
Узнают, организоваться работу команды или отдела, чтобы прогресс был заметен; как сформулировать достижимые цели и реалистичный план их достижения.
Системные аналитики и архитекторы
Узнает, выбрать самые важные цели и задачи; как отделить важное от неважного; почему не удаётся придерживаться нового графика; как поддерживать мотивацию и доводить дела до результата.
Тренер: Дмитрий Блинов
System analyst, IT project manager, Agile coach
Прошёл путь от веб-программиста до системного аналитика. Обучился и сертифицировался по UML, RUP, управлению требованиями с помощью вариантов использования (Use cases).
С 2009 года провожу тренинги по этим темам.
Затем занимал роли менеджера проектов и линейного руководителя 100 человек в крупных ИТ-компаниях и банках. Сертифицировался на PMI's PMP.
C 2017 работаю в роли Agile-коуча и консультанта, обучаю Scrum, пользовательским историям (User story), управлению бэклогом.
Я сам практикую то, что рекомендую клиентам.
С 2009 года провожу тренинги по этим темам.
Затем занимал роли менеджера проектов и линейного руководителя 100 человек в крупных ИТ-компаниях и банках. Сертифицировался на PMI's PMP.
C 2017 работаю в роли Agile-коуча и консультанта, обучаю Scrum, пользовательским историям (User story), управлению бэклогом.
Я сам практикую то, что рекомендую клиентам.
Тренер: Дмитрий Блинов
System analyst, IT project manager, Agile coach
Прошёл путь от веб-программиста до системного аналитика. Обучился и сертифицировался по UML, RUP, управлению требованиями с помощью вариантов использования (Use cases).
С 2009 года провожу тренинги по этим темам.
Затем занимал роли менеджера проектов и линейного руководителя 100 человек в крупных ИТ-компаниях и банках. Сертифицировался на PMI's PMP.
C 2017 работаю в роли Agile-коуча и консультанта, обучаю Scrum, пользовательским историям (User story), управлению бэклогом.
Я сам практикую то, что рекомендую клиентам.
С 2009 года провожу тренинги по этим темам.
Затем занимал роли менеджера проектов и линейного руководителя 100 человек в крупных ИТ-компаниях и банках. Сертифицировался на PMI's PMP.
C 2017 работаю в роли Agile-коуча и консультанта, обучаю Scrum, пользовательским историям (User story), управлению бэклогом.
Я сам практикую то, что рекомендую клиентам.
Это практический тренинг!
Каждая тема — блок из 4 частей
Немного теории
Кратко рассматривается тема, основные термины, зачем это нужно знать и уметь
Ответы на вопросы
Уточняющие вопросы от группы,
объяснение практического задания
объяснение практического задания
Много практики
Каждый выполняет задание индивидуально в контексте личный целей и задач. Обсуждение в парах и тройках
Обсуждение в группе
Сравнение результатов, ответы на новые вопросы, впечатления, применимость в жизни и работе
Хорошие требования — фактор успеха проекта
Потребности заказчика важно не только выявить, их необходимо однозначно зафиксировать и чётко структурировать, чтобы облегчить проектирование архитектуры системы, её разработку и тестирование.
Программа тренинга
Тренинг состоит из последовательного обсуждения и практического применения способов фиксации требований
Проблема и решение
Что такое "требование к системе"? Как отличить требование к системе от варианта решения?
Анализ проблемы клиента/заказчика.
Анализ проблемы клиента/заказчика.
Стейкхолдеры
Кто такие заинтересованные лица? Как их выявить? Как их классифицировать и взаимодействовать с ними.
Документирование требований
Классификация FURPS+.
Варианты использования — Use cases.
Моделирование бизнес-процессов.
Переход от бизнес-модели к модели ВИ.
Варианты использования — Use cases.
Моделирование бизнес-процессов.
Переход от бизнес-модели к модели ВИ.
RUP и диаграммы UML
Как модель Use-Cases синхронизирует другие модели UML в процессе Rational Unified Process (RUP).
Диаграммы UML
Модель вариантов использования UML.
Диаграммы Use-Case, Sequence, Communication, Activity.
Диаграммы Use-Case, Sequence, Communication, Activity.
Организация больших моделей
Структурирование модели Вариантов использования.
Мозговой штурм в ходе тренинга по Use cases & UML
Это пример мозгового штурма, выполненного в образовательных целях во время одного из тренингов по Управлению требованиями и вариантам использования в 2016 году.
Научитесь выявлять и упорядочивать требования
Берите известные требования к системе своего проекта с собой. На тренинге вы сможете оформить часть в виде вариантов использования или диаграмм UML.
Какие материалы вы получите после тренинга?
Я отправлю вам по почте слайды тренинга, фотографии всех результатов дискуссий и упражнений, ссылки на статьи, книги и видео для самостоятельного изучения.
Фотографии с тренингов
Я проводил тренинги по Вариантам использования, Управлению требованиями и UML для русскоговорящих и иностранных групп, очно и в дистанционном формате. Каждый раз это проходит интересно и живо, потому что рассматриваются не только учебные, но и реальные проекты участников.
“
У меня была одна проблема, поэтому я решил написать программу, которая её решит. Теперь у меня есть 1 проблема, 9 ошибок и 12 предупреждений.