Документ описывает принципы и подходы к управлению проектами в рамках Microsoft Solutions Framework (MSF) и Agile-разработки, акцентируя внимание на комбинировании ролей и гибких методах работы. Он также обсуждает важность тестирования, управления рисками и оптимизации процессов развертывания, а также подчеркивает необходимость создания персоны и сценариев для улучшения взаимодействия с пользователями. Упоминаются ресурсы и рекомендации для дальнейшего изучения, касающиеся разработки и применения MSF.

1. Опыт управления проектамиЕвгений КривошеевProgram Managerevgenykr@microsoft.com

2. ИсточникиMSFГруппы разработки MicrosoftMicrosoftServicesПодтверждение практикойMicrosoftOperations & TechnologyGroupMicrosoft Certified PartnersПроанализированы результаты проектных команд и групп разработкиРезультаты анализа контрастируют с индустриальной практикой и методамиКомбинированные результаты организованы и собраны в руководство «люди и процесс»C 1994 года

3. Группы представителей в MSF v4Модель командыУправлениепрограммойАрхитектураУправлениепродуктомРазработкаУдовлетворениепользователяТестированиеВыпуск /эксплуатацияПоставка решенияДизайн решенияОпределение решенияРазработка решенияПредставителиКачество решенияЮзабилити решенияРазвертывание решения

4. Группы представителей MSF v4РРВВНРРВННРРРРР РВВНВРВННВРВВННРоли могут комбинироваться, но некоторые сочетания несут в себе рискУправление продуктомУправление программойУдовлетворение пользователяУправление выпускомРазработкаТестированиеУправление продуктомУправление программойРазработкаТестированиеУдовлетворение пользователяУправление выпускомВВозможноННежелательноРРискованно

5. УправлениепрограммойУдовлетворениепользователяРазработкаУправлениепродуктомТестированиеГруппы представителей 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Тот же набор принциповТот же образ мышленияMSFCMMIMSFAgileОсновыMSF

9. Что выбирать?MSF для ASD:Для проектов с командами ориентированными на результат, которые могут работать без большого количества промежуточной документации.“Дотянуться” вместо “уместиться”Минималистический подходГибкие методологии пропагандируют адаптациюMSF для CMMI:Для проектов с длительным временем жизни, требующими истории принятых решений. Также, если организация работает над широкомасштабной инициативой улучшения качества и процессовили если команде требуется набор точных рекомендацийвместо опыта.

10. ЦиклОснова для ежедневной координированной работы командыТреки перекрываются с каждым и проверяются по контрольным точкамВидениеПланированиеРазработкаСтабилизацияРазвертываниеНепрерывныйИтерацияПроектЕжедневная сборкаВозврат кодаПринятая сборка

11. Версия3Версия2Версия1РазвертываниеРазвертываниеРазвертываниеСтабилизацияСтабилизацияСтабилизацияРазработкаРазработкаРазработкаПланированиеПланированиеПланированиеВидениеВидениеВидениеИтеративный подходЦиклМинимизация рисков посредством разделения больших проектов на версииВремя

12. Что такое видение?Определение видения проектаКороткий, согласованный тест лаконично описывающий цель создания новой или улучшенной системыПредоставляет команде обоснование создания системыВ идеальном случае содержит не больше 25 словЛюбой член команды может его запомнить и соотнести со своей ежедневной работой

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

14. Создание сценариевНаписание сценария:Сценарий – это единичный способ взаимодействия пользователя с системой. По мере того, как пользователь пытается достичь реального результата, сценарий описывает конкретные шаги, которые производит пользователь.Общее количество возможных сценариев практически бесконечно, поэтому важно выбрать важные.Могут описывать успешный путь или неуспешный.Расстановка приоритетов:Определите важность сценарияОрганизуйте сценарии по приоритетамИспользуйте модель Кано!

15. Удовлетворенный пользовательЛинейные потребностиПривлекательные потребностиНеобходимые потребности“Это клево”Редактирование страницы из панели инструментов IE

16. Бесплатный интернет в Starbucks

17. Убирающиеся фары

18. Отправка фотографий с мобильного телефона“Больше – лучше”Скорость соединения

19. Вкус кофе

20. Экономия топлива

21. Время жизни батареиНеважноеБедный функционалБогатый функционал“Мне все равно”Поддержка MapPoint

22. Цвет чашки

23. Размер колес

24. Напряжение батареи“Без этого мне продукт не нужен”Возможность печати

25. Горячий кофе

26. Тормоза в машине

27. Возможность переноса фотографий на компьютерНеудовлетворённый пользователь

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 + DREADMicrosoft Threat Modeling Tool

36. КодированиеЗадание разработкиМодульное тестирование (Unit Testing)Без вариантов!Простое правило: 70% покрытия кодаПолитика возврата кода (Check-in Policy)Возврат как можно раньшеПредотвращайте поломку сборкиМодульное тестирование завершено без ошибокАвтоматический анализ кодаОбзор кодаРефакторинг – это нормальноТребования меняютсяВидение меняется

37. Создание или обновлениемодульных тестовНаписание кода длязадания разработкиВыполнениемодульных тестовВозврат кода с учетомрекомендацийНачинать с теста или с кода?Задание разработкиНеважно, главное делать это!

38. КодированиеИсправление ошибкиКлассификация ошибокРекомендации процесса MSF 41 = В этой интеграции2 = В этой версии3 = Возможно, или, возможно, НЕ будет исправленоПрактика Microsoft: рассказывайте и спрашивайтеЧестность приносит плодыМодульное тестированиеПомогает убедиться в работе исправленияМожет быть использовано для воспроизведения ошибки

39. Ежедневная сборкаСборка продуктаЕжедневная сборка жизненно важнаЭто пульс проекта!Поддерживайте качество около 100%Используйтетесты проверки сборок(Build Verification Tests – BVT)Основаны на сценарияхЕжедневная интеграцияНет сюрпризов в концеЭкономит время

40. Тестовое заданиеТестирование сценарияВключайте тестовую группу в проектНе в концеАвтоматизируйте тестыВезде, где возможноЗакрытие ошибкиТестовая группа решает, НЕразработчики

41. Тестовое заданиеТестирование качестваТестирование производительностиГлобальная производительность, производительность сценарияНагрузочное тестирование (пользователи)Стресс-тестирование (ресурсы)Тестирование безопасностиРазнообразие ролей, средИсследовательское тестированиеТворческая работаДействуйте как персона

42. РискУправление проектомХарактеристикиПрисуще каждому проектуНи плохо, ни хорошоНе пугаться, а управлятьУпрощенная среда управления рискамиРиск это просто еще одна задача

43. Мониторинг проектаУправление проектомОставшаяся работаСколько работы осталось и когда она будет закончена?Индикатор качестваКакое качество у проекта?СкоростьКак быстро команда завершает задачи?Незапланированная работаНасколько много незапланированной работы?Реальная и запланированная работаСколько сценариев может быть завершено прежде чем качество станет неприемлемым?Количество ошибокКоличество повторных ошибок

44. СтабилизацияСфокусируйтесь на выпуске продуктаФункционально законченная версияНовый функционал НЕ добавляетсяИсправленные ошибки должны превысить найденныеБалансирует стабильность против потребностей клиентаМожет вылиться в потерю какой-либо функциональности ради стабильности

45. РазвертываниеMicrosoft Solutions FrameworkПланированиеЭксплуатацияРазработкаРазвертываниеMicrosoft Operations Framework

46. РазвертываниеЦель: Запуск или приемкаФокус командыСтимулировать беспроблемную передачу решения от проектной команды к эксплуатационнойПолучить приемку решения заказчиком, подтвердить, что проект законченАртефактыХранилище всех версий документов, наборов загрузки, конфигураций, скриптов и кодаКомментарии к релизу

47. Практика развертыванияТестировать развертывание как можно раньше в среде близкой к «боевой»Развертывать множество раз в течение разработки для улучшения процесса развертыванияАвтоматизировать как можно большеПисать полезные и свежие комментарии к релизуТесно работать с эксплуатационной командой