5. • Планирование
Выявление целей, планирование работ, определение и
выделение ресурсов
• Выполнение
• Проверка
Контроль результата, выявление отклонений,
установление причин отклонений
• Корректировка
принятие мер по устранению причин отклонений,
перераспределение работ, ресурсов.
7. Производительность труда
Адам Смит
1. Уменьшение времени на смену рода занятия в процессе
производства.
2. Автоматизция работы каждого конкретного рабочего
3. Совершенствование рабочих в каком-то конкретном
навыке, который нужен именно на этом участке
работ.
8. Исследования по переключению
задач
Мейер, Эванс и Рубинштайн
Переключение задачи происходит в две стадии
1. Перемена цели
2. Активация правила
Мейер: при постоянном переключении между двумя
задачами теряется до 40% производственного времени,
между тремя – до 80% производственного времени.
Пример: разговор по телефону во время езды
9. Состояние потока
Поток, или потоковое состояние — психическое состояние, в
котором человек полностью включён в то, чем он
занимается, что характеризуется деятельным
сосредоточением, полным вовлечением и нацеленностью
на успех в процессе деятельности.
• Михай Чиксентмихайи
10. Описание состояния потока
• ощущение удовольствия от самореализации
• повышенная и обоснованная уверенность в себе
• ярко выраженное повышение коммуникативных
способностей
• умение четко и ясно выражать свои мысли
• умение убеждать собеседника
• эффективно решать проблемы любой сложности или
находить неординарные способы их решения
12. Признаки состояния потока
• Ясные цели.
• Высокая степень концентрации на ограниченной сфере
внимания.
• Отсутствие рефлексии.
• Искажённое восприятие времени.
• Прямая и незамедлительная обратная связь.
• Равновесие между уровнем способностей и сложности
задания.
• Ощущение полного контроля над ситуацией или
деятельностью.
14. PMBOK4
•
•
•
Свод знаний по управлению проектами
Разрабатывается PMI (www.pmi.org)
ВШД 02.013-2008
Описывает 5 групп процессов
• Инициация
• Планирование
• Выполнение
• Мониторинг и контроль
• Завершение
Описание каждого процесса проходит по схеме:
• Входы
• Инструменты и техники
• Выходы
• Зависимости с другими процессами
15. Определения
Проект— уникальная деятельность, имеющая начало и
конец во времени, направленная на достижение заранее
определённого результата/цели, создание
определённого, уникального продукта или услуги, при
заданных ограничениях по ресурсам и срокам, а также
требованиям к качеству и допустимому уровню риска.
Управление проектами - это приложение знаний, навыков,
инструментов и методов к операциям проекта для
удовлетворения требований, предъявляемых в проекту.
(PMBOK 4)
16. Управление проектами включает:
• Определение требований;
• Установку четких и достижимых целей;
• Уравновешивание противоречащих требований по качеству,
содержанию, времени и стоимости;
• Коррекцию характеристик, планов и подхода в соответствии с
мнением и ожиданиями различных участников проекта.
17. Программа проектов – это ряд связанных друг с другом
проектов, управление которыми координируется для
достижения преимуществ и степени управляемости,
недоступных при управлении ими по отдельности.
Портфель проектов — это набор проектов, программ
проектов и других работ, объединенных вместе для
достижения более эффективного управления и
обеспечения выполнения стратегических целей
организации.
18. Определяет 9 ключевых областей знаний по управлению
проектами:
• Управление интеграцией проекта
• Управление содержанием проекта
• Управление временем проекта
• Управление стоимостью проекта
• Управление качеством проекта
• Управление человеческими ресурсами проекта
• Управление коммуникациями на проекте
• Управление рисками проекта
• Управление закупками проекта
19.
20. MSF
• http://msdn.microsoftcom/ru-ru/vstudio/aa718795.aspx
• ВШД 02.016-2008
Ключевые концепции
• Партнерство с заказчиками
• Единая точка зрения
• Инкрементная выдача результатов
• Инвестиции в качество
• Широкие полномочия участников проекта
• Четкая подотчетность
• Учет любого опыта
• Свободное общение
• Гибкость и готовность к переменам
22. Модель водопада
• 1970, Winston W. Royce
• ВШД 02.012-1970
•
•
•
•
•
•
•
Определение требований
Проектирование
Конструирование («реализация» либо «кодирование»)
Интеграция
Тестирование и отладка (также «верификация»)
Инсталляция
Поддержка
23.
24. Спиралевидная модель
• 1988, Барри Боэм
• http://csse.usc.edu/csse/about/people/faculties/BarryBoehm
.html
• ВШД 02.015-2000
• Центральная идея – управление рисками
• Развитие проекта ведется по спирали
• Каждый виток проходит через 4 сектора:
–
–
–
–
определение целей, альтернатив и ограничений
идентификация, оценка и разрешение рисков
планирование
разработка и тестирование
25.
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)
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
Кроссфункциональность
– Специализация должна быть разумной
– Не должно быть искусственного и избыточного деления по ролям
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 неделю спринта
• Что было хорошего в спринте?
• Что было хорошего, но можно улучшить?
• Улучшения
46.
47.
48. Daily Scrum
• Что было сделано с предыдущего митинга
• Чем буду заниматься до следующего митинга
• Какие есть препятствия?
• 15 минут
• Это не статусный митинг
• Говорят только свиньи, цыплята только слушают
50. Release Backlog
• Product Owner (приоритезация, содержание, доступность)
• Никогда не заканчивается (пока существует продукт)
• Постоянно меняется
• Приоритезация на основе рисков, ценности и
необходимости
52. Sprint Backlog
• Задачи, необходимые для выполнения элементов Product
Backlog
• Уровень декомпозиции задач достаточный, чтобы можно
было понимать прогресс на Daily Scrum
55. Критерий завершенности
• Для принятия решения о выпуске той или иной фичи нужно
знать, что она сделана
• Критерий завершенности задачи
• Пример критерия завершенности задачи, если выполнены:
–
–
–
–
–
–
Анализ
Проектирование
Рефакторинг
Программирование
Документирование
Тестирование (юнит, системное, пользовательское, регрессионное,
нефункциональное)
56. Ограничения SCRUM
•
•
•
•
•
Небольшой размер команды
Заказчик как неотъемлемая часть команды (Proxy)
Локализация команды в одном месте
Архитектура специально не разрабатывается
Объем требований и степень документированности
информации
• Культура и окружение
• Ограничения компании
–
–
–
–
Регламенты и процедуры
Корпоративная культура
Стили управления
Фиксированный график и объем
58. TDD
Test Driven Development (TDD):
1. Автоматические тесты
2. Программный код, который удовлетворяет одному тесту
3. Рефакторинг (восприятие кода, удаление дублирований)
4. Повторяем шаги
•
TDD использовать трудно
–
–
–
Требуется время на овладение техникой
Меры по облегчению написания тестов (обучение, набор
инструментов, специальные приемы проектирования)
Тесты тоже надо проектировать
59. Набор инструментов
• Библиотеки для тестирования
– Юнит-тестирование (NUnit)
– Тестирование интерфейсов (Selenium)
– Нагрузочное тестирование (NoeLoad)
• База данных не требующая сервера (SqLite)
• Средство для вычисления метрик покрытия кода (NСover,
Dot Cover)
• Mockups (заглушки)
60. • TDD для новой функциональности
• TDD для существующей функциональности
– тяжело (тесты будут повторять неидеальную архитектуру,
включать предположения о реализации классов)
– возможно, лучше предоставить набор утилит для облегчения
ручного тестирования
66. Постоянный уровень интенсивности
работы
• Переработки дают только кратковременный эффект
• В долгосрочной перспективе переработки не приводят к
увеличению объема работ
• Постоянные переработки приводят к:
– Снижению производительности
– Увеличению числа ошибок
– Потере самомотивации
67. MSF For Agile Software Dev.
• ВШД 02.016-2008
• Попытка адаптации принципов гибкой разработки
приложений к продуктам компании Microsoft
• В описание процесса встраиваются технологические
операции с помощью инструментов компании
68. Принципы MSF
•
•
•
•
•
•
•
•
•
•
Партнерство с заказчиками (вовлечение заказчика в проект)
Единая точка зрения на подходы к решению задач
Инкрементная выдача результатов
Инвестиции в качество (планирование итераций на
исправление дефектов)
Широкие полномочия участников проекта (необходимые
полномочия для выполнения задач)
Команда – это группа равнозначных сотрудников с четкой
подотчетностью, разделяемой ответственностью и свободным
общением
Четкая подотчетность
Учет любого опыта
Свободное общение
Гибкость и готовность к переменам
69. Проектные роли
Бизнес-аналитик
• Действия
–
–
–
–
Формулировка концепции проекта
Разработка требований к качеству
Создание сценария
Планирование итерации
• Операции
–
–
–
–
–
–
Написание концепции
Обзор целей
Определение приоритетов
Выполнение ретроспективного анализа
Оценка требований
Определение требований безопасности
70. Менеджер проекта
• Действия
– Контроль итерации
– Планирование итерации
– Ведение проекта
• Операции
–
–
–
–
–
–
Оценка задач, требований
Мониторинг итерации
Определение, снижение риска
Выполнение ретроспективного анализа
Определение пороговых значений тестов
Составление графиков реализации
71. Архитектор
• Действия
– Разработка архитектуры решения
– Планирование итерации
• Операции
–
–
–
–
–
Разработка моделей угроз, производительности, архитектуры
Разбиение требований на задачи
Определение требований безопасности
Выделение подсистем
Определение интерфейсов
72. Разработчик
• Действия
–
–
–
–
•
Сборка продукта
Устранение дефекта
Реализация задачи по разработке
Планирование итерации
Операции
–
–
–
–
–
–
–
–
–
–
Определение интерфейсов
Выделение подсистем
Разработка модели производительности
Манипулирование сборками
Работа с дефектами
Тестирование (в т.ч. автоматизированное)
Рефакторинг, code review, анализ кода
Оценка задач, сценариев
Кодирование
Выполнение ретроспективного анализа
73. Тестирование
• Действия
–
–
–
–
Планирование итерации
Закрытие дефекта
Тестирование требования к качеству
Проверка сценария
• Операции
–
–
–
–
–
–
Выполнение ретроспективного анализа
Разбиение требований, сценариев на задачи
Проверка исправлений, закрытие дефектов
Создание различных видов тестов
Документирование дефекта
Оценка пороговых значений показателей тестов
75. Администратор баз данных
• Создание проекта базы данных
• Развертывание проекта базы данных
Разработчик баз данных
• Реализация задачи по развертыванию базы данных
• Планирование итерации
76. Описатели
Дефект – предоставление пользователям сведений,
необходимых для полного понимания влияния проблемы
на систему:
• Информация должна помогать воспроизведению бага
• Проблема должно четко проявляться в ходе тестов
77. Требования к качеству
• Производительность
• Загрузка
• Доступность
• Специальные возможности
• Удобство обслуживания и сопровождения
78. Сценарий – один из возможных вариантов взаимодействия
пользователя с системой (упрощения Use Case)
• Успешные
• Безуспешные
79. Риск – вероятное событие или фактор, который может
оказать негативное влияние на проект в будущем
Отношение к проявлению рисков должно быть
положительным
81. Результаты работ
• Диаграмма приложения
• Пакет изменений
– Задержанные
– Отложенные
– Зафиксированные
•
•
•
•
•
•
•
Диаграмма классов
Исходный код
План итерации
Нагрузочный тест
Логическая диаграмма центра обработки данных
Ручной тест
Собирательный образ
82. •
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Контрольный список проекта
Список требований к качеству
План выпуска продукта
Описание сценария
Список сценариев
Раскадровка
Диаграмма системы
Групповая сборка
Подход к тестированию
Результат тестирования
Модель угроз
Тест модуля
Концепция проекта
Веб-тест
Прототип
83. Отчеты
•
•
•
•
Качество и скорость
Приоритетные дефекты
Интенсивность дефектов
Индикаторы качества
– Количество тестов (проходящих и непроходящих)
– Активные баги
– Покрытие кода тестами
•
•
•
•
Оставшаяся работа
Внеплановая работа
Темп
Возобновленные работы
