Документ содержит инструкцию по управлению проектами, включая методы планирования, контроля и корректировки. Он описывает состояния потока в работе, методологии Agile, включая Scrum и TDD, а также различные модели управления проектом. Включает концепции команды, взаимодействия с заказчиками и принципы успешного выполнения проектов.

1. УК 03.005.02-2011
Учебный курс. Обучение.
Управление проектами.

2. Chaos Report

3. Основы управления

4. Цикл Деминга-Шухарта

5. • Планирование
Выявление целей, планирование работ, определение и
выделение ресурсов
• Выполнение
• Проверка
Контроль результата, выявление отклонений,
установление причин отклонений
• Корректировка
принятие мер по устранению причин отклонений,
перераспределение работ, ресурсов.

6. Параметры управления

7. Производительность труда
Адам Смит
1. Уменьшение времени на смену рода занятия в процессе
производства.
2. Автоматизция работы каждого конкретного рабочего
3. Совершенствование рабочих в каком-то конкретном
навыке, который нужен именно на этом участке
работ.

8. Исследования по переключению
задач
Мейер, Эванс и Рубинштайн
Переключение задачи происходит в две стадии
1. Перемена цели
2. Активация правила
Мейер: при постоянном переключении между двумя
задачами теряется до 40% производственного времени,
между тремя – до 80% производственного времени.
Пример: разговор по телефону во время езды

9. Состояние потока
Поток, или потоковое состояние — психическое состояние, в
котором человек полностью включён в то, чем он
занимается, что характеризуется деятельным
сосредоточением, полным вовлечением и нацеленностью
на успех в процессе деятельности.
• Михай Чиксентмихайи

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

11. Истоки
•
•
•
•
Буддизм
Религиозные практики
Спорт
Боевые искусства

12. Признаки состояния потока
• Ясные цели.
• Высокая степень концентрации на ограниченной сфере
внимания.
• Отсутствие рефлексии.
• Искажённое восприятие времени.
• Прямая и незамедлительная обратная связь.
• Равновесие между уровнем способностей и сложности
задания.
• Ощущение полного контроля над ситуацией или
деятельностью.

13. Зачем нужен поток?
• Удовлетворенность результатом
• Продуктивность

14. PMBOK4
•
•
•
Свод знаний по управлению проектами
Разрабатывается PMI (www.pmi.org)
ВШД 02.013-2008
Описывает 5 групп процессов
• Инициация
• Планирование
• Выполнение
• Мониторинг и контроль
• Завершение
Описание каждого процесса проходит по схеме:
• Входы
• Инструменты и техники
• Выходы
• Зависимости с другими процессами

15. Определения
Проект— уникальная деятельность, имеющая начало и
конец во времени, направленная на достижение заранее
определённого результата/цели, создание
определённого, уникального продукта или услуги, при
заданных ограничениях по ресурсам и срокам, а также
требованиям к качеству и допустимому уровню риска.
Управление проектами - это приложение знаний, навыков,
инструментов и методов к операциям проекта для
удовлетворения требований, предъявляемых в проекту.
(PMBOK 4)

16. Управление проектами включает:
• Определение требований;
• Установку четких и достижимых целей;
• Уравновешивание противоречащих требований по качеству,
содержанию, времени и стоимости;
• Коррекцию характеристик, планов и подхода в соответствии с
мнением и ожиданиями различных участников проекта.

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

18. Определяет 9 ключевых областей знаний по управлению
проектами:
• Управление интеграцией проекта
• Управление содержанием проекта
• Управление временем проекта
• Управление стоимостью проекта
• Управление качеством проекта
• Управление человеческими ресурсами проекта
• Управление коммуникациями на проекте
• Управление рисками проекта
• Управление закупками проекта

20. MSF
• http://msdn.microsoftcom/ru-ru/vstudio/aa718795.aspx
• ВШД 02.016-2008
Ключевые концепции
• Партнерство с заказчиками
• Единая точка зрения
• Инкрементная выдача результатов
• Инвестиции в качество
• Широкие полномочия участников проекта
• Четкая подотчетность
• Учет любого опыта
• Свободное общение
• Гибкость и готовность к переменам

21. Модели разработки ПО

22. Модель водопада
• 1970, Winston W. Royce
• ВШД 02.012-1970
•
•
•
•
•
•
•
Определение требований
Проектирование
Конструирование («реализация» либо «кодирование»)
Интеграция
Тестирование и отладка (также «верификация»)
Инсталляция
Поддержка

24. Спиралевидная модель
• 1988, Барри Боэм
• http://csse.usc.edu/csse/about/people/faculties/BarryBoehm
.html
• ВШД 02.015-2000
• Центральная идея – управление рисками
• Развитие проекта ведется по спирали
• Каждый виток проходит через 4 сектора:
–
–
–
–
определение целей, альтернатив и ограничений
идентификация, оценка и разрешение рисков
планирование
разработка и тестирование

26. TOP-10 рисков в 1988 по Боэму
•
•
•
•
•
•
•
•
•
•
Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
«Золотая сервировка», перфекционизм, ненужная оптимизация
и оттачивание деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах, определяющих
окружение системы или вовлечённых в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению
к проекту) ресурсами.
Недостаточная производительность получаемой системы.
«Разрыв» в квалификации специалистов разных областей
знаний.

27. Методологии
•
•
Формальные
– RUP
Гибкие
– Agile Modeling
– Agile Unified Process (AUP)
– Agile Data Method
– DSDM
– Essential Unified Process (EssUP)
– Экстремальное программирование (Extreme programming, XP)
– Feature Driven Development (FDD)
– Getting Real
– Open Unified Process (OpenUP)
– Scrum
– Бережливая разработка программного обеспечения (Lean Software
Development)

28. Типология
Люди делятся на:
• Рациональные (анализ)
• Иррациональные (синтез)

29. Ценности Agile
• Личности и их взаимодействие важнее, чем процессы и
инструменты
• Работоспособное программное обеспечение важнее, чем
обширная документация
• Сотрудничество с заказчиком важнее, чем переговоры по
контрактам
• Умение реагировать на изменения важнее, чем следовать
плану

30. SCRUM
Преобладающая на сегодняшний день методология
Источники
• SCRUM Guide, ВШД 02.017-2010 (scrum.org)
• Scrum and XP from the Trenches, ВШД 02.019 (infoq.com)
• Обзор методологии SCRUM
(http://citforum.ru/SE/project/scrum/)
• Задача масштабирования Agile
(http://www.agilerussia.ru/2007/06/zadacha-masshtabirovaniaagile.html)
• Практика внедрения SCRUM, ВШД 02.018-2008 (scrumtek.ru)

31. Базовые ценности SCRUM
• Эффективные коммуникации
– Достигается за счет обязательного участия каждого члена команды
в Scrum Planning Meeting, Review, Retrospective, Daily Scrum
– Обеспечивать качественное распространение информации
– Повысить вовлеченность в процесс
• Самоорганизация команды
– Поддерживать самомотивацию
– Стимул к кроссфункциональности
– Снижение нагрузки на управленческое звено
• Жесткие временные рамки
– Длительность итерации жестко фиксируется
– Объем работ на итерацию фиксируется и соблюдается
– Время проведения Daily Scrum фиксировано в рамках итерации

32. Составные части SCRUM
• Команда (SCRUM Team)
• Временные рамки (Time-boxes)
• Артефакты
Артефакт – общее название любого вида информации,
создаваемой, изменяемой или используемой в проекте
Документ ~ Артефакт
• Правила

33. Командные роли
• Свиньи (члены проектной команды)
• Цыплята (заинтересованные лица, за пределами
проектной команды)

34. ScrumMaster
• Следование ценностям Agile, практики и правила
• Обучение через лидерство и коучинг повышению
производительности и повышению качества ПО
• Помощь в самоорганизации и кроссфункциональности
• Своевременное решение всех проблем, тормозящих или
останавливающих работу любого члена команды

35. Product Owner
• В единственном числе
• Управление Product Backlog
• Ценность выполняемой работы проектной команды
• Никто другой не может менять приоритеты задач
• Команда получает виденье у бизнеса. Если его нет, то команда
участвует в разработке виденья.
• Win-Win исход для команды и бизнеса.
• Максимальные усилия команды для того, чтобы идеи бизнеса
заработали в продукте – ключ к получению взаимного доверия.

36. Проектная команда
•
•
Преобразует содержимое бэклога в инкрементное приращение, которое
выдается на каждом спринте
Команда самоорганизующаяся:
– Почти все члены команды являются носителями адекватного видения того, что они
делают;
– Почти все хорошо мотивированны;
– Почти все возможные управленческие функции (управление другими и собой) по
максимуму делегированы членам команды;
– Хотя бы раз в месяц они добиваются успеха вместе;
– Посидеть с кем-то в паре и помочь ему с решением задачи почти так же важно, как
и решать свою задачу
•
•
Оптимальный размер команды: 7 ± 2
Кроссфункциональность
– Специализация должна быть разумной
– Не должно быть искусственного и избыточного деления по ролям

37. Кроссфункциональность
Organizational Patterns of Agile Software Development by
Coplien and Harrison (2004), ВШД 02.020-2007

40. Временные рамки
•
•
•
•
•
•
Release Planning Meeting
Sprint
Sprint Planning Meeting
Sprint Review
Sprint Retrospective
Daily Scrum

41. Release Planning Meeting
• Установить планы и цели перед командой
• Приоритезация и оценка Product Backlog для релиза
• Необязательный

42. Sprint
•
•
•
•
итерация
фиксирован во времени
изменения не влияют на достижение целей
длительность 1-4 недели
•
•
•
•
•
Рабочий билд и релиз-версия
Стабилизационные спринты
10-15% времени необходимо на стабилизацию
В момент стабилизации менять требования нельзя
Изменения требований даже безобидные (поменять текст,
ссылку, форматирование) могут повлиять на стабильную работу
системы

43. Sprint Planning Meeting
• планирование итерации
• 2 часа на одну неделю спринта
• Два вопроса:
– Что делать?
– Как делать?

44. Sprint Review
• 1 час на одну неделю спринта
• что было сделано (Product Owner)
• что не было сделано
• Что было хорошего
• Какие есть проблемы
• Как решить эти проблемы
• Демонстрация выполненных задач и ответы на вопросы
• Обсуждение Product Backlog (Product Owner)

45. Sprint Retrospective
• После Sprint Review, до следующего Sprint Planning Meeting
• 0,75 часа на 1 неделю спринта
• Что было хорошего в спринте?
• Что было хорошего, но можно улучшить?
• Улучшения

48. Daily Scrum
• Что было сделано с предыдущего митинга
• Чем буду заниматься до следующего митинга
• Какие есть препятствия?
• 15 минут
• Это не статусный митинг
• Говорят только свиньи, цыплята только слушают

49. Артефакты
•
•
•
•
Release Backlog
Release Burndown
Sprint Backlog
Sprint Burndown

50. Release Backlog
• Product Owner (приоритезация, содержание, доступность)
• Никогда не заканчивается (пока существует продукт)
• Постоянно меняется
• Приоритезация на основе рисков, ценности и
необходимости

51. Release Burndown

52. Sprint Backlog
• Задачи, необходимые для выполнения элементов Product
Backlog
• Уровень декомпозиции задач достаточный, чтобы можно
было понимать прогресс на Daily Scrum

53. Sprint Burndown

55. Критерий завершенности
• Для принятия решения о выпуске той или иной фичи нужно
знать, что она сделана
• Критерий завершенности задачи
• Пример критерия завершенности задачи, если выполнены:
–
–
–
–
–
–
Анализ
Проектирование
Рефакторинг
Программирование
Документирование
Тестирование (юнит, системное, пользовательское, регрессионное,
нефункциональное)

56. Ограничения SCRUM
•
•
•
•
•
Небольшой размер команды
Заказчик как неотъемлемая часть команды (Proxy)
Локализация команды в одном месте
Архитектура специально не разрабатывается
Объем требований и степень документированности
информации
• Культура и окружение
• Ограничения компании
–
–
–
–
Регламенты и процедуры
Корпоративная культура
Стили управления
Фиксированный график и объем

57. Практики

58. TDD
Test Driven Development (TDD):
1. Автоматические тесты
2. Программный код, который удовлетворяет одному тесту
3. Рефакторинг (восприятие кода, удаление дублирований)
4. Повторяем шаги
•
TDD использовать трудно
–
–
–
Требуется время на овладение техникой
Меры по облегчению написания тестов (обучение, набор
инструментов, специальные приемы проектирования)
Тесты тоже надо проектировать

59. Набор инструментов
• Библиотеки для тестирования
– Юнит-тестирование (NUnit)
– Тестирование интерфейсов (Selenium)
– Нагрузочное тестирование (NoeLoad)
• База данных не требующая сервера (SqLite)
• Средство для вычисления метрик покрытия кода (NСover,
Dot Cover)
• Mockups (заглушки)

60. • TDD для новой функциональности
• TDD для существующей функциональности
– тяжело (тесты будут повторять неидеальную архитектуру,
включать предположения о реализации классов)
– возможно, лучше предоставить набор утилит для облегчения
ручного тестирования

61. Коллективное владение кодом
• Code Review (в меньшей степени)
• Парное программирование с частой сменой пар

62. Информативное рабочее
пространство (Taskboard)

65. Стандарты кодирования
• Однородность кода
• Качество кода

66. Постоянный уровень интенсивности
работы
• Переработки дают только кратковременный эффект
• В долгосрочной перспективе переработки не приводят к
увеличению объема работ
• Постоянные переработки приводят к:
– Снижению производительности
– Увеличению числа ошибок
– Потере самомотивации

67. MSF For Agile Software Dev.
• ВШД 02.016-2008
• Попытка адаптации принципов гибкой разработки
приложений к продуктам компании Microsoft
• В описание процесса встраиваются технологические
операции с помощью инструментов компании

68. Принципы MSF
•
•
•
•
•
•
•
•
•
•
Партнерство с заказчиками (вовлечение заказчика в проект)
Единая точка зрения на подходы к решению задач
Инкрементная выдача результатов
Инвестиции в качество (планирование итераций на
исправление дефектов)
Широкие полномочия участников проекта (необходимые
полномочия для выполнения задач)
Команда – это группа равнозначных сотрудников с четкой
подотчетностью, разделяемой ответственностью и свободным
общением
Четкая подотчетность
Учет любого опыта
Свободное общение
Гибкость и готовность к переменам

69. Проектные роли
Бизнес-аналитик
• Действия
–
–
–
–
Формулировка концепции проекта
Разработка требований к качеству
Создание сценария
Планирование итерации
• Операции
–
–
–
–
–
–
Написание концепции
Обзор целей
Определение приоритетов
Выполнение ретроспективного анализа
Оценка требований
Определение требований безопасности

70. Менеджер проекта
• Действия
– Контроль итерации
– Планирование итерации
– Ведение проекта
• Операции
–
–
–
–
–
–
Оценка задач, требований
Мониторинг итерации
Определение, снижение риска
Выполнение ретроспективного анализа
Определение пороговых значений тестов
Составление графиков реализации

71. Архитектор
• Действия
– Разработка архитектуры решения
– Планирование итерации
• Операции
–
–
–
–
–
Разработка моделей угроз, производительности, архитектуры
Разбиение требований на задачи
Определение требований безопасности
Выделение подсистем
Определение интерфейсов

72. Разработчик
• Действия
–
–
–
–
•
Сборка продукта
Устранение дефекта
Реализация задачи по разработке
Планирование итерации
Операции
–
–
–
–
–
–
–
–
–
–
Определение интерфейсов
Выделение подсистем
Разработка модели производительности
Манипулирование сборками
Работа с дефектами
Тестирование (в т.ч. автоматизированное)
Рефакторинг, code review, анализ кода
Оценка задач, сценариев
Кодирование
Выполнение ретроспективного анализа

73. Тестирование
• Действия
–
–
–
–
Планирование итерации
Закрытие дефекта
Тестирование требования к качеству
Проверка сценария
• Операции
–
–
–
–
–
–
Выполнение ретроспективного анализа
Разбиение требований, сценариев на задачи
Проверка исправлений, закрытие дефектов
Создание различных видов тестов
Документирование дефекта
Оценка пороговых значений показателей тестов

74. Релиз-менеджер
• Действия
– Выпуск-продукта
• Операции
– Выпуск релиза
– Развертывание релиза
– Создание заметок о выпуске

75. Администратор баз данных
• Создание проекта базы данных
• Развертывание проекта базы данных
Разработчик баз данных
• Реализация задачи по развертыванию базы данных
• Планирование итерации

76. Описатели
Дефект – предоставление пользователям сведений,
необходимых для полного понимания влияния проблемы
на систему:
• Информация должна помогать воспроизведению бага
• Проблема должно четко проявляться в ходе тестов

77. Требования к качеству
• Производительность
• Загрузка
• Доступность
• Специальные возможности
• Удобство обслуживания и сопровождения

78. Сценарий – один из возможных вариантов взаимодействия
пользователя с системой (упрощения Use Case)
• Успешные
• Безуспешные

79. Риск – вероятное событие или фактор, который может
оказать негативное влияние на проект в будущем
Отношение к проявлению рисков должно быть
положительным

80. Задача – некоторая работа.
Используется каждой ролью по-своему.

81. Результаты работ
• Диаграмма приложения
• Пакет изменений
– Задержанные
– Отложенные
– Зафиксированные
•
•
•
•
•
•
•
Диаграмма классов
Исходный код
План итерации
Нагрузочный тест
Логическая диаграмма центра обработки данных
Ручной тест
Собирательный образ

82. •
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Контрольный список проекта
Список требований к качеству
План выпуска продукта
Описание сценария
Список сценариев
Раскадровка
Диаграмма системы
Групповая сборка
Подход к тестированию
Результат тестирования
Модель угроз
Тест модуля
Концепция проекта
Веб-тест
Прототип

83. Отчеты
•
•
•
•
Качество и скорость
Приоритетные дефекты
Интенсивность дефектов
Индикаторы качества
– Количество тестов (проходящих и непроходящих)
– Активные баги
– Покрытие кода тестами
•
•
•
•
Оставшаяся работа
Внеплановая работа
Темп
Возобновленные работы