Msf Dz

906 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
906
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Msf Dz

  1. 1. Опыт управления проектами<br />Евгений Кривошеев<br />Program Manager<br />evgenykr@microsoft.com<br />
  2. 2. ИсточникиMSF<br />Группы разработки Microsoft<br />Microsoft<br />Services<br />Подтверждение практикой<br />Microsoft<br />Operations & <br />TechnologyGroup<br />Microsoft Certified Partners<br />Проанализированы результаты проектных команд и групп разработки<br />Результаты анализа контрастируют с индустриальной практикой и методами<br />Комбинированные результаты организованы и собраны в руководство «люди и процесс»<br />C 1994 года<br />
  3. 3. Группы представителей в MSF v4Модель команды<br />Управлениепрограммой<br />Архитектура<br />Управлениепродуктом<br />Разработка<br />Удовлетворениепользователя<br />Тестирование<br />Выпуск /эксплуатация<br />Поставка решения<br />Дизайн решения<br />Определение решения<br />Разработка решения<br />Представители<br />Качество решения<br />Юзабилити решения<br />Развертывание решения<br />
  4. 4. Группы представителей MSF v4<br />Р<br />Р<br />В<br />В<br />Н<br />Р<br />Р<br />В<br />Н<br />Н<br />Р<br />Р<br />Р<br />Р<br />Р <br />Р<br />В<br />В<br />Н<br />В<br />Р<br />В<br />Н<br />Н<br />В<br />Р<br />В<br />В<br />Н<br />Н<br />Роли могут комбинироваться, но некоторые сочетания несут в себе риск<br />Управление продуктом<br />Управление программой<br />Удовлетворение пользователя<br />Управление выпуском<br />Разработка<br />Тестирование<br />Управление продуктом<br />Управление программой<br />Разработка<br />Тестирование<br />Удовлетворение пользователя<br />Управление выпуском<br />ВВозможно<br />ННежелательно<br />РРискованно<br />
  5. 5. Управлениепрограммой<br />Удовлетворениепользователя<br />Разработка<br />Управлениепродуктом<br />Тестирование<br />Группы представителей MSF v4Небольшая команда<br />Небольшая команда, совмещенные роли<br />Управлениевыпуском<br />
  6. 6. Управление продуктом<br />Управление продуктом<br />Архитектура<br />Управление программой<br />Выпуск / Эксплуатация<br />Выпуск / Эксплуатация<br />Выпуск / Эксплуатация<br />Управление продуктом<br />Разработка<br />Удовлетворение пользователя<br />Тестирование<br />Управление программой<br />Управление программой<br />Управление программой<br />Разработка<br />Разработка<br />Разработка<br />Тестирование<br />Тестирование<br />Тестирование<br />Архитектура<br />Архитектура<br />Отношение подкоманд в MSF с лидирующей командой<br />Многопрофильные подкоманды организуются вокруг функциональных возможностей продукта или создаются для работы над специфическими возможностями<br />Функциональная команда<br />Ролевой лидер<br />Удовлетворение пользователя<br />Выпуск/ Эксплуатация<br />Передача сообщений<br />Клиентскоеприложение<br />Файловые операции и печать<br />Подкоманды разработки<br />
  7. 7. MSF дляAgile Software Development<br />Представляет версию MSF которая<br />Уделяет меньше внимания формальным проектным решениям<br />Концентрируется на гибких методах разработки в небольших сотрудничающих командах<br />Итеративный, движимый сценариями, контекстно-зависимый процесс разработки<br />Завершается с<br />Документированным процессов<br />Руководства и шаблоны<br />Инструменты с возможностями расширения<br />
  8. 8. MSF дляCMMI Process Improvement<br />Помогает организациям работать на Capability Maturity Model® Integration (CMMI®) уровня3, стандарта определенного институтом Карнеги Меллона (Carnegie Mellon Software Engineering Institute – SEI) <br />Не заменяет инфраструктуру улучшения процессов<br />Гибкий подход к CMMI<br />Представляет дополнительную формальность, обзоры, верификацию и аудит<br />Сравните с MSF4ASD<br />Основано на той же мета-модели MSF<br />Тот же набор принципов<br />Тот же образ мышления<br />MSFCMMI<br />MSFAgile<br />ОсновыMSF<br />
  9. 9. Что выбирать?<br />MSF для ASD:<br />Для проектов с командами ориентированными на результат, которые могут работать без большого количества промежуточной документации.<br />“Дотянуться” вместо “уместиться”<br />Минималистический подход<br />Гибкие методологии пропагандируют адаптацию<br />MSF для CMMI:<br />Для проектов с длительным временем жизни, требующими истории принятых решений. Также, если организация работает над широкомасштабной инициативой улучшения качества и процессовили если команде требуется набор точных рекомендацийвместо опыта.<br />
  10. 10. Цикл<br />Основа для ежедневной координированной работы команды<br />Треки перекрываются с каждым и проверяются по контрольным точкам<br />Видение<br />Планирование<br />Разработка<br />Стабилизация<br />Развертывание<br />Непрерывный<br />Итерация<br />Проект<br />Ежедневная сборка<br />Возврат кода<br />Принятая сборка<br />
  11. 11. Версия3<br />Версия2<br />Версия1<br />Развертывание<br />Развертывание<br />Развертывание<br />Стабилизация<br />Стабилизация<br />Стабилизация<br />Разработка<br />Разработка<br />Разработка<br />Планирование<br />Планирование<br />Планирование<br />Видение<br />Видение<br />Видение<br />Итеративный подходЦикл<br />Минимизация рисков посредством разделения больших проектов на версии<br />Время<br />
  12. 12. Что такое видение?Определение видения проекта<br />Короткий, согласованный тест лаконично описывающий цель создания новой или улучшенной системы<br />Предоставляет команде обоснование создания системы<br />В идеальном случае содержит не больше 25 слов<br />Любой член команды может его запомнить и соотнести со своей ежедневной работой<br />
  13. 13. ПерсоныОпределение персон<br />Описание группы типичных пользователей<br />Персона описывает типичные умения, возможности, потребности, желания, привычки, задачи и прочую информацию для специфической группы пользователей.<br />Персона – это вымышленная личность, собирающая в себе реальные данные и описывающие важные характеристики группы пользователей.<br />
  14. 14. Создание сценариев<br />Написание сценария:<br />Сценарий – это единичный способ взаимодействия пользователя с системой. По мере того, как пользователь пытается достичь реального результата, сценарий описывает конкретные шаги, которые производит пользователь.<br />Общее количество возможных сценариев практически бесконечно, поэтому важно выбрать важные.<br />Могут описывать успешный путь или неуспешный.<br />Расстановка приоритетов:<br />Определите важность сценария<br />Организуйте сценарии по приоритетам<br />Используйте модель Кано!<br />
  15. 15. Удовлетворенный пользователь<br />Линейные потребности<br />Привлекательные потребности<br />Необходимые потребности<br />“Это клево”<br /><ul><li>Редактирование страницы из панели инструментов IE
  16. 16. Бесплатный интернет в Starbucks
  17. 17. Убирающиеся фары
  18. 18. Отправка фотографий с мобильного телефона</li></ul>“Больше – лучше”<br /><ul><li>Скорость соединения
  19. 19. Вкус кофе
  20. 20. Экономия топлива
  21. 21. Время жизни батареи</li></ul>Неважное<br />Бедный функционал<br />Богатый функционал<br />“Мне все равно”<br /><ul><li>Поддержка MapPoint
  22. 22. Цвет чашки
  23. 23. Размер колес
  24. 24. Напряжение батареи</li></ul>“Без этого мне продукт не нужен”<br /><ul><li>Возможность печати
  25. 25. Горячий кофе
  26. 26. Тормоза в машине
  27. 27. Возможность переноса фотографий на компьютер</li></ul>Неудовлетворённый пользователь<br />
  28. 28. Истории для сценариевСоздание сценариев<br />Опишите экраны, которые будут показаны персоне. Создайте наброски пользовательского интерфейса в данном сценарии. Обсудите с другими членами команды, чтобы убедится, что предлагаемый интерфейс не выбивается из общего видения.<br />Хорошо зарекомендовавшие себя инструменты: Microsoft Visio иMicrosoft PowerPoint.<br />
  29. 29. Обсудите критерии качестваКритерии качества<br />“Не функциональные” требования<br />Ограничивают функциональность<br />Верхние5<br />Производительность<br />Безопасность<br />Взаимодействие с пользователем<br />Платформа<br />Нагрузка<br />Будьте конкретны: «Время ответа системы не более 3 секунд в 95% случаев при 10 тыс. пользователей»<br />
  30. 30. Определение подхода к тестированиюТестирование сценариев<br />Определение порога тестирования<br />Объективное определение момента, когда качество продукта достаточно для выпуска<br />Контекстно-зависимое<br />Тестирование приемлемое для одного из проектов может быть совершенно неприемлемым для другого<br />
  31. 31. ПланированиеПланирование итерации<br />Длительность итерации?<br />Сценарий1<br />Сценарий 2<br />Сценарий 3<br />Сценарий 4<br />Итерация1<br />Список сценариев<br />Сценарий 1<br />Сценарий 2<br />Сценарий 3<br />Размер сценариев?<br />План итерации<br />Сколько сценариев можно реализовать за итерацию?<br />
  32. 32. Длительность итерации?Планирование итерации<br />Ограничение по времени<br />От 2 до6 недель<br />4 недели –разумное умолчание<br />Планирование пересечения с разработкой и тестированием<br />(Самоорганизация)<br />Разбиение Сценария/Критерия качествана задания<br />
  33. 33. Оценка задания разработкиЗадание разработки<br />В начале каждой итерации<br />Разработчики оценивают задачи в часах<br />Проверьте, что сумма задач+ накладные расходы> длины итерации<br />Разбейте или сбалансируйте задания если нужно<br />Обновите реальные часы<br />Используйте скорость для оценки<br />Используйте реальные часы для мониторинга<br />Разница в накладных расходах:<br />Встречи, обзоры кода, почта и т.п.<br />
  34. 34. Роль архитектораАрхитектура проекта<br />Скоординируйте с разработкой и эксплуатацией<br />Неразработчик<br />Неотвечает за дизайн классов<br />Практик<br />Ограниченная документация (только архитектурные решения)<br />Структура решения<br />Отвечает за требования к критериям качества<br />Архитектурный (эволюционирующий) прототип<br />Модель опасностей<br />Производительность<br />
  35. 35. Модель опасностейАрхитектура проекта<br />Обсудите список опасностей<br />Расставьте опасности по уровню риска<br />Насколько серьезны последствия?<br />Насколько проста атака?<br />Найдите способы ослабить опасности<br />Решите от каких опасностей нужно защищаться и действуйте соответственно<br />STRIDE + DREAD<br />Microsoft Threat Modeling Tool<br />
  36. 36. КодированиеЗадание разработки<br />Модульное тестирование (Unit Testing)<br />Без вариантов!<br />Простое правило: 70% покрытия кода<br />Политика возврата кода (Check-in Policy)<br />Возврат как можно раньше<br />Предотвращайте поломку сборки<br />Модульное тестирование завершено без ошибок<br />Автоматический анализ кода<br />Обзор кода<br />Рефакторинг – это нормально<br />Требования меняются<br />Видение меняется<br />
  37. 37. Создание или обновлениемодульных тестов<br />Написание кода длязадания разработки<br />Выполнениемодульных тестов<br />Возврат кода с учетомрекомендаций<br />Начинать с теста или с кода?Задание разработки<br />Неважно, главное делать это!<br />
  38. 38. КодированиеИсправление ошибки<br />Классификация ошибок<br />Рекомендации процесса MSF 4<br />1 = В этой интеграции<br />2 = В этой версии<br />3 = Возможно, или, возможно, НЕ будет исправлено<br />Практика Microsoft: рассказывайте и спрашивайте<br />Честность приносит плоды<br />Модульное тестирование<br />Помогает убедиться в работе исправления<br />Может быть использовано для воспроизведения ошибки<br />
  39. 39. Ежедневная сборкаСборка продукта<br />Ежедневная сборка жизненно важна<br />Это пульс проекта!<br />Поддерживайте качество около 100%<br />Используйтетесты проверки сборок(Build Verification Tests – BVT)<br />Основаны на сценариях<br />Ежедневная интеграция<br />Нет сюрпризов в конце<br />Экономит время<br />
  40. 40. Тестовое заданиеТестирование сценария<br />Включайте тестовую группу в проект<br />Не в конце<br />Автоматизируйте тесты<br />Везде, где возможно<br />Закрытие ошибки<br />Тестовая группа решает, НЕразработчики<br />
  41. 41. Тестовое заданиеТестирование качества<br />Тестирование производительности<br />Глобальная производительность, производительность сценария<br />Нагрузочное тестирование (пользователи)<br />Стресс-тестирование (ресурсы)<br />Тестирование безопасности<br />Разнообразие ролей, сред<br />Исследовательское тестирование<br />Творческая работа<br />Действуйте как персона<br />
  42. 42. РискУправление проектом<br />Характеристики<br />Присуще каждому проекту<br />Ни плохо, ни хорошо<br />Не пугаться, а управлять<br />Упрощенная среда управления рисками<br />Риск это просто еще одна задача<br />
  43. 43. Мониторинг проектаУправление проектом<br />Оставшаяся работа<br />Сколько работы осталось и когда она будет закончена?<br />Индикатор качества<br />Какое качество у проекта?<br />Скорость<br />Как быстро команда завершает задачи?<br />Незапланированная работа<br />Насколько много незапланированной работы?<br />Реальная и запланированная работа<br />Сколько сценариев может быть завершено прежде чем качество станет неприемлемым?<br />Количество ошибок<br />Количество повторных ошибок<br />
  44. 44. Стабилизация<br />Сфокусируйтесь на выпуске продукта<br />Функционально законченная версия<br />Новый функционал НЕ добавляется<br />Исправленные ошибки должны превысить найденные<br />Балансирует стабильность против потребностей клиента<br />Может вылиться в потерю какой-либо функциональности ради стабильности<br />
  45. 45. Развертывание<br />Microsoft Solutions Framework<br />Планирование<br />Эксплуатация<br />Разработка<br />Развертывание<br />Microsoft Operations Framework<br />
  46. 46. Развертывание<br />Цель: Запуск или приемка<br />Фокус команды<br />Стимулировать беспроблемную передачу решения от проектной команды к эксплуатационной<br />Получить приемку решения заказчиком, подтвердить, что проект закончен<br />Артефакты<br />Хранилище всех версий документов, наборов загрузки, конфигураций, скриптов и кода<br />Комментарии к релизу<br />
  47. 47. Практика развертывания<br />Тестировать развертывание как можно раньше в среде близкой к «боевой»<br />Развертывать множество раз в течение разработки для улучшения процесса развертывания<br />Автоматизировать как можно больше<br />Писать полезные и свежие комментарии к релизу<br />Тесно работать с эксплуатационной командой<br />
  48. 48. Вопросы?<br />
  49. 49. © 2005-2010 Microsoft Corporation. All rights reserved.<br />This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.<br />
  50. 50. Приложения<br />
  51. 51. Принципы MSF v4<br />Открытость коммуникаций<br />Общее видение<br />Полномочия членов команды<br />Ответственность и общие обязательства<br />Фокус на бизнес-ценностях<br />Гибкость, ожидайте изменений<br />Инвестиции в качество<br />Обучение на основе опыта<br />Сотрудничество с клиентами<br />На выходе всегда готовые решения<br />
  52. 52. Образ мышления MSF v4<br />Команда равных<br />Фокус на клиентах<br />Решение<br />Доверие<br />Качество<br />Желание учиться<br />
  53. 53. Фокус представителей в MSF v4<br />Управлениепродуктом<br />Удовлетворение пользователя<br />Разработка<br />Бизнес<br />Пользователи<br />Клиент<br />ЭксплуатацияПоддержка<br />Тестирование<br />Проектная команда<br />Спонсор проекта<br />Управление программой<br />Архитекторы решения<br />Выпуск/ Эксплуатация<br />Эксплуатация<br />Архитектура<br />Технологические архитекторы<br />Технологии<br />
  54. 54. STRIDE– Категоризация опасностейАрхитектура решения<br />
  55. 55. DREAD– Ранжирование опасностейАрхитектура решения<br />
  56. 56. Инструмент: Threat Modeling ToolАрхитектура решения<br />
  57. 57. Microsoft Solution FrameworkРесурсы<br />Основы Microsoft Solution Framework, Майкл С.В. Тернерhttp://www.rusedit.com/book.aspx?BookID=1280<br />Руководство по применению MSF<br />
  58. 58. Определение персонРесурсы<br />Personas: Practice and Theory Whitepaper<br />http://research.microsoft.com/en-us/um/people/jgrudin/publications/personas/pruitt-grudin.pdf<br />Книга о персонах<br /><ul><li>The Persona Lifecycle</li></li></ul><li>Рекомендации по написанию кодаРесурсы<br />Полные рекомендации могут быть найдены здесьhttp://msdn.microsoft.com/en-us/library/czefa0ke.aspx<br />Дополнительные детали и обоснования для рекомендаций описанных раньше.<br />Усилия сообщества, авторLance Hunt<br />C# Coding Standard for .NET<br />http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx<br />

×