2. ИсточникиMSF Группы разработки Microsoft Microsoft Services Подтверждение практикой Microsoft Operations & TechnologyGroup Microsoft Certified Partners Проанализированы результаты проектных команд и групп разработки Результаты анализа контрастируют с индустриальной практикой и методами Комбинированные результаты организованы и собраны в руководство «люди и процесс» C 1994 года
3. Группы представителей в MSF v4Модель команды Управлениепрограммой Архитектура Управлениепродуктом Разработка Удовлетворениепользователя Тестирование Выпуск /эксплуатация Поставка решения Дизайн решения Определение решения Разработка решения Представители Качество решения Юзабилити решения Развертывание решения
4. Группы представителей MSF v4 Р Р В В Н Р Р В Н Н Р Р Р Р Р Р В В Н В Р В Н Н В Р В В Н Н Роли могут комбинироваться, но некоторые сочетания несут в себе риск Управление продуктом Управление программой Удовлетворение пользователя Управление выпуском Разработка Тестирование Управление продуктом Управление программой Разработка Тестирование Удовлетворение пользователя Управление выпуском ВВозможно ННежелательно РРискованно
6. Управление продуктом Управление продуктом Архитектура Управление программой Выпуск / Эксплуатация Выпуск / Эксплуатация Выпуск / Эксплуатация Управление продуктом Разработка Удовлетворение пользователя Тестирование Управление программой Управление программой Управление программой Разработка Разработка Разработка Тестирование Тестирование Тестирование Архитектура Архитектура Отношение подкоманд в MSF с лидирующей командой Многопрофильные подкоманды организуются вокруг функциональных возможностей продукта или создаются для работы над специфическими возможностями Функциональная команда Ролевой лидер Удовлетворение пользователя Выпуск/ Эксплуатация Передача сообщений Клиентскоеприложение Файловые операции и печать Подкоманды разработки
7. MSF дляAgile Software Development Представляет версию MSF которая Уделяет меньше внимания формальным проектным решениям Концентрируется на гибких методах разработки в небольших сотрудничающих командах Итеративный, движимый сценариями, контекстно-зависимый процесс разработки Завершается с Документированным процессов Руководства и шаблоны Инструменты с возможностями расширения
8. MSF дляCMMI Process Improvement Помогает организациям работать на Capability Maturity Model® Integration (CMMI®) уровня3, стандарта определенного институтом Карнеги Меллона (Carnegie Mellon Software Engineering Institute – SEI) Не заменяет инфраструктуру улучшения процессов Гибкий подход к CMMI Представляет дополнительную формальность, обзоры, верификацию и аудит Сравните с MSF4ASD Основано на той же мета-модели MSF Тот же набор принципов Тот же образ мышления MSFCMMI MSFAgile ОсновыMSF
9. Что выбирать? MSF для ASD: Для проектов с командами ориентированными на результат, которые могут работать без большого количества промежуточной документации. “Дотянуться” вместо “уместиться” Минималистический подход Гибкие методологии пропагандируют адаптацию MSF для CMMI: Для проектов с длительным временем жизни, требующими истории принятых решений. Также, если организация работает над широкомасштабной инициативой улучшения качества и процессовили если команде требуется набор точных рекомендацийвместо опыта.
10. Цикл Основа для ежедневной координированной работы команды Треки перекрываются с каждым и проверяются по контрольным точкам Видение Планирование Разработка Стабилизация Развертывание Непрерывный Итерация Проект Ежедневная сборка Возврат кода Принятая сборка
11. Версия3 Версия2 Версия1 Развертывание Развертывание Развертывание Стабилизация Стабилизация Стабилизация Разработка Разработка Разработка Планирование Планирование Планирование Видение Видение Видение Итеративный подходЦикл Минимизация рисков посредством разделения больших проектов на версии Время
12. Что такое видение?Определение видения проекта Короткий, согласованный тест лаконично описывающий цель создания новой или улучшенной системы Предоставляет команде обоснование создания системы В идеальном случае содержит не больше 25 слов Любой член команды может его запомнить и соотнести со своей ежедневной работой
13. ПерсоныОпределение персон Описание группы типичных пользователей Персона описывает типичные умения, возможности, потребности, желания, привычки, задачи и прочую информацию для специфической группы пользователей. Персона – это вымышленная личность, собирающая в себе реальные данные и описывающие важные характеристики группы пользователей.
14. Создание сценариев Написание сценария: Сценарий – это единичный способ взаимодействия пользователя с системой. По мере того, как пользователь пытается достичь реального результата, сценарий описывает конкретные шаги, которые производит пользователь. Общее количество возможных сценариев практически бесконечно, поэтому важно выбрать важные. Могут описывать успешный путь или неуспешный. Расстановка приоритетов: Определите важность сценария Организуйте сценарии по приоритетам Используйте модель Кано!
28. Истории для сценариевСоздание сценариев Опишите экраны, которые будут показаны персоне. Создайте наброски пользовательского интерфейса в данном сценарии. Обсудите с другими членами команды, чтобы убедится, что предлагаемый интерфейс не выбивается из общего видения. Хорошо зарекомендовавшие себя инструменты: Microsoft Visio иMicrosoft PowerPoint.
29. Обсудите критерии качестваКритерии качества “Не функциональные” требования Ограничивают функциональность Верхние5 Производительность Безопасность Взаимодействие с пользователем Платформа Нагрузка Будьте конкретны: «Время ответа системы не более 3 секунд в 95% случаев при 10 тыс. пользователей»
30. Определение подхода к тестированиюТестирование сценариев Определение порога тестирования Объективное определение момента, когда качество продукта достаточно для выпуска Контекстно-зависимое Тестирование приемлемое для одного из проектов может быть совершенно неприемлемым для другого
31. ПланированиеПланирование итерации Длительность итерации? Сценарий1 Сценарий 2 Сценарий 3 Сценарий 4 Итерация1 Список сценариев Сценарий 1 Сценарий 2 Сценарий 3 Размер сценариев? План итерации Сколько сценариев можно реализовать за итерацию?
32. Длительность итерации?Планирование итерации Ограничение по времени От 2 до6 недель 4 недели –разумное умолчание Планирование пересечения с разработкой и тестированием (Самоорганизация) Разбиение Сценария/Критерия качествана задания
33. Оценка задания разработкиЗадание разработки В начале каждой итерации Разработчики оценивают задачи в часах Проверьте, что сумма задач+ накладные расходы> длины итерации Разбейте или сбалансируйте задания если нужно Обновите реальные часы Используйте скорость для оценки Используйте реальные часы для мониторинга Разница в накладных расходах: Встречи, обзоры кода, почта и т.п.
34. Роль архитектораАрхитектура проекта Скоординируйте с разработкой и эксплуатацией Неразработчик Неотвечает за дизайн классов Практик Ограниченная документация (только архитектурные решения) Структура решения Отвечает за требования к критериям качества Архитектурный (эволюционирующий) прототип Модель опасностей Производительность
35. Модель опасностейАрхитектура проекта Обсудите список опасностей Расставьте опасности по уровню риска Насколько серьезны последствия? Насколько проста атака? Найдите способы ослабить опасности Решите от каких опасностей нужно защищаться и действуйте соответственно STRIDE + DREAD Microsoft Threat Modeling Tool
36. КодированиеЗадание разработки Модульное тестирование (Unit Testing) Без вариантов! Простое правило: 70% покрытия кода Политика возврата кода (Check-in Policy) Возврат как можно раньше Предотвращайте поломку сборки Модульное тестирование завершено без ошибок Автоматический анализ кода Обзор кода Рефакторинг – это нормально Требования меняются Видение меняется
37. Создание или обновлениемодульных тестов Написание кода длязадания разработки Выполнениемодульных тестов Возврат кода с учетомрекомендаций Начинать с теста или с кода?Задание разработки Неважно, главное делать это!
38. КодированиеИсправление ошибки Классификация ошибок Рекомендации процесса MSF 4 1 = В этой интеграции 2 = В этой версии 3 = Возможно, или, возможно, НЕ будет исправлено Практика Microsoft: рассказывайте и спрашивайте Честность приносит плоды Модульное тестирование Помогает убедиться в работе исправления Может быть использовано для воспроизведения ошибки
39. Ежедневная сборкаСборка продукта Ежедневная сборка жизненно важна Это пульс проекта! Поддерживайте качество около 100% Используйтетесты проверки сборок(Build Verification Tests – BVT) Основаны на сценариях Ежедневная интеграция Нет сюрпризов в конце Экономит время
40. Тестовое заданиеТестирование сценария Включайте тестовую группу в проект Не в конце Автоматизируйте тесты Везде, где возможно Закрытие ошибки Тестовая группа решает, НЕразработчики
41. Тестовое заданиеТестирование качества Тестирование производительности Глобальная производительность, производительность сценария Нагрузочное тестирование (пользователи) Стресс-тестирование (ресурсы) Тестирование безопасности Разнообразие ролей, сред Исследовательское тестирование Творческая работа Действуйте как персона
42. РискУправление проектом Характеристики Присуще каждому проекту Ни плохо, ни хорошо Не пугаться, а управлять Упрощенная среда управления рисками Риск это просто еще одна задача
43. Мониторинг проектаУправление проектом Оставшаяся работа Сколько работы осталось и когда она будет закончена? Индикатор качества Какое качество у проекта? Скорость Как быстро команда завершает задачи? Незапланированная работа Насколько много незапланированной работы? Реальная и запланированная работа Сколько сценариев может быть завершено прежде чем качество станет неприемлемым? Количество ошибок Количество повторных ошибок
44. Стабилизация Сфокусируйтесь на выпуске продукта Функционально законченная версия Новый функционал НЕ добавляется Исправленные ошибки должны превысить найденные Балансирует стабильность против потребностей клиента Может вылиться в потерю какой-либо функциональности ради стабильности
46. Развертывание Цель: Запуск или приемка Фокус команды Стимулировать беспроблемную передачу решения от проектной команды к эксплуатационной Получить приемку решения заказчиком, подтвердить, что проект закончен Артефакты Хранилище всех версий документов, наборов загрузки, конфигураций, скриптов и кода Комментарии к релизу
47. Практика развертывания Тестировать развертывание как можно раньше в среде близкой к «боевой» Развертывать множество раз в течение разработки для улучшения процесса развертывания Автоматизировать как можно больше Писать полезные и свежие комментарии к релизу Тесно работать с эксплуатационной командой
51. Принципы MSF v4 Открытость коммуникаций Общее видение Полномочия членов команды Ответственность и общие обязательства Фокус на бизнес-ценностях Гибкость, ожидайте изменений Инвестиции в качество Обучение на основе опыта Сотрудничество с клиентами На выходе всегда готовые решения
52. Образ мышления MSF v4 Команда равных Фокус на клиентах Решение Доверие Качество Желание учиться
53. Фокус представителей в MSF v4 Управлениепродуктом Удовлетворение пользователя Разработка Бизнес Пользователи Клиент ЭксплуатацияПоддержка Тестирование Проектная команда Спонсор проекта Управление программой Архитекторы решения Выпуск/ Эксплуатация Эксплуатация Архитектура Технологические архитекторы Технологии
57. Microsoft Solution FrameworkРесурсы Основы Microsoft Solution Framework, Майкл С.В. Тернерhttp://www.rusedit.com/book.aspx?BookID=1280 Руководство по применению MSF
