Мастер-класс. Конструируем процесс разработки на основе практик SEMAT

SECR 2018
Юрий Куприянов
ИТ Эксперт, НИУ ВШЭ

Деловая игра, позволяющая сконструировать новый процесс разработки или улучшить уже существующий, используя библиотеку практик SEMAT.

Ожидаемая аудитория – ИТ-специалисты разного профиля, которые хотят поглубже разобраться, как устроен процесс разработки ПО, чем отличаются разные методики и из каких практик они формируются. Мастер-класс будет интересен всем, кто так или иначе задумывается о проектировании и улучшении деятельности команд разработки – тим-лидам, методологам, менеджерам проектов.

Transcript

1. SEMAT (OMG Essence) и моделирование метода ЮРИЙ КУПРИЯНОВ SECR’2018
2. В мире много методов приемов практик идеологий разработки ПО SCRUM Agile XP UML RUP MSF Use Cases Kanban Pair Programming Model Driven Development Jobs To Be Done V-model User Story Lean DevOps PRINCE2 ISO 12207 Continious Integration Waterfall BPMN OpenUP Definition of Done BDD Automate Testing Feature Driven Development Test Driven Development ГОСТ 34 ISO 24744 Literate Programming DSDM Lean UX ScrumBan ScrumButt
3. SCRUM
11. Ивар Якобсон UML, RUP, аспектно-ориентированное программирование Бертран Мейер Eiffel, ООП, контрактное программирование Ричард Солей OMG, UML, CORBA, MDA
12. сегодня серьезно страдает от незрелых практик. Основные проблемы: • Погоня за модой. • Отсутствие прочной, признанной теоретической базы. • Огромное число методов и их вариаций, различия которых искусственно преувеличены. • Отсутствие надежной экспериментальной оценки и проверки. • Разрыв между индустриальной практикой и академическими исследованиями. “Программная инженерия
13. Мы поддерживаем процесс нового основания программной инженерии – на твердой теории, проверенных принципах и лучших практиках, которые: • Включают в себя ядро согласованных элементов, расширяемых для конкретных применений. • Решают как технологические, так и человеческие вопросы. • Поддержаны индустрией, наукой и пользователями. • Поддерживают расширение в условиях меняющихся требований и технологий.
16. Software Engineering Method And Theory
17. Методы Methods Практики Practices Ядро The Kernel Язык The Language Методы состоят из практик Практики описаны элементами Ядра (как расширения) Методы, Практики и Ядро определены в терминах Языка OMG Essence: Kernel and Language
18. Поле деятельности Компетенция Дело Состояние альфы Рабочий продукт Имеет Требует Создает/изменяет Подтверждает Воплощается в Воплощается в Намечает Дело Дело Элементы языка: Альфа
19. Потребитель Решение Деятельность Альфы Возможность Стейкхолдер Требования Программная система Работа Технология работы Команда
20. Потребитель Решение Деятельность Связи Альф Возможность Стейкхолдер Требования Программная система Работа Технология работы Команда планирует и производит предоставляет удовлетворяет создает потребляет и использует задают ограничения поддерживает фокусирует
21. Потребитель Решение Деятельность Исследовать возможность Понять нужды Убедиться в удовлетворении Изучать использование системы Понять требова- ния Спроек- тировать систему Реализо- вать систему Обслу- живать систему Приготовиться выполнять работу Координи- ровать дела Поддерживать команду Отслеживать прогресс Протес- тировать систему Развер- нуть систему Прекратить работу Поля деятельности
22. Потребитель Решение Деятельность Анализ Разработка Представление интересов стейкхолдеров Лидерство Управление Тестирование Компетенции
23. SCRUM: Альфы и рабочие продукты
24. SCRUM: Дела
25. Потребитель Решение Деятельность Essence Kernel: Альфы Возможность Стейкхолдер Требования Программная система Работа Технология работы Команда
26. Собираем метод из практик Разработка мобильных приложений Kernel Метод разработки платформы Метод интеграции приложений Defect/Issue Tracking Git Flow Defect/Issue Tracking Git Flow Defect/Issue Tracking Git Flow Общие практики RUP Kanban Scrum Architecture Centric Emerging Architecture Emerging Architecture ТЗ по ГОСТ 34 Lean UX Use Cases Специфические практики DevOps DevOps DevOps Улучшения
27. Потребитель Решение Деятельность Возможность Стейкхолдеры Выявлены → Представлены → Вовлечены → В согласии → → Удовлетворены развертыванием Удовлетворены использованием Требования Прогр. система Архитектура выбрана → → → → Эксплуатируется → Готова к демонстрации Готова к использованию Готова к запуску Выведена из эксплуатации Работа Технология Команда Намечена → Сформирована → Сотрудничает → Производит → Распущена Замыслены → Ограничены → Непротиворечивы → Приемлемы → Адресованы → Удовлетворены Определена → → Оценена → Жизнеспособна → Адресована → Принесла выгоду Решается программной системой Принципы установлены → → Используется → Наличествует → → Основа положена Работает хорошо Выведена из употребления Инициирована → Подготовлена → Начата → Под контролем → Закончена → Закрыта
28. Состояние альфы Выявлены Представлены Вовлечены В согласии Удовлетворены развертыванием системы Удовлетворены работой системы Стейкхолдеры выявлены. Механизмы вовлечения стейкхолдеров согласованы, представители обозначены. Представители стейкхолдеров вовлечены в работу и выполняют свои обязанности. Представители стейкхолдеров находятся в согласии. Минимальные ожидания представителей стейкхолдеров удовлетворены. Система удовлетворяет или превышает минимальные ожидания стейкхолдеров.
29. Архитектура выбрана Готова к демонстрации Готова к использованию Готова к запуску Эксплуатируется Выведена из эксплуатации Выбрана архитектура, адресующая технические риски и удовлетворяющая организационным ограничениям. Работающая версия системы готова для демонстрации соответствия архитектуры и возможности тестирования. Система готова к использованию и демонстрирует заданные характеристики качества. Система была принята к развертыванию и запуску. Система используется в операционном окружении. Система больше не поддерживается. Система
30. Намечена Сформирована Сотрудничает Производит Распущена Чек-лист: Индивидуальные обязанности понимаются. Набрано достаточное число членов команды, чтобы работа продвигалась. Каждый член команды понимает, как команда организована, и какая у него индивидуальная роль. Все члены команды понимают, как выполнять их работу. Все члены команды встретились (возможно, виртуально) и начинают узнавать друг друга. Члены команды понимают их обязанности и как они увязаны с их компетенциями. Члены команды принимают работу. Любые внешние смежники (организации, команды и индивиды) определены. Механизмы общения в команде определены. Каждый член команды принял обязательство работать в команде, как определено. Команда была пополнена достаточным количеством людей с принятыми обязательствами, чтобы начать миссию. Команда
31. Software System Work Team Requirements http://www.slideshare.net/junesungpark/applying-essence-in-practiceberlin-ed
32. Достигнуты Не достигнуты http://www.slideshare.net/junesungpark/applying-essence-in-practiceberlin-ed
33. http://www.slideshare.net/junesungpark/applying-essence-in-practiceberlin-ed
35. Страница стандарта на сайте OMG: http://www.omg.org/spec/Essence/ Страницы про Essence в Wiki по системной инженерии: http://sewiki.ru/OMG_Essence (на русском). Инициатива SEMAT: http://www.semat.org/ Карты Essence на английском: https://www.ivarjacobson.com/alphastatecards Ссылки
36. Спасибо за внимание! Давайте пробовать! yksi12@gmail.com http://facebook.com/yksi12 skype: yury.kupriyanov 8-903-617-4283