Как выбрать для проекта практики проектирования и работы с требованиями (Максим Цепков на AnalystDays-2017). Страница доклада http://mtsepkov.org/Methods4req
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
Опыт применения метода ATAM для оценки архитектурыCUSTIS
Выступление Игоря Беспальчука, нашего руководителя проектов дирекции архитектуры, на заседании русского отделения INCOSE (9 ноября 2016 года, Москва).
Видеозапись выступления:
https://vimeo.com/190918892
6 апреля 2013 г. в омском филиале Luxoft прошел пятый IT-субботник – открытая встреча для IT-специалистов. Максим Юнусов, тренер Luxoft Training по анализу и проектированию ПО, представил доклад «Архитектура в Agile проекте».
В своем выступлении Максим рассказал об архитектуре в «раннем» и в «развитом» Agile, принципах дизайна, мифе о рефакторинге и факторах качества по Бертрану Мейеру, а также о качествах, ценных в Agile, и архитектурных взаимодействиях в Agile проектах.
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
Опыт применения метода ATAM для оценки архитектурыCUSTIS
Выступление Игоря Беспальчука, нашего руководителя проектов дирекции архитектуры, на заседании русского отделения INCOSE (9 ноября 2016 года, Москва).
Видеозапись выступления:
https://vimeo.com/190918892
6 апреля 2013 г. в омском филиале Luxoft прошел пятый IT-субботник – открытая встреча для IT-специалистов. Максим Юнусов, тренер Luxoft Training по анализу и проектированию ПО, представил доклад «Архитектура в Agile проекте».
В своем выступлении Максим рассказал об архитектуре в «раннем» и в «развитом» Agile, принципах дизайна, мифе о рефакторинге и факторах качества по Бертрану Мейеру, а также о качествах, ценных в Agile, и архитектурных взаимодействиях в Agile проектах.
Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQA Day...CUSTIS
Выступление Максима Цепкова, нашего главного архитектора дирекции по развитию решений, на конференции Software Quality Assurance Days (2–3 декабря 2011 года, Москва).
Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
Б.Позин, Е.Горбунова -- развитие ядра Essence для стадии сопровожденияAnatoly Levenchuk
Доклад Бориса Позина и Eвгении Горбуновой "Предложение по развитию ядра OMG Essence для обеспечения процессов жизненного цикла программных систем" на 97 заседании INCOSE, 26 ноября 2014г.
Внедрение юзабилити практик в процесс разработки ПО в соответствии с СMMI - д...Julia Kryuchkova
Авторы: Юлия Крючкова, Дмитрий Павлов. Доклад для конференции CEE-SECR 2010 (http://2010.secr.ru)
Сравнение практик юзабилити и рекоммендаций раздела "Валидация" CMMI.
Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQA Day...CUSTIS
Выступление Максима Цепкова, нашего главного архитектора дирекции по развитию решений, на конференции Software Quality Assurance Days (2–3 декабря 2011 года, Москва).
Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
Б.Позин, Е.Горбунова -- развитие ядра Essence для стадии сопровожденияAnatoly Levenchuk
Доклад Бориса Позина и Eвгении Горбуновой "Предложение по развитию ядра OMG Essence для обеспечения процессов жизненного цикла программных систем" на 97 заседании INCOSE, 26 ноября 2014г.
Внедрение юзабилити практик в процесс разработки ПО в соответствии с СMMI - д...Julia Kryuchkova
Авторы: Юлия Крючкова, Дмитрий Павлов. Доклад для конференции CEE-SECR 2010 (http://2010.secr.ru)
Сравнение практик юзабилити и рекоммендаций раздела "Валидация" CMMI.
www.cmcons.com. Практика и технология внедрения процесса конфигурационного управления и управления изменениями с применением IBM Rational ClearCase и ClearQuest
Dnepr iOS Club #2
Speaker - Александр Колесник, middle iOS developer at WOXAPP
Тема: “MVVM vs Viper. Что и как выбирать?”
Тезисы:
- подробно разберем каждый из паттернов проектирования
- определим минусы и плюсы использования MVVM
- определим минусы и плюсы использования Viper
- проведем сравнение - определим как выбирать архитектуру для своего проекта.
Уровень: middle и выше.
Cистемная инженерия безопасности объектов недвижимости и бизнес-процессов.Yuri Bubnov
Структура метода системной инженерии безопасности объектов недвижимости и бизнес-процессов, основанного на международных стандартах ISO 24744, ISO 31000, ISO 22301, Archimate, OMG Essence и работах видных зарубежных учёных Nancy Leveson (MIT), Donald Firesmith (SEI).
Достоинства и ограничения проектных моделей водопада и гибких подходов: скрам, аджайл (scrum, agile).
Как на основе специфичных характеристик проекта подобрать модели планирования и управления ИТ проектом
From Agile to Teal Organization PRyug-2017Maxim Tsepkov
Будущее уже наступило: от Agile к Бирюзовым организациям. http://mtsepkov.org/Agile-PRyug Дни PR и маркетинга на Юге 2017 - рассказ про Agile и тренды развития организаций для не специалистов, вне IT
Доклад на SQAdays весной 2017 в Москве. Страница доклада http://mtsepkov.org/SelfDet Проблема самоопределения, конструирования своего будущего в современном мире становится все актуальнее, в отличие от мира прошлого, в котором ты определялся всего пару раз, выбирая профессию и создавая семью, да и то это часто делали за тебя родители. А сейчас ты должен делать это регулярно, да еще - в быстро развивающемся мире, что особенно заметно в мире IT, на фоне бурного развития технологий. У меня сформировалась сборка из схем, которые помогают это делать.
Agile and the Third Wave (IT Spring 2017)Maxim Tsepkov
http://mtsepkov.org/AgileAgainstThirdWave Развитие на конференции IT Spring доклада на AgileDays-2017 Третья промышленная революция, которая была предсказана в далеком 1980 году Элвисом Тоффлером в книге «Третья волна», уже перестала быть делом будущего, а становится частью настоящего. Вызовы, которые она несла, в первую очередь пришли в IT-отрасль в конце 20 века. А в начале 21 века появился ответ на них — практики Agile, которые развиваются уже полтора десятилетия, в том числе вбирая из традиционного менеджмента все ценное и применимое в будущем мире. Сейчас новые вызовы и связанная с ними турбулентность идут в другие отрасли, которые могут в ответ изобретать собственные практики, а могут воспользоваться апробированными ответами Agile, наполнив его практики своей спецификой. Темп изменений в разных отраслях различается, однако приход нового неизбежен, потому что изменился mindset нового поколения соцсетей — тех, кто начал активно общаться и завоевывать лидерство в виртуальном пространстве еще в школе. И по мере того, как такие люди будут приходить в организации, они будут необратимо менять их культуру. Распространение бирюзовых организаций, описанных Фредериком Лалу в книге «Открывая организации будущего», — зримое проявление этих изменений. И вовсе не случайно организационный фреймворк для таких компаний — холакратия — тоже появился в IT-отрасли и распространяется за ее пределы. В докладе будет описана big picture современного развития, в которой каждой из организаций предстоит самоопределиться и выбрать собственный путь.
Диаграммы учета как средство для наглядного и целостного отображения правил учета. Страница доклада http://mtsepkov.org/AccDiagramEcon Международный экономический симпозиум - Соколовские чтения 2017
Agile - ответ на вызовы третьей промышленной революции - цепков custisMaxim Tsepkov
http://mtsepkov.org/AgileAgainstThirdWave доклад на AgileDays-2017 Третья промышленная революция, которая была предсказана в далеком 1980 году Элвисом Тоффлером в книге «Третья волна», уже перестала быть делом будущего, а становится частью настоящего. Вызовы, которые она несла, в первую очередь пришли в IT-отрасль в конце 20 века. А в начале 21 века появился ответ на них — практики Agile, которые развиваются уже полтора десятилетия, в том числе вбирая из традиционного менеджмента все ценное и применимое в будущем мире. Сейчас новые вызовы и связанная с ними турбулентность идут в другие отрасли, которые могут в ответ изобретать собственные практики, а могут воспользоваться апробированными ответами Agile, наполнив его практики своей спецификой. Темп изменений в разных отраслях различается, однако приход нового неизбежен, потому что изменился mindset нового поколения соцсетей — тех, кто начал активно общаться и завоевывать лидерство в виртуальном пространстве еще в школе. И по мере того, как такие люди будут приходить в организации, они будут необратимо менять их культуру. Распространение бирюзовых организаций, описанных Фредериком Лалу в книге «Открывая организации будущего», — зримое проявление этих изменений. И вовсе не случайно организационный фреймворк для таких компаний — холакратия — тоже появился в IT-отрасли и распространяется за ее пределы. В докладе будет описана big picture современного развития, в которой каждой из организаций предстоит самоопределиться и выбрать собственный путь.
Process and Case Management together (SECR-2016)Maxim Tsepkov
Подробнее - http://mtsepkov.org/Process_and_Case-SECR Process & Case Management в информационной системе:от автоматизации As Is к поддержке развития бизнеса - доклад на SECR-2016.
Эволюция организаций и эволюция сотрудника – как изменяется понятие о прави...Maxim Tsepkov
Подъем по уровням ценностей Спиральной динамики меняет содержание, вкладываемое в такие, казалось бы, понятные действия, такие как вписаться в коллектив или завершить проект, и наполняет новым содержанием понятия целеполагания, ответственности, осмысленности действий, решения конфликтов, которые лежат в основе бирюзовых организаций.
Taxonomy vs folksonomy Tsepkov Analyst Days 2016Maxim Tsepkov
http://mtsepkov.org/SMD-AnalystDays2016 Коммуникация при различной структуре мышления - таксономия против фолксономии. Выступление Максима Цепкова на AnalystDays-2016.
Spiral dynamics in use tsepkov sqadays-16Maxim Tsepkov
Спиральная динамика как призма для взгляда на мир ИТ-шника. Подробности и видео http://mtsepkov.org/SpiralDynamics-SQAdays Выступление на SQAdays-16 14.11.2014 в Санкт-Петербурге.
Domain driven design (DDD) - отражение модели предметной области в код (Максим Цепков на Software People 2013). Подробнее http://mtsepkov.org/DDD_problem_and_solving
Choose method for requirements Tsepkov Analyst Days-2017
1. Как выбрать для проекта
практики проектирования
и работы с требованиями
Максим Цепков
Главный архитектор дирекции развития решений
Москва, 21–22 апреля 2017
Analyst Days
И собрать из них целостный метод
2. Что такое «требования»: два ответа
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
На V-диаграмме (Wikipedia)
требования – внешние
функции системы
Я буду говорить
о требованиях в широком
понимании OMG Essence
Concept Maintenance
2/35
3. Когда-то давно проектирование считалось
искусством – как стиль художника
Потом начали верить в правильный метод,
который знают гуру
И когда Rational собрал трех методологов, Гради Буча,
Ивара Якобсона и Джеймса Рамбо, у этой веры даже
появились основания – родился UML. Но не случилось
Потом пришло многообразие легких методов:
проекты разные, и делать их надо по-разному
Надо ли собирать метод?
3/35
4. Big Picture развития методов
Эпоха НИОКР: делаем правильную систему
Время
Способ
работы
«Новое время»
Удовлетворенность стейкхолдеров
Достижение бизнес-целей продукта
Эпоха RUP: делаем систему правильно
Время Scrum: движемся к цели
1960 1990 2005 2013
Подробности – в докладах «Развитие критериев качества и управления
проектами» на AgileDays – 2015 и «Ответственность за качество в разных ИТ-
проектах» на SQA Days – 20
4/35
5. Я не буду делать обзор методов –
о каждом можно прочитать
Я расскажу о вопросах, с помощью которых
можно выбрать метод или собрать свой
Речь пойдет о работе с требованиями,
а бизнес-анализ, проектирование и смежные
области будут только затрагиваться
О чем будет доклад
Метод для работы с требованиями
правильно собирать аналитикам:
каждый сам кузнец своего счастья
5/35
6. Как определяем границы проекта?
Как декомпозируем и инкрементально
развиваем?
Как обеспечиваем качество?
Как организуем артефакты?
OMG Essence – способ описать метод
План рассказа
6/35
8. V-модель как карта проекта
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
V-Model (Wikipedia)
Пользователи
Needs and
Opportunities
Concept Maintenance
Delivery
Заказчик
ИТ-система
Concept
8/35
11. IT-проект внутри бизнес-проекта?
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
ИТ-система
Бизнес-проект
Needs and
Opportunities Delivery
Needs and
Opportunities
Delivery
11/35
12. Или IT и бизнес делают совместный
проект?
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
В современных проектах граница между IT-частью проекта и изменением
бизнеса подвижна и меняется в ходе проекта, а диджитализация
означает, что проект будет единым, а IT-часть – главной!
Needs and
Opportunities
Delivery
12/35
13. Исходные данные для проекта – потребности
пользователей или внешние функции?
Насколько жестко надо фиксировать внешний
контур проекта и трассировать к нему решения?
Какие используем форматы: user story, use case,
описания фич, классические требования?
Требования и потребности – внешний
контур проекта
Это зависит от стейкхолдеров, заказывающих
проект, – как они видят границы и их описание?
13/35
14. Первоначально требования описывали функции
системы и систему как целое
Выяснилось, что сделанные так системы
оказываются неудобны или непригодны в работе
Use case – описание, как пользователь будет
применять систему для решения своих задач
User story – фиксируем, зачем пользователь
решает задачи, применяя систему
Выйти за границу – представить
себя на месте пользователя
В процессе разработки принимается много решений,
требующих представить себя на месте пользователя
Функции
Сценарии
Цели
14/35
16. Каждая система имеет деление
На компоненты – по внешним функциям
На модули – по ячейкам внутренней конструкции
В общем случае они связаны произвольно
Развитие системы дискретно
Инкременты поставок очередных версий
Инкременты разработки, передаваемой в тестирование
Если деление мелкое, надо удерживать
целостность системы
Компоненты, модули и их приращения
Из курса
Левенчука,
он ссылается
на ISO 81346
Существует много вариантов организации системы
из составных частей. Метод работы с требованиями должен
соответствовать способу декомпозиции
16/35
17. Инкрементальная поставка требует создания
бизнес-ценного функционала
Формат User story формулирует малый
функционал, ценный пользователю
Use case больше, и его сценарии имеют
разную ценность – делим case на slice
Можно описывать приращения в терминах
доработки конструктивных элементов системы,
ее фич, функций или сервисов
Инкрементальная поставка
Ивар
Якобсон
Use Case 2.0
17/35
18. Детализация до мелких фрагментов выполняется
не сразу – каковы крупные фрагменты?
Соответствуют ли крупные фрагменты наборам
поставляемого функционала или поставки
формируются отдельно?
На каких уровнях детализации и как оцениваем?
Как организуем пакеты поставки из набора
функционала?
Как выделяем MVP?
Как используем приоритеты?
Как удовлетворяем интересы групп пользователей?
Инкрементальная детализация
Вариант – практика
Story Mapping
18/35
19. Что является поставляемым приложением?
Монолит, прирастающий по объему
Крупные модули
Мелкие сервисы или модули
Что является ячейками приложения?
Процедуры, таблицы и формы UI
Объекты (данные плюс методы в одном флаконе)
Модули с собственной моделью декомпозиции и др.
Применяется ли слоевое деление и какое?
Как интегрируются модули и мелкие ячейки?
Какова структура приложения?
Модуль – развиваем,
а сервис – заменяем новым
19/35
22. Концепция системы – цели создания
и верхнеуровневые полагания
Метафора системы – эффективная
практика XP, если ее получается придумать
Я говорил о метафоре в докладе «Модель системы – архитектура
для Agile-разработки» на AgileDays – 2011
Архитектура системы – основа конструкции
Модель системы – постепенно создаваемая
и принципиальная конструкция системы
Подход Domain Driven Design (DDD) адаптировал использование
модели для инкрементальной поставки (мои доклады по DDD)
Удержание целостности системы UI
DB
БЛ ??
22/35
24. Инкремент поставки развивает функции, изменяя
для этого ячейки конструкции
Чтобы влияние изменений было локальным, ячейки
должны быть изолированными
ООП, микросервисы и многое другое придумывали
для этого, но гарантий независимости нет
В ООП ее нарушают обращение по цепочкам ссылок, есть хороший
доклад Андрея Бибичева на AgileDays – 2011 «Архитектура в Agile –
переосмысляя идею модульности и компонентности»
Независимость микросервисов нарушает синхронное взаимодействие
Какие практики будете использовать вы?
Ограниченность изменений
24/35
26. Уровень тест-кейсов не может быть выше
уровня требований – нет смысла делать
BDD, если нужды пользователей неясны
Уровень формальности требований
должен соответствовать формальности
тестов: автотесты требуют строгости
Надо контролировать стоимость ведения
и проверки тест-кейсов
Ведение требований должно
соответствовать подходу к тестированию
26/35
28. Используем средство моделирования
(EA и другие) или диаграммы
«в вольном стиле»?
Какие wiki-системы и другие
средства коллективной работы используем?
Как структурируем артефакты?
Через какие viewpoint представляем систему?
Какой набор диаграмм используем?
Артефакты и диаграммы
MS Word не является
эффективным средством
коллективной работы
На SECR – 2016 был рассказ Павла Музыки об опыте CUSTIS «Собираем кубик
Рубика: восстановление архитектурного описания корпоративной
распределенной системы»
28/35
29. Артефакт – средство коммуникации
С заказчиком и разработчиками в ходе проекта
С будущими пользователями системы
С теми, кто будет развивать и эксплуатировать –
даже если это ты сам, но через полгода
Артефакт должен быть понятен всем
сторонам коммуникации
Это ограничивает сложность нотаций
Упрощенные схемы должны сохранять
ключевые моменты
Принципы работы с артефактами
29/35
30. Эксплуатация добавляет фокусы
Стоимости функционирования бизнес-процессов и поддержки
Быстрой и эффективной обработки инцидентов
Сохраняется фокус развития системы
Автоматизация вспомогательных и побочных процессов
Реализация специальных процессов для конкретных целевых
групп пользователей
Крупные доработки основного процесса
Все это требует изменений в практиках
и артефактах ведения требований
От внедрения к эксплуатации
Их надо спроектировать и реализовать, тем более
что на внедрении артефакты обычно отстают от системы
30/35
31. OMG Essence –
способ описать метод
Потому что процессное описание в IT
не работает – помни историю RUP
Источники: Спецификация на сайте OMG и библиотека практик
на сайте Ивара Якобсона (требуется регистрация)
31/35
32. Требования и возможности в Essence
Req
Conceived
Bounded
Coherent
Acceptable
Addressed
Fulfilled
Opportunity
Identified
Solution
Needed
Value
Established
Viable
Addressed
Benefit
Accrued
Обнаружены
коммерческие
или социальные
возможности
Необходимо
IT-решение
Согласована
потребность
в IT-решении
Определена
ценность решения
Ясно назначение
и область системы
Описаны основные
характеристики
Описание принято
стейкхолдерами
Вольный
перевод!
Сроки и стоимость
решения приемлемы
Значительная
часть требований
удовлетворена
Демонстрируется,
что решение
доставляет ценность
Требования
удовлетвореныОжидаемый эффект
достигается
32/35
34. User story и Use case
Req Item
Identified
Described
Implemented
Verified
User story
Described
Understood
Implemented
Fulfilled
Use case
Goal Established
Story Structure
Understood
Simplest Story
Fulfilled
Sufficient Stories
Fulfilled
All Stories
Fulfilled
Use case
slice
Implemented
Verified
Analyzed
Prepared
Scored
Req
34/35
35. Каждая ИТ-разработка идет в своих условиях
Требования определяют внешние границы проекта
и создаваемую конструкцию
Способ работы с требованиями в проекте сам
по себе – объект конструирования и воплощения
Подводя итоги
Вакансии аналитиков
Пишите на hr@custis.ru, подходите с вопросами
Максим Цепков
mtsepkov.org