Design & Process Models
2 likes6,596 views
Документ представляет собой материалы 4-й конференции .NET разработчиков, проведенной 28 апреля 2012 года, с акцентом на модели дизайна и процессы разработки. Обсуждаются ключевые аспекты, такие как компромисс решений, типовые процессы и борьба с неопределенностью в разработке, а также важность метамоделирования. Участникам предложены практические рекомендации для оптимизации процессов и повышения качества проектов.
Design & Process Models
- 1. 4-‐я конференция .NET разработчиков 28 апреля 2012 Design&Process Models: Как нужно уметь думать прагматичным разработчикам Кривошеев Евгений ScrumTrek/SkillTrek h9p://ekrivosheev.moikrug.ru ekrivosheyev@scrumtrek.ru
- 3. Agenda 3
- 4. Target audience 4
- 5. Objectives 5
- 6. Value 6
- 7. Disclaimer 7
- 8. Agenda { 8
- 9. Понятие модели 9
- 10. Свойства моделей 10
- 11. Ключевые модели 11
- 12. Ключевые модели Таксономия требований/ожиданий: - Функциональные (сценарии) - Нефункциональные (QA) Другая таксономия: - Внешние требования - Внутренние требования Частый способ верификации/валидации: - DoD 12
- 13. Agenda { 13
- 14. Решение как компромисс 14
- 15. Конфликты ожиданий 15
- 16. Конфликты ожиданий интеллект специальные готовка навыки Ирка Петрова Саша Грей TCO уборка 16
- 17. Решение как компромисс 17
- 18. Обоснование решений 18
- 19. Обоснование решений «Дизайн – это компромисс. Любое решение – компромисс. За все приходится платить.» 19
- 20. Обоснование решений Фабрика design pattern Что получаем Чем платим 20
- 21. Обоснование решений Кеш design pattern Что получаем Чем платим 21
- 22. Обоснование решений «Проектирование в общем смысле, как выработка решений – задача многокритериальной оптимизации. Попытка найти глобальный оптимум целевой функции, зачастую в ущерб локальным оптимумам.» 22
- 23. Agenda { 23
- 24. Роль неопределенности Корень всех зол. Все практики разработки ПО – это групповые способы борьбы с неопределенностью. Про виды неопределенности поговорим ниже. 24
- 25. Agenda { 25
- 26. Метамоделирование «Мы не можем решить проблему на том же уровне абстракции, на котором она возникла» 26
- 27. Метамоделирование 27
- 28. Метамоделирование 28
- 29. Метамоделирование 29
- 30. Pull vs Push Динамика получения ценности «Вытягиваем новую ценность, исходя из имеющегося решения» { { { { «Проталкиваем решение, исходя из нашего плана» 30
- 31. Pull vs Push Динамика получения ценности «Вытягиваем новую ценность, исходя из Интерпретатор имеющегося решения» «Проталкиваем решение, Компилятор исходя из нашего плана» 31
- 32. Agenda { 32
- 33. Паттерны «Паттерн – типовое решение» «Паттерн – уже принятое решение в осях ожиданий метамодели» 33
- 34. Паттерны 34
- 35. Паттерны 35
- 36. Паттерны 36
- 37. Типовые бизнес-модели 37
- 38. Типовые процессы 38
- 39. Типовые процессы Характер неопределенности высокая Решения команды и их реализация, внутренние риски высокая Внутренняя низкая Внешняя Изменчивость требований и внешней среды, внешние риски низкая 39
- 40. Типовые процессы Борьба с неопределенностью высокая Итеративные процессы с быстрой обратной связью Итеративность и малым охватом задач на вход Последовательные процессы с большим охватом задач на вход медленной обратной связью и низкая 40
- 41. Типовые процессы Борьба с неопределенностью низкая Самоорганизация высокая Управление по: Процессам Задачам Проблемам, Ценностям целям Принимают решения Принимают решения PM/PA. исполнители. Исполнители – сервис. Scrum Master – сервис. 41
- 42. Типовые процессы Методологии DoD Watefall RUP Scrum Kanban Итеративность Формальные процессы Самоорганизация Последовательность 42
- 43. Типовые процессы «Нет хороших или плохих процессов. Есть лишь вопрос соответствия задачам. За все нужно платить.» 43
- 44. Целостность между моделями Любое решение должно быть обосновано в системе критериев, заданных метамоделью 44
- 45. Целостность между моделями Возможное трение 45
- 46. Целостность между моделями Любое решение должно быть обосновано в системе критериев, заданных метамоделью Наличие java i nterface в к в итоге обосно оде вывается бизнес-модель ю компании 46
- 47. Целостность между моделями Любое решение должно быть обосновано в системе критериев, заданных метамоделью Обоснование и описание реше ний следует начин в терминах ме ать тамодели 47
- 48. Целостность между моделями Lean startup Пример Scrum целостных User Stories моделей без Agile Modeling трения Simple Design TDD 48
- 49. Agenda 49
- 50. Отлить в граните 1. Решение – это компромисс, задача многокритериальной оптимизации 2. Система ожиданий задается метамоделью 3. Мы часто не можем решить проблему на том же уровне абстракции, на котором она возникла 4. Необходимо полнота и непротиворечивость метамодели 5. Динамика получения ценности определяется выбором между pull- и push-подходами 6. Любое решение должно быть обосновано в системе критериев, заданных метамоделью 7. Паттерн – уже принятое решение, готовое к переиспользованию 8. Современная разработка ПО – групповая борьба с неопределенностью (внешней и внутренней) 9. Типовые процессы определяют степени итеративности и самоуправления 50
- 51. Контакты Евгений Кривошеев, ekrivosheyev@scrumtrek.ru Никита Филиппов, nfilippov@scrumtrek.ru Асхат Уразбаев, askhat@scrumtrek.ru «Тяжело в учении – легко в бою» SkillTrek – это дистанционный центр компетенций, где специалисты получают востребованные на рынке знания и навыки в условиях реальных проектов с выбором удобной им загрузки 51