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

Chaos Report

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

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

• ПланированиеВыявление целей, планирование работ, определение и выделение ресурсов

• Выполнение

• ПроверкаКонтроль результата, выявление отклонений, установление причин отклонений

• Корректировкапринятие мер по устранению причин отклонений, перераспределение работ, ресурсов.

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

Производительность труда

Адам Смит

1. Уменьшение времени на смену рода занятия в процессе производства.

2. Автоматизция работы каждого конкретного рабочего

3. Совершенствование рабочих в каком-то конкретном навыке, который нужен именно на этом участке работ.

Исследования по переключению задач

Мейер, Эванс и Рубинштайн

Переключение задачи происходит в две стадии

1. Перемена цели

2. Активация правила

Мейер: при постоянном переключении между двумя задачами теряется до 40% производственного времени,

между тремя – до 80% производственного времени.

Пример: разговор по телефону во время езды

Состояние потока

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

• Михай Чиксентмихайи

Описание состояния потока

• ощущение удовольствия от самореализации

• повышенная и обоснованная уверенность в себе

• ярко выраженное повышение коммуникативных способностей

• умение четко и ясно выражать свои мысли

• умение убеждать собеседника

• эффективно решать проблемы любой сложности или находить неординарные способы их решения

Истоки

• Буддизм

• Религиозные практики

• Спорт

• Боевые искусства

Признаки состояния потока

• Ясные цели.

• Высокая степень концентрации на ограниченной сфере внимания.

• Отсутствие рефлексии.

• Искажённое восприятие времени.

• Прямая и незамедлительная обратная связь.

• Равновесие между уровнем способностей и сложности задания.

• Ощущение полного контроля над ситуацией или деятельностью.

Зачем нужен поток?

• Удовлетворенность результатом

• Продуктивность

PMBOK4

• Свод знаний по управлению проектами• Разрабатывается PMI (www.pmi.org)• ВШД 02.013-2008

Описывает 5 групп процессов• Инициация• Планирование• Выполнение• Мониторинг и контроль• Завершение

Описание каждого процесса проходит по схеме:• Входы• Инструменты и техники• Выходы• Зависимости с другими процессами

Определения

Проект— уникальная деятельность, имеющая начало и конец во времени, направленная на достижение заранее определённого результата/цели, создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска.

Управление проектами - это приложение знаний, навыков,инструментов и методов к операциям проекта дляудовлетворения требований, предъявляемых в проекту.

(PMBOK 4)

Управление проектами включает:

• Определение требований;

• Установку четких и достижимых целей;

• Уравновешивание противоречащих требований по качеству, содержанию, времени и стоимости;

• Коррекцию характеристик, планов и подхода в соответствии смнением и ожиданиями различных участников проекта.

Программа проектов – это ряд связанных друг с другом проектов, управление которыми координируется для достижения преимуществ и степени управляемости, недоступных при управлении ими по отдельности.

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

Определяет 9 ключевых областей знаний по управлению проектами:

• Управление интеграцией проекта

• Управление содержанием проекта

• Управление временем проекта

• Управление стоимостью проекта

• Управление качеством проекта

• Управление человеческими ресурсами проекта

• Управление коммуникациями на проекте

• Управление рисками проекта

• Управление закупками проекта

MSF

• http://msdn.microsoftcom/ru-ru/vstudio/aa718795.aspx• ВШД 02.016-2008

Ключевые концепции• Партнерство с заказчиками• Единая точка зрения• Инкрементная выдача результатов• Инвестиции в качество• Широкие полномочия участников проекта• Четкая подотчетность• Учет любого опыта• Свободное общение• Гибкость и готовность к переменам

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

Модель водопада

• 1970, Winston W. Royce

• ВШД 02.012-1970

• Определение требований

• Проектирование

• Конструирование («реализация» либо «кодирование»)

• Интеграция

• Тестирование и отладка (также «верификация»)

• Инсталляция

• Поддержка

Спиралевидная модель

• 1988, Барри Боэм

• http://csse.usc.edu/csse/about/people/faculties/BarryBoehm.html

• ВШД 02.015-2000

• Центральная идея – управление рисками

• Развитие проекта ведется по спирали

• Каждый виток проходит через 4 сектора:– определение целей, альтернатив и ограничений

– идентификация, оценка и разрешение рисков

– планирование

– разработка и тестирование

TOP-10 рисков в 1988 по Боэму

• Дефицит специалистов.• Нереалистичные сроки и бюджет.• Реализация несоответствующей функциональности.• Разработка неправильного пользовательского интерфейса.• «Золотая сервировка», перфекционизм, ненужная оптимизация

и оттачивание деталей.• Непрекращающийся поток изменений.• Нехватка информации о внешних компонентах, определяющих

окружение системы или вовлечённых в интеграцию.• Недостатки в работах, выполняемых внешними (по отношению

к проекту) ресурсами.• Недостаточная производительность получаемой системы.• «Разрыв» в квалификации специалистов разных областей

знаний.

Методологии

• Формальные– 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)

Типология

Люди делятся на:

• Рациональные (анализ)

• Иррациональные (синтез)

Ценности Agile

• Личности и их взаимодействие важнее, чем процессы и инструменты

• Работоспособное программное обеспечение важнее, чем обширная документация

• Сотрудничество с заказчиком важнее, чем переговоры по контрактам

• Умение реагировать на изменения важнее, чем следовать плану

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-masshtabirovania-agile.html)

• Практика внедрения SCRUM, ВШД 02.018-2008 (scrumtek.ru)

Базовые ценности SCRUM

• Эффективные коммуникации– Достигается за счет обязательного участия каждого члена команды

в Scrum Planning Meeting, Review, Retrospective, Daily Scrum

– Обеспечивать качественное распространение информации

– Повысить вовлеченность в процесс

• Самоорганизация команды– Поддерживать самомотивацию

– Стимул к кроссфункциональности

– Снижение нагрузки на управленческое звено

• Жесткие временные рамки– Длительность итерации жестко фиксируется

– Объем работ на итерацию фиксируется и соблюдается

– Время проведения Daily Scrum фиксировано в рамках итерации

Составные части SCRUM

• Команда (SCRUM Team)

• Временные рамки (Time-boxes)

• Артефакты

Артефакт – общее название любого вида информации, создаваемой, изменяемой или используемой в проекте

Документ ~ Артефакт

• Правила

Командные роли

• Свиньи (члены проектной команды)

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

ScrumMaster

• Следование ценностям Agile, практики и правила

• Обучение через лидерство и коучинг повышению производительности и повышению качества ПО

• Помощь в самоорганизации и кроссфункциональности

• Своевременное решение всех проблем, тормозящих или останавливающих работу любого члена команды

Product Owner

• В единственном числе

• Управление Product Backlog

• Ценность выполняемой работы проектной команды

• Никто другой не может менять приоритеты задач

• Команда получает виденье у бизнеса. Если его нет, то команда участвует в разработке виденья.

• Win-Win исход для команды и бизнеса.

• Максимальные усилия команды для того, чтобы идеи бизнеса заработали в продукте – ключ к получению взаимного доверия.

Проектная команда

• Преобразует содержимое бэклога в инкрементное приращение, которое выдается на каждом спринте

• Команда самоорганизующаяся:– Почти все члены команды являются носителями адекватного видения того, что они

делают;– Почти все хорошо мотивированны;– Почти все возможные управленческие функции (управление другими и собой) по

максимуму делегированы членам команды;– Хотя бы раз в месяц они добиваются успеха вместе;– Посидеть с кем-то в паре и помочь ему с решением задачи почти так же важно, как

и решать свою задачу

• Оптимальный размер команды: 7 ± 2• Кроссфункциональность

– Специализация должна быть разумной– Не должно быть искусственного и избыточного деления по ролям

Кроссфункциональность

Organizational Patterns of Agile Software Development by Coplien and Harrison (2004), ВШД 02.020-2007

Временные рамки

• Release Planning Meeting

• Sprint

• Sprint Planning Meeting

• Sprint Review

• Sprint Retrospective

• Daily Scrum

Release Planning Meeting

• Установить планы и цели перед командой

• Приоритезация и оценка Product Backlog для релиза

• Необязательный

Sprint

• итерация

• фиксирован во времени

• изменения не влияют на достижение целей

• длительность 1-4 недели

• Рабочий билд и релиз-версия

• Стабилизационные спринты

• 10-15% времени необходимо на стабилизацию

• В момент стабилизации менять требования нельзя

• Изменения требований даже безобидные (поменять текст, ссылку, форматирование) могут повлиять на стабильную работу системы

Sprint Planning Meeting

• планирование итерации

• 2 часа на одну неделю спринта

• Два вопроса:– Что делать?

– Как делать?

Sprint Review

• 1 час на одну неделю спринта

• что было сделано (Product Owner)

• что не было сделано

• Что было хорошего

• Какие есть проблемы

• Как решить эти проблемы

• Демонстрация выполненных задач и ответы на вопросы

• Обсуждение Product Backlog (Product Owner)

Sprint Retrospective

• После Sprint Review, до следующего Sprint Planning Meeting

• 0,75 часа на 1 неделю спринта

• Что было хорошего в спринте?

• Что было хорошего, но можно улучшить?

• Улучшения

Daily Scrum

• Что было сделано с предыдущего митинга

• Чем буду заниматься до следующего митинга

• Какие есть препятствия?

• 15 минут

• Это не статусный митинг

• Говорят только свиньи, цыплята только слушают

Артефакты

• Release Backlog

• Release Burndown

• Sprint Backlog

• Sprint Burndown

Release Backlog

• Product Owner (приоритезация, содержание, доступность)

• Никогда не заканчивается (пока существует продукт)

• Постоянно меняется

• Приоритезация на основе рисков, ценности и необходимости

Release Burndown

Sprint Backlog

• Задачи, необходимые для выполнения элементов Product Backlog

• Уровень декомпозиции задач достаточный, чтобы можно было понимать прогресс на Daily Scrum

Sprint Burndown

Критерий завершенности

• Для принятия решения о выпуске той или иной фичи нужно знать, что она сделана

• Критерий завершенности задачи

• Пример критерия завершенности задачи, если выполнены:

– Анализ

– Проектирование

– Рефакторинг

– Программирование

– Документирование

– Тестирование (юнит, системное, пользовательское, регрессионное, нефункциональное)

Ограничения SCRUM

• Небольшой размер команды

• Заказчик как неотъемлемая часть команды (Proxy)

• Локализация команды в одном месте

• Архитектура специально не разрабатывается

• Объем требований и степень документированности информации

• Культура и окружение

• Ограничения компании – Регламенты и процедуры

– Корпоративная культура

– Стили управления

– Фиксированный график и объем

Практики

TDD

Test Driven Development (TDD):

1. Автоматические тесты

2. Программный код, который удовлетворяет одному тесту

3. Рефакторинг (восприятие кода, удаление дублирований)

4. Повторяем шаги

• TDD использовать трудно– Требуется время на овладение техникой

– Меры по облегчению написания тестов (обучение, набор инструментов, специальные приемы проектирования)

– Тесты тоже надо проектировать

Набор инструментов

• Библиотеки для тестирования– Юнит-тестирование (NUnit)

– Тестирование интерфейсов (Selenium)

– Нагрузочное тестирование (NoeLoad)

• База данных не требующая сервера (SqLite)

• Средство для вычисления метрик покрытия кода (NСover, Dot Cover)

• Mockups (заглушки)

• TDD для новой функциональности

• TDD для существующей функциональности– тяжело (тесты будут повторять неидеальную архитектуру,

включать предположения о реализации классов)

– возможно, лучше предоставить набор утилит для облегчения ручного тестирования

Коллективное владение кодом

• Code Review (в меньшей степени)

• Парное программирование с частой сменой пар

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

Стандарты кодирования

• Однородность кода

• Качество кода

Постоянный уровень интенсивности работы

• Переработки дают только кратковременный эффект

• В долгосрочной перспективе переработки не приводят к увеличению объема работ

• Постоянные переработки приводят к: – Снижению производительности

– Увеличению числа ошибок

– Потере самомотивации

MSF For Agile Software Dev.

• ВШД 02.016-2008

• Попытка адаптации принципов гибкой разработки приложений к продуктам компании Microsoft

• В описание процесса встраиваются технологические операции с помощью инструментов компании

Принципы MSF

• Партнерство с заказчиками (вовлечение заказчика в проект)• Единая точка зрения на подходы к решению задач• Инкрементная выдача результатов• Инвестиции в качество (планирование итераций на

исправление дефектов)• Широкие полномочия участников проекта (необходимые

полномочия для выполнения задач)• Команда – это группа равнозначных сотрудников с четкой

подотчетностью, разделяемой ответственностью и свободным общением

• Четкая подотчетность • Учет любого опыта• Свободное общение• Гибкость и готовность к переменам

Проектные роли

Бизнес-аналитик

• Действия– Формулировка концепции проекта

– Разработка требований к качеству

– Создание сценария

– Планирование итерации

• Операции– Написание концепции

– Обзор целей

– Определение приоритетов

– Выполнение ретроспективного анализа

– Оценка требований

– Определение требований безопасности

Менеджер проекта

• Действия– Контроль итерации

– Планирование итерации

– Ведение проекта

• Операции– Оценка задач, требований

– Мониторинг итерации

– Определение, снижение риска

– Выполнение ретроспективного анализа

– Определение пороговых значений тестов

– Составление графиков реализации

Архитектор

• Действия– Разработка архитектуры решения

– Планирование итерации

• Операции– Разработка моделей угроз, производительности, архитектуры

– Разбиение требований на задачи

– Определение требований безопасности

– Выделение подсистем

– Определение интерфейсов

Разработчик• Действия

– Сборка продукта– Устранение дефекта– Реализация задачи по разработке– Планирование итерации

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

Тестирование

• Действия– Планирование итерации

– Закрытие дефекта

– Тестирование требования к качеству

– Проверка сценария

• Операции– Выполнение ретроспективного анализа

– Разбиение требований, сценариев на задачи

– Проверка исправлений, закрытие дефектов

– Создание различных видов тестов

– Документирование дефекта

– Оценка пороговых значений показателей тестов

Релиз-менеджер

• Действия– Выпуск-продукта

• Операции– Выпуск релиза

– Развертывание релиза

– Создание заметок о выпуске

Администратор баз данных

• Создание проекта базы данных

• Развертывание проекта базы данных

Разработчик баз данных

• Реализация задачи по развертыванию базы данных

• Планирование итерации

Описатели

Дефект – предоставление пользователям сведений, необходимых для полного понимания влияния проблемы на систему:

• Информация должна помогать воспроизведению бага

• Проблема должно четко проявляться в ходе тестов

Требования к качеству

• Производительность

• Загрузка

• Доступность

• Специальные возможности

• Удобство обслуживания и сопровождения

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

• Успешные

• Безуспешные

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

Отношение к проявлению рисков должно быть положительным

Задача – некоторая работа.

Используется каждой ролью по-своему.

Результаты работ

• Диаграмма приложения

• Пакет изменений– Задержанные

– Отложенные

– Зафиксированные

• Диаграмма классов

• Исходный код

• План итерации

• Нагрузочный тест

• Логическая диаграмма центра обработки данных

• Ручной тест

• Собирательный образ

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

Отчеты

• Качество и скорость

• Приоритетные дефекты

• Интенсивность дефектов

• Индикаторы качества– Количество тестов (проходящих и непроходящих)

– Активные баги

– Покрытие кода тестами

• Оставшаяся работа

• Внеплановая работа

• Темп

• Возобновленные работы