Гибкие методологии управления проектами

Август 8, 2022

Главная
Информатика
Гибкие методологии управления проектами

Содержание

2. Вопросы темы: Сравнение гибких методов с традиционным подходом История появления Agile Что такое управление ИТ-проектом Управление
3. Вопросы темы: Анализ и внедрение проекта с Agile Применение Agile на практике
4. Сравнение гибких методов с традиционным подходом 01 Вопрос
5. Принципы методов
6. Начнем с инкрементального подхода – это быстрое создание продукта с ограниченным, но работающим функционалом Инкрементальный подход
7. Итеративный подход Итеративный подход заключается в повторении операций для улучшения результатов предыдущего этапа (итерации)
8. В этом примере совмещаются инкрементальный и итеративный подходы Итеграция подходов
9. Классическое проектное управление («водопад») основано на последовательности выполнения этапов работ и передаче заказчику готового продукта в
10. Классический подход Agile Поставка ценности (работающего результата) Проверка гипотез Планирование Стиль менеджмента, руководства Происходит в конце
11. Классический подход Agile Отношение к изменениям Тип мышления, отношений Метрики проекта Как правило имеет негативный характер
12. Классический подход Agile Наличие руководств, методик Область эффективного применения Хорошо структурированы, детально описаны (PMBoK, PRINCE2). Отраслевые
13. Феномен гибридных методологий проектного управления — следствие конкуренции между гибкими и классическими методами Гибрид методов «Гибрид»
14. WBS используется для планирования высокоуровневой дорожной карты проекта, Гибрид методов В гибридном методе используется классический метод
15. Компоненты #1 #2 #3 #n 1-й повтор 2-й повтор 3-й повтор
16. История появления Agile 02 Вопрос
17. Software engineering - менеджмента разработки программ Первое электронное устройство, в названии которого было слово «computer», это
18. Заказчик Филиал: Или кончились деньги Или кончилось терпение Fix Хватит, больше не надо Fix Fix Fix
19. Проекты всегда превышали бюджеты Реализация проекта всегда превышала оговоренные сроки Итоговое ПО неэффективно решало возложенную на
20. В исходной «каскадной модели» стадии шли в таком порядке: Определение требований Проектирование Конструирование (также «реализация» либо
21. На первом этапе делалась самая простая реализация, которая доводилась до стадии внутреннего тестирования, на основе выявленных
22. Этот итеративный подход позволял использовать наработки первого этапа и получить гораздо более качественное ПО, отражающее потребности
23. Время Это дает возможность разным специалистам раньше получить обратную связь и внести корректировки Модификация «каскадного подхода»
24. Waterfall with Subprojects Модуль 1 Модуль 2 Модуль 3 Проектирование Разработка Тестирование Проектирование Разработка Тестирование Проектирование
25. Компания IBM официально перешла к политике разделения продаж «железа» и софта Разрастающийся программный кризис Во всей
26. Софтверный рынок X2 раза каждые 3 года
27. В 1971 году резко изменился и рынок «железа», в связи с появлением первого микропроцессора Intel 4004.
28. Итеративно-инкрементальная модель По итогам каждой итерации происходит обновление требований на основе оценки и эксплуатации новой версии
29. Важным также было появление в 1985 году «Спиральной модели» Барри Боэма. Она была универсальная, но довольно
30. 1. Determine Objectives 2. Identify $ resolve risks 3. Development $ Test 4. Plan the next
31. Цикл Шухарта (PDCA) Act -Выбираем изменение -Решение о следующем шаге Plan -Цель -Гипотеза -План действий Check
32. В 1986 году были представлены результаты исследований успешного опыта быстрого создания принципиально новых продуктов, на примере
33. Туре А - Каскадный процесс. Специалисты работают изолированно Туре В - Интеграция в точке передачи эстафеты
34. 40млн. компьютеров Рост продаж основных игроков рынка составил 20млн. компьютеров X8 раз за 10 лет
35. V-Model (Verification and Validation Model) Acceptance Testing Requirements Analysis System Design System Testing High-Level Design Integration
36. Спиральную модель V-Модель PRINCE2 другие, основанные на Waterfa К «тяжеловесным» моделям и подходам относили 8
37. К легковесным методам причисляли следующие: Crystal Clear Extreme Programming (XP) Rapid Application Development (RAD) Dynamic Systems
38. Параллельно со всем этим, развивались методы в концепции управления качеством (quality management) Основным документом стал Agile-манифест,
39. Четыре основные ценности: Люди и взаимодействие важнее процессов и инструментов Рабочее программное обеспечение важнее всеобъемлющей документации
40. 03 Вопрос Что такое управление ИТ-проектом
41. Семейство гибких методологий буквально ворвалось на софтверную сцену и перевернуло все с ног на голову Мы
42. Мы всегда готовы к изменениям, так как понимаем, что мир вокруг нас меняется и то, что
43. Важнее Важнее Важнее Важнее
44. Наш высший приоритет – это удовлетворение заказчика с помощью частых и непрерывных поставок продукта Мы принимаем
45. Успешные проекты строятся мотивированными людьми Самый эффективный метод взаимодействия и обмена информацией – это личная беседа
46. Команда должна постоянно искать способы стать эффективнее путем настройки и адаптации своих процессов Простота необходима как
47. Требования потенциальных пользователей Скрам-мастер Диаграмма сгорания задач Ежедневное совещание (скрам) Каждые 24 часа 1-4 недели Спринт
48. Владелец продукта – человек отвечающий за требования и их приоритеты, работая с заинтересованными лицами Скрам-мастер –
49. Экстремальное программирование Управленческие практики Игра в планирование Частые небольшие релизы Заказчик всегда рядом 40-часовая рабочая Коллективное
50. Канбан – это высокоадаптивный инструмент, который требует от команды, решившей использовать его, соответствующего уровня самоорганизации и
51. Пул Очередь Выполнение Проверка Готово Проект 1 Проект 2 Проект 3 Проект 4 Специалист 1 Специалист
52. Scrum вовсе не методология, это гибкий управленческий фреймворк Scrum используют не только для разработки ПО, он
53. Владелец продукта (Product Оwner, менеджер продукта) – это член команды, ответственный за максимизацию ценности продукта и
54. Скрам-мастер (Scrum Master) – член команды, который дополнительно отвечает за процессы, координацию работы и поддержание социальной
55. Что будет сделано к следующему скрам-митингу? Спринт – это ограниченная по времени итерация, которая является контейнером
56. В долгосрочном плане ретроспективы (или сокращенно «ретро») являются самой важной практикой Scrum, ведь именно они позволяют
57. Инкремент продукта – новая функциональность продукта, созданная во время спринта В Scrum также определены три артефакта
58. Управление проектом с Agile 04 Вопрос
59. Практика анализа персон пришла в управление продуктами из практик User Experience (опыт использования) Story Mapping (стори
60. 2.ПРОБЛЕМА 1-3 ключевых проблемы существующие альтернативы Список того, как эти проблемы уже решаются сегодня 7. СТРУКТУРА
61. Верхний слой подзадач представляет собой простейшую возможную реализацию функционала и обычно включается в первый релиз. Подзадачи,
62. Время Важность
63. Уникальный числовой идентификатор истории – обычно совпадает с идентификатором истории пользователя из трекера, которым пользуется команда
64. Подробное описание – текстовое и графическое описание истории пользователя Демонстрация – достаточно подробный сценарий, позволяющий провести
65. Как вы отнесетесь к отсутствию данной функциональности в продукте? Таким образом, можно выделить три типа функций
66. Закон Мерфи: «Если есть несколько способов понять задачу, то кто-то обязательно поймет ее неправильно» Английская буква
67. В соответствии с навыками и знаниями человека задачи можно категоризировать следующим образом: Недостижимые Труднодостижимые Достижимые Легкодостижимые
68. «Любая работа увеличивается в объеме, чтобы заполнить все отпущенное на нее время» Срочность целей тесно связана
69. Команда – это небольшая группа людей, взаимодополняющих и взаимозаменяющих друг друга, которые собраны для совместного решения
70. Фокусирование на результате Формирование Бурление Нормализация Функционирование Расформирование Фокусирование на отношениях
71. Этап Быстрый переход Средний переход Долгий переход Формирование Бурление Нормализация Функционирование Расформирование 2-й спринт 3-й спринт
72. Поддерживающие поведение Директивное поведение Высокий Низкий Высокий
73. Команды уровня 1 Командам данного уровня требуется предписывающий стиль лидерства. Лидер должен точно указывать, что команде
74. Покер-планирование (Planning poker) – консенсусная относительная оценка историй пользователей командой. Этот вид оценки не входит в
75. Покер-планирование проводится следующим образом Каждому участнику раздается колода карт с числовыми весами для оценки требований Начинается
76. Анализ производится путем сравнения реального графика с идеальным: если реальный график выше идеального, значит, команда отстает
77. недооценивание и реализация рисков (обычно технологических) Обратной ситуацией является опережение плана Самые распространенные причины следующие: серьезная
78. Согласно теории X, люди работают, только чтобы получать зарплату Теория Y гласит, что люди в принципе
79. Задача классического управления проектами – сделать проект в срок, в рамках бюджета, полностью реализовав функционал и
80. На данном этапе очень важно объяснить заказчику, что он сможет: Первый вопрос, который обычно возникает, –
81. Регулировать сроки и стоимость работ по проектам за счет возможности остановить проект после любого спринта Каждые
82. Видение проекта - краткий документ описывает, что представляет собой продукт, какой будет его аудиторией, основные фазы
83. В самом простом случае клиентов можно разделить на три группы: нелояльные, средние и лояльные Программа-минимум –
84. Самый гибкий вариант – сделать доску с рисками и отслеживать их жизненный цикл Худший вариант –
85. Анализ и внедрение проекта с Agile 05 Вопрос
86. красный – пишем неработающий тест зеленый – минимальными усилиями заставляем тест работать рефакторинг – устраняем дублирования
87. Простой код – это самый тривиальный код, в котором сложно допустить ошибки и который фактически не
88. Рефакторинг – это изменения исходного кода без изменения функциональности для улучшения внутреннего качества (простота кода, гибкость
89. Коллективное владение кодом обеспечивает многофункциональность самих участников команды и позволяет реализовывать это важное свойство Scrum Фиксированная
90. UML-диаграммы – это не конечный продукт, пользователям он не принесет ценность UML-диаграммы быстро теряют актуальность при
91. ICONIX – это методология разработки программного обеспечения, сфокусированная на анализе требований и моделировании В рамках ICONIX
92. UML ICONIX Диаграмма взаимодействия Диаграмма пакетов Диаграмма активности Диаграмма компонентов Диаграмма вариантов использования Диаграмма классов Диаграмма
93. Плюсы и минусы работы в Scrum в Канбане меняются местами: здесь аналитик работает наравне со всеми
94. Организационная структура (оргструктура) – это способ упорядочить сотрудников организации для достижения ее целей. Прежде всего, оргструктура
95. Виды оргструктур Дивизионная оргструктура Функциональная оргструктура Командная (проектная) оргструктура Матричная оргструктура Основная цель скрам-митинга – координация
96. В качестве базовой структуры митинга можно предложить каждому скрам-мастеру ответить на следующие вопросы: Что было сделано
97. Следующим уровнем масштабирования является Scrum of Scrum of Scrum Для масштабирования деятельности продуктовых команд владельцы продуктов
98. У тестировщиков в Scrum есть две основные функции: регрессионное тестирование функционала с предыдущих спринтов приемочное тестирование
99. У тестировщиков есть пять основных активностей: планирование итерации автоматизация приемочного тестирования тестирование историй пользователей регрессионное тестирование
100. Принципы бережливого производства можно применить и в разработке программного обеспечения Уменьшение потерь Фокусировка на обучении Встроенное
101. На практике кайзен – это стратегия постоянного улучшения путем небольших изменений. Для реализации такого подхода необходимо
102. Карта потока создания ценности (Value Stream Mapping) – инструмент, который отображает стадии производственного процесса и время
103. На ней также отображаются проблемы, но они заранее сгруппированы по нескольким областям, например, таким: методология требования
104. Контрольные карты - данный инструмент используется для выявления несистематических отклонений и устранения вариаций Средние значение количества
105. Диаграмма Парето - этот инструмент позволяет выявить модули, которые содержат определенный процент дефектов Именно на эти
106. Crystal Clear – это легковесная гибкая методология, созданная Алистером Кокберном Crystal Clear использует семь методов/практик, три
107. Методология DSDM (Dynamic Systems Development Method – метод разработки динамических систем) основана на подходе RAD (Rapid
108. Agile Unified Process (AUP) – упрощенная версия IBM Rational Unified Process, созданная Скоттом Амблером (Scott Ambler)
109. Цикл Деминга (PDCA-цикл) Традиционным методом в данном случае является цикл Деминга, который состоит из четырех шагов
110. План внедрения Agile за 14 дней состоит из трех частей Подготовка компании к трансформации Первый релиз
111. Неделя № 1 (подготовка к трансформации) Неделя № 2 (нулевой спринт) Неделя № 3 (старт первого
112. Применение Agile на практике 06 Вопрос
113. Новые правила и роли в HR Традиционный менеджмент Фокус на контроле и согласованности Исполнительность, порядок, контроль
114. Три направления, где Agile работает эффективно: Agile в разработке программного обеспечения (софт, сайты, моб. приложения) Agile
115. Такие методологии позволяют: повышать навыки самообразования и саморазвития улучшать мотивацию к обучению развивать умение делать осознанный
116. Традиционный подход в обучении Agile-подходы в образовании Период обучения Формат обучения Форма организации Форма восприятия информации
117. Заинтересованные стороны Agile Государственное управление и управление, основанное на данных Государственные услуги для граждан Работа отраслей
118. Текст Текст Чем более масштабен цифровой проект и чем сильнее трансформационный эффект, тем больше заинтересованных сторон
119. Создание суперсервисов — это значительный прорыв в отношениях государства и граждан, новый подход, который сопоставим с
120. В подходе к созданию суперсервисов заложены основные принципы, отвечающие философии гибких подходов: проектирование без привязки к
121. * По результатам опроса в телеграм-канале Aglie Thinking
122. Согласно исследованиям 2021 года, 95% респондентов заявили, что их компании частично либо полностью используют Agile методологии
124. Скачать презентацию

Слайд 2

Вопросы темы:
Сравнение гибких методов с традиционным подходом
История появления Agile
Что такое управление

ИТ-проектом

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

Слайд 3

Вопросы темы:
Анализ и внедрение проекта с Agile
Применение Agile на практике

Слайд 4

Сравнение гибких методов с традиционным подходом
01
Вопрос

Слайд 5

Принципы
методов

Слайд 6

Начнем с инкрементального подхода – это быстрое создание продукта с ограниченным,

но работающим функционалом

Инкрементальный подход

Слайд 7

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

предыдущего этапа (итерации)

Слайд 8

В этом примере совмещаются инкрементальный и итеративный подходы
Итеграция подходов

Слайд 9

Классическое проектное управление («водопад») основано на последовательности выполнения этапов работ и

передаче заказчику готового продукта в конце проекта

Agile предлагает выстроить работу в другом формате: короткими спринтами поставлять заказчику продукт, который уже имеет для него ценность, пусть и ограниченную, и быстро получать обратную связь для корректировки направления работы

Выводы

Слайд 10

Классический подход
Agile
Поставка ценности (работающего результата)
Проверка гипотез
Планирование
Стиль менеджмента, руководства
Происходит в конце проекта
Осуществляется

по мере реализации проекта в виде работающих элементов продукта. Использует

Детальное, до конца проекта. Для оценки сроков используется Метод критического пути. В проектах с высокой неопределенностью используется метод «набегающей волны»

Вертикаль управления: Управляющий комитет -> Куратор, Заказчик -> Руководитель проекта

Выполняется командой в ходе проекта для улучшения продукта. Часть гипотез может быть признана несостоятельными

Эмпирическое, на основе исторических данных о реализованных элементов продукта

Самоорганизация внутри команды. Плоская команда без внутренней иерархии

Характеристика

Как правило, выполняется на предпроектной стадии, до старта проекта

Слайд 11

Классический подход
Agile
Отношение к изменениям
Тип мышления, отношений
Метрики проекта
Как правило имеет негативный характер

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

Изменения являются частью процесса разработки. Источником изменений является в т.ч. более лучшее понимание продукта на основе опыта

% реализации, отклонение от плана, Метод освоенного объема, прогнозная дата завершения проекта
В проектах с высокой неопределенностью используется метод «набегающей волны»

Необходим гибкий mindset для успешной работы в среде с высокой неопределенностью

Диаграмма сгорания задач (Burn down chart), Накопительная диаграмма реализованных функций (Burn Up Chart), Дата выхода на рынок (Time to market)

Характеристика

Как правило определяется культурой организации, зачастую фиксированный mindset

Слайд 12

Классический подход
Agile
Наличие руководств, методик
Область эффективного применения
Хорошо структурированы, детально описаны (PMBoK, PRINCE2).

Отраслевые стандарты и практики

Верхнеуровневые фреймворки (например, Скрам). Множество отдельных практик (ежедневное собрание, ретроспектива, спринт и др.)

«Сложные системы» по модели Киневин (Cynefin) – много работ, агентов (стейкхолдеров). Продукт и требования к нему известны, состав работ может быть описан и зафиксирован. Границы проекта фиксированы.
«Запутанные системы» по модели Киневин (Cynefin) – не знаем продукт и/или процесс его создания. Состав работ проекта не определен. Границы проекта размыты

Характеристика

Слайд 13

Феномен гибридных методологий проектного управления — следствие конкуренции между гибкими и

классическими методами

Гибрид методов

«Гибрид» включает в себя все принципы и гибких, и традиционных методов

Слайд 14

WBS используется для планирования высокоуровневой дорожной карты проекта,
Гибрид методов
В гибридном

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

Это нужно для построения иерархической структуры работ проекта — ИСР (Work Breakdown Structure, WBS)

Agile — для разработки, уточнения и выпуска каждого компонента и подкомпонента продукта

Слайд 15

Компоненты
#1
#2
#3
#n
1-й
повтор
2-й
повтор
3-й
повтор

Слайд 16

История появления Agile
02
Вопрос

Слайд 17

Software engineering - менеджмента разработки программ
Первое электронное устройство, в названии которого

было слово «computer», это ENIAC (Electronic Numerical Integrator and Computer), который разрабатывался в 1942–1945 годах и работал 10 лет, до 1955 года

Начало массовой разработке ПО было положено в 1957 году, когда компания IBM презентовала первый язык программирования высокого уровня Fortran (Formula Translator)

Software engineering

Слайд 18

Заказчик
Филиал:
Или кончились деньги
Или кончилось терпение
Fix
Хватит, больше не надо
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Code&Fix
Программист

Слайд 19

Проекты всегда превышали бюджеты
Реализация проекта всегда превышала оговоренные сроки
Итоговое ПО неэффективно

решало возложенную на него задачу (тормозило, нестабильно работало и т.д.)

Итоговый результат был низкого качества

Проекты были неуправляемыми, а код было сложно поддерживать

Разработке не было видно конца, и в конечном итоге, заказанное ПО никуда не поставлялось, нигде не разворачивалось и не использовалось

Проблемы проектов

Слайд 20

В исходной «каскадной модели» стадии шли в таком порядке:
Определение требований
Проектирование
Конструирование (также

«реализация» либо «кодирование»)

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

Инсталляция

Поддержка

Waterfall

Каскадная модель

REQUIREMENTS ANALYSIS

DESIGN

NIMPLEMENTATION

TESTING

MAINTENANCE

Слайд 21

На первом этапе делалась самая простая реализация, которая доводилась до стадии

внутреннего тестирования, на основе выявленных ограничений, делалось повторное уточнение исходных требований, новая стадия проектирования и все последующие этапы

Слайд 22

Этот итеративный подход позволял использовать наработки первого этапа и получить гораздо

более качественное ПО, отражающее потребности Заказчика

И только результаты второй итерации поставлялись заказчику для использования

Слайд 23

Время
Это дает возможность разным специалистам раньше получить обратную связь и внести

корректировки

Модификация «каскадного подхода» предполагающее перекрытие этапов по времени

Sashimi

Слайд 24

Waterfall with Subprojects
Модуль 1
Модуль 2
Модуль 3
Проектирование
Разработка
Тестирование
Проектирование
Разработка
Тестирование
Проектирование
Разработка
Тестирование
Время

Слайд 25

Компания IBM официально перешла к политике разделения продаж «железа» и софта
Разрастающийся

программный кризис

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

Компания IBM официально перешла к политике разделения продаж «железа» и софта

Слайд 26

Софтверный рынок
X2 раза
каждые 3 года

Слайд 27

В 1971 году резко изменился и рынок «железа», в связи с

появлением первого микропроцессора Intel 4004. Это открыло эру «микрокомпьютеров», а затем и персональных компьютеров

Слайд 28

Итеративно-инкрементальная модель
По итогам каждой итерации происходит обновление требований на основе оценки

и эксплуатации новой версии продукта

Итерация 1

Итерация 2

Итерация N

Время

Слайд 29

Важным также было появление в 1985 году «Спиральной модели» Барри Боэма.

Она была универсальная, но довольно сложная для понимания

По итогу каждой итерации (витка) мы должны получить готовый протестированный прототип, который дополняет существующий продукт

Эта модель хорошо работает в сложных, высокорисковых проектах, где важно получить гарантированный, качественный результат, и чрезвычайно высока цена ошибки

Слайд 30

1. Determine Objectives
2. Identify $ resolve risks
3. Development $ Test
4. Plan

the next iteration

Cost

Prototype 2

Prototype 1

Operational Prototype

Requirements plan

Concept of Operation

Development
Plan

Test plan

Verification & Validation

Implementation

Test

Integration

Code

Detailed Design

Concept of Requirements

Review

Слайд 31

Цикл Шухарта (PDCA)
Act
-Выбираем
изменение
-Решение
о следующем шаге
Plan
-Цель
-Гипотеза
-План действий
Check
Study
-Анализ
данных
-Проверка
Гипотезы
Do
-Действуем
по плану
-Собираем
данные

Слайд 32

В 1986 году были представлены результаты исследований успешного опыта быстрого создания

принципиально новых продуктов, на примере таких компаний как Honda, Xerox, Canon, Epson и других

Таким образом, к началу 90-х годов XX века были изучены и опробованы два ключевых аспекта, которые лягут в основу Agile:
итеративно-инкрементальный подход
командная работа

Слайд 33

Туре А - Каскадный
процесс. Специалисты
работают изолированно
Туре В - Интеграция в точке

передачи эстафеты от этапа
к этапу
Туре С - Процесс с перекрытием этапов.
Высокое вовлечение всех специалистов во все этапы работы

EXHIBIT 1

Sequential (A) vs. overlapping (B and C) phases of development

Туре А

Phase

Туре B

Phase

Туре C

Phase

Туре C

Туре А

Слайд 34

40млн. компьютеров
Рост продаж основных игроков рынка составил
20млн. компьютеров
X8 раз
за

10 лет

Слайд 35

V-Model (Verification and Validation Model)
Acceptance
Testing
Requirements
Analysis
System Design
System
Testing
High-Level
Design
Integration
Testing
Unit
Testing
Low-Level
Design
Implementation
Code Review
Static Code
Analysis
Review System Design
Review Architectural
Design
Review

Low-Level
Design

Слайд 36

Спиральную модель
V-Модель
PRINCE2
другие, основанные на Waterfa
К «тяжеловесным» моделям и подходам относили
8

Слайд 37

К легковесным методам причисляли следующие:
Crystal Clear
Extreme Programming (XP)
Rapid Application Development

(RAD)

Dynamic Systems Development Method (DSDM)

ICONIX

Scrum

Adaptive Software Development (ASD)

Feature Driven Development (FDD)

Слайд 38

Параллельно со всем этим, развивались методы в концепции управления качеством (quality

management)

Основным документом стал Agile-манифест, являвшийся призывом к индустрии разработки программного обеспечения (software industry), и провозгласивший новую парадигму менеджмента разработки

Слайд 39

Четыре основные ценности:
Люди и взаимодействие важнее процессов и инструментов
Рабочее программное обеспечение

важнее всеобъемлющей документации
Сотрудничество с клиентами важнее переговоров по контракту
Реагирование на изменения важнее следования плану

Кроме того, появилось направление Agile Project Management, и PMI-сертификация

Слайд 40

03
Вопрос
Что такое управление ИТ-проектом

Слайд 41

Семейство гибких методологий буквально ворвалось на софтверную сцену и перевернуло все

с ног на голову

Мы стали сосредотачиваться на людях и улучшении коммуникаций между ними вместо выстраивания сверхжестких процессов

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

Слайд 42

Мы всегда готовы к изменениям, так как понимаем, что мир вокруг

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

Мы больше не заставляем заказчика расписываться кровью, ограничивая его жесткими и неудобными условиями договоров, а строим действительно партнерские отношения и выясняем, чего он хочет и что ему нужно

Слайд 43

Важнее
Важнее
Важнее
Важнее

Слайд 44

Наш высший приоритет – это удовлетворение заказчика с помощью частых и

непрерывных поставок продукта

Мы принимаем изменения в требованиях даже на поздних этапах реализации проекта

Гибкие процессы приветствуют изменения, что является конкурентным преимуществом для заказчика

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

Слайд 45

Успешные проекты строятся мотивированными людьми
Самый эффективный метод взаимодействия и обмена информацией

– это личная беседа

Рабочее программное обеспечение – главная мера прогресса проекта

Гибкие процессы способствуют непрерывному развитию

Постоянное внимание к техническому совершенству и качественной архитектуре способствует гибкости

Представители бизнеса и команда разработки должны работать вместе над проектом

Слайд 46

Команда должна постоянно искать способы стать эффективнее путем настройки и адаптации

своих процессов

Простота необходима как искусство максимизации работы, которую не следует делать

Лучшая архитектура, требования и дизайн создаются в самоорганизующихся командах

Слайд 47

Требования потенциальных пользователей
Скрам-мастер
Диаграмма сгорания задач
Ежедневное совещание (скрам)
Каждые 24 часа
1-4 недели Спринт
Обзор

итогов спринта

Готовое ПО

Product Owner
(представитель заказчика)

Product Backlog
(техническое задание)

Sprint Backlog (техническое задание на спринт)

Ретроспективное совещание

Список требований по приоритетам

Команда разработчиков

Планирование спринта

Слайд 48

Владелец продукта – человек отвечающий за требования и их приоритеты, работая

с заинтересованными лицами

Скрам-мастер – человек отвечающий за соблюдение процессов в команде и конструктивную атмосферу

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

Команда согласно своей скорости набирает задачи на неизменяемую по времени итерацию – СПРИНТ

Определение

Слайд 49

Экстремальное программирование
Управленческие практики
Игра в планирование
Частые небольшие релизы
Заказчик всегда

рядом
40-часовая рабочая
Коллективное владение кодом

Инженерные практики

Непрерывная интеграция
Парное программирование
Разработка через тестирование
Рефакторинг
Простота
Метафора системы
Стандарт кодирования

Слайд 50

Канбан – это высокоадаптивный инструмент, который требует от команды, решившей использовать

его, соответствующего уровня самоорганизации и дисциплины
Визуализируйте производственный процесс
Ограничивайте количество незавершенной работы (WIP, Work In Progress)
Оптимизируйте процесс

Канбан

Слайд 51

Пул
Очередь
Выполнение
Проверка
Готово
Проект 1
Проект 2
Проект 3
Проект 4
Специалист 1
Специалист 2
Специалист 3
Специалист 4
Специалист 5
Специалист

Слайд 52

Scrum вовсе не методология, это гибкий управленческий фреймворк
Scrum используют не

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

Scrum обычно дополняют инженерными практиками из других гибких методологий

Роли

Владелец продукта
Скрам-мастер
Команда

Артефакты

Бэклог продукта
Бэклог спринта
Инкремент продукта

Процессы

Планирование спринта
Обзор спринта
Ретроспектива
Ежедневный Скрам

Слайд 53

Владелец продукта (Product Оwner, менеджер продукта) – это член команды, ответственный

за максимизацию ценности продукта и управление его журналом пожеланий

Слайд 54

Скрам-мастер (Scrum Master) – член команды, который дополнительно отвечает за процессы,

координацию работы и поддержание социальной атмосферы в команде

Команда разработки (Development Team) – это многофункциональная и самоорганизующаяся группа специалистов, которая создает инкремент продукта

Слайд 55

Что будет сделано к следующему скрам-митингу?
Спринт – это ограниченная по

времени итерация, которая является контейнером для других процессов в Scrum. В конце спринта создается потенциально готовый к поставке продукт и начинается следующий спринт
Спринт длится от одной до четырех недель

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

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

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

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

Sprint
1-4 Weeks

Слайд 56

В долгосрочном плане ретроспективы (или сокращенно «ретро») являются самой важной практикой

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

Обычно ретроспектива занимает от 30 минут до четырех часов и ее продолжительность зависит от таких факторов, как:
длина спринта
размер команды
наличие проблем

Открытие

Сбор мнений

Обсуждение
и генерации идей

Составление плана действий

Закрытие

Слайд 57

Инкремент продукта – новая функциональность продукта, созданная во время спринта
В Scrum

также определены три артефакта
Журнал пожеланий продукта (Product Backlog) – фактически приоритезированный список требований. Обычно он состоит из бизнес-требований, которые приносят конкретную бизнес-пользу и называются элементами журнала пожеланий

Журнал пожеланий спринта (Sprint Backlog) – часть журнала пожеланий продукта с самой высокой важностью и суммарной оценкой, не превышающей скорости команды, отобранная для спринта

Слайд 58

Управление проектом с Agile
04
Вопрос

Слайд 59

Практика анализа персон пришла в управление продуктами из практик User Experience

(опыт использования)

Story Mapping (стори маппинг) – способ визуализации и планирования функционала

Слайд 60

2.ПРОБЛЕМА
1-3 ключевых
проблемы
существующие альтернативы
Список того, как эти проблемы
уже решаются
сегодня
7. СТРУКТУРА ИЗДЕРЖЕК
Список

постоянных и переменных издержек

4. РЕШЕНИЕ
Возможные решения
для каждой проблемы

3. УНИКАЛЬНАЯ
ЦЕННОСТЬ
Простое четкое
сообщение, которое отличает вас от конкурентов
и привлекает внимание

8. КЛЮЧЕВЫЕ метрики
Список ключевых цифр,
которые говорят о том,
как обстоит бизнес

9. СКРЫТОЕ ПРЕИМУЩЕСТВО
Ваша особенность,
которую сложно купить
или подделать

1. СЕГМНТЫ ПОТРЕБИТЕЛЕЙ
Список целевых
покупателей
и пользователей

5. КАНАЛЫ
Списки входящих
и исходящих каналов
на пути к вашим
клиентам

конкуренты
Список товаров/услуг,
которыми можно заменить ваш
продукт (в том числе согласно
концепции JTBD)

6. ПОТОКИ ПРИБЫЛИ
Список источников прибыли

ранние последователи
Список характеристик
идеального потребителя

Слайд 61

Верхний слой подзадач представляет собой простейшую возможную реализацию функционала и обычно

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

Подзадачи

Слайд 62

Время
Важность

Слайд 63

Уникальный числовой идентификатор истории – обычно совпадает с идентификатором истории пользователя

из трекера, которым пользуется команда
Название истории пользователя – короткое (примерно до десяти слов) описание функционала с точки зрения пользователя, сформулированное в виде тройки «роль – действие – цель»
Важность – уникальный числовой приоритет истории пользователя. Чем она выше, тем раньше данную историю необходимо сделать
Оценка – числовая относительная оценка истории пользователя по специальной шкале

Слайд 64

Подробное описание – текстовое и графическое описание истории пользователя
Демонстрация –

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

Слайд 65

Как вы отнесетесь к отсутствию данной функциональности в продукте?
Таким образом,

можно выделить три типа функций продукта
Обязательные функции
Линейные функции
Привлекательные функции

Задаем по каждой истории пользователю два вопроса.

Как вы отнесетесь к наличию данной функциональности в продукте?

Слайд 66

Закон Мерфи: «Если есть несколько способов понять задачу, то кто-то обязательно

поймет ее неправильно»

Английская
буква

Английское
слово

Русский
перевод

Что это означает?

Specific

Measurable

Achievable

Relevan

Time-bound

Конкретная

Измеримая

Достижимая

Уместная

Ограниченная
во времени

Цель должна быть конкретной и четко сформулированной

Цель должна иметь количественные или качественные параметры, по которым ее можно оценить

Цель должна быть реалистичной и достижимой
в тех временных рамках, которые для нее
отводятся

Цель должна быть адекватной и согласованной
с другими целями

Цель должна быть ограничена временными
рамками и иметь определенный срок
достижения

Слайд 67

В соответствии с навыками и знаниями человека задачи можно категоризировать следующим

образом:
Недостижимые
Труднодостижимые
Достижимые
Легкодостижимые

Общий вывод можно сделать следующий: необходимо чередовать достижимые и труднодостижимые задачи

Слайд 68

«Любая работа увеличивается в объеме, чтобы заполнить все отпущенное на нее

время»

Срочность целей тесно связана с достижимостью: чем меньше срок исполнения задачи, тем более она труднодостижимая, что надо учитывать при постановке задач

Концепция ограничения по срокам встроена в Scrum: итерации всегда фиксированного размера и команда четко знает, когда будет проводиться демонстрация результатов спринта

Закон Паркинсона

Слайд 69

Команда – это небольшая группа людей, взаимодополняющих и взаимозаменяющих друг друга,

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

В своем развитии команды проходят несколько этапов
Формирование
Бурление
Нормализация
Функционирование
Расформирование

Слайд 70

Фокусирование на результате
Формирование
Бурление
Нормализация
Функционирование
Расформирование
Фокусирование на отношениях

Слайд 71

Этап
Быстрый переход
Средний переход
Долгий переход
Формирование
Бурление
Нормализация
Функционирование
Расформирование
2-й спринт
3-й спринт
4-й спринт
5-й спринт
Завершение проекта
4-й спринт
6-й спринт
8-й

спринт

10-й спринт

4-й спринт

8-й спринт

12-й спринт

16-й спринт

Во-первых, команда не может сама себе ставить цели, они всегда приходят извне

Во-вторых, команда не определяет состав сама, она опять же формируется сверху

Слайд 72

Поддерживающие поведение
Директивное поведение
Высокий
Низкий
Высокий

Слайд 73

Команды уровня 1
Командам данного уровня требуется предписывающий стиль лидерства. Лидер

должен точно указывать, что команде необходимо сделать
Команды уровня 2
Команды этого уровня не могут стать гибкими, но хотят это сделать. Таким командам требуется продающий стиль лидерства
Команды уровня 3
Команды данного уровня могут стать гибкими, но не хотят этого. Такой команде требуется участвующий стиль лидерства
Команды уровня 4
Лидер не должен помогать принимать решения команде, но может помогать в выборе методов поиска решений

Слайд 74

Покер-планирование (Planning poker) – консенсусная относительная оценка историй пользователей командой. Этот

вид оценки не входит в классический Scrum, но является паттерном для оценки историй пользователей

Слайд 75

Покер-планирование проводится следующим образом
Каждому участнику раздается колода карт с числовыми весами

для оценки требований

Начинается обсуждение и оценка очередной истории пользователя: она зачитывается, команда задает вопросы владельцу продукта, выясняет детали, если это необходимо

Каждый член команды дает свою оценку, кладя карту рубашкой вверх

После того как все члены команды сделали оценку, все карты переворачиваются и оценки сверяются

Если оценки всех участников одинаковы, консенсусная оценка заносится в журнал пожеланий; в противном случае начинается повторное обсуждение и проводится второй раунд

Слайд 76

Анализ производится путем сравнения реального графика с идеальным:
если реальный

график выше идеального, значит, команда отстает от плана
если реальный график ниже идеального – команда опережает план

Оставшиеся часы/story points

Даты спринта

Слайд 77

недооценивание и реализация рисков (обычно технологических)
Обратной ситуацией является опережение плана
Самые распространенные

причины следующие:

серьезная ошибка в планировании

болезнь или иная причина отсутствия одного или нескольких членов команды

Слайд 78

Согласно теории X, люди работают, только чтобы получать зарплату
Теория Y гласит,

что люди в принципе высокомотивированы на достижение результатов и сама работа приносит им удовольствие

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

Для работы в рамках Scrum команда должна состоять в основном из людей, которые больше соответствуют теории Y, иначе команда не будет самоорганизованной и эффективной

Слайд 79

Задача классического управления проектами – сделать проект в срок, в рамках

бюджета, полностью реализовав функционал и соблюдая установленные критерии качества

Метод PERT (Program (Project) Evaluation and Review Technique), или метод оценки по трем точкам

оптимистичной (Мин)
вероятной (Сред)
пессимистичной (Макс)

Вероятная дата завершения

Отклонение

(

Мин

Сред

Макс

)

Метод заключается в получении трех оценок:

(

Макс

–

Мин

)

Слайд 80

На данном этапе очень важно объяснить заказчику, что он сможет:
Первый вопрос,

который обычно возникает, – как продать Scrum клиенту

Особенности Scrum

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

Слайд 81

Регулировать сроки и стоимость работ по проектам за счет возможности остановить

проект после любого спринта

Каждые две недели менять требования, чтобы изменения в бизнесе отражались и в ПО

Второй вопрос, который появляется сразу после первого, – как отразить процесс в контракте

Особенности Scrum

Слайд 82

Видение проекта - краткий документ описывает, что представляет собой продукт, какой

будет его аудиторией, основные фазы проекта, бизнес-модель для монетизации и т.д.

Обратная сторона медали – это выбор платформы для разработки и создания архитектуры

Слайд 83

В самом простом случае клиентов можно разделить на три группы: нелояльные,

средние и лояльные

Программа-минимум – это посещение заказчиком всех демонстраций

Программа-максимум – это присутствие представителя заказчика и на других мероприятиях

Слайд 84

Самый гибкий вариант – сделать доску с рисками и отслеживать их

жизненный цикл

Худший вариант – создать Excel-файл с рисками (в самом укромном уголке) и при провале проекта сказать: «Этот риск у меня есть в реестре под номером 37»

Выявление

Анализ и приоритезация

Планирование

Мониторинг

Слайд 85

Анализ и внедрение проекта с Agile
05
Вопрос

Слайд 86

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

– устраняем дублирования и приводим код в порядок

Слайд 87

Простой код – это самый тривиальный код, в котором сложно допустить

ошибки и который фактически не требует тестирования

Сложный код – достаточно запутанный код, но для него нужны тесты

Алгоритмы – это код, реализующий разного рода алгоритмы и бизнес-логику

Связующий код – это код с максимальным количеством зависимостей, что сильно повышает
стоимость поддержки модульных тестов для него

Слайд 88

Рефакторинг – это изменения исходного кода без изменения функциональности для улучшения

внутреннего качества (простота кода, гибкость архитектуры и т. д.)

Формальные инспекции кода не относятся к экстремальному программированию, эту практику представляет парное программирование

Слайд 89

Коллективное владение кодом обеспечивает многофункциональность самих участников команды и позволяет реализовывать

это важное свойство Scrum

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

Слайд 90

UML-диаграммы – это не конечный продукт, пользователям он не принесет ценность
UML-диаграммы

быстро теряют актуальность при начале разработки
UML очень объемен (более десяти видов диаграмм, 900-страничное официальное руководство) и избыточен, так как часть диаграмм фактически дублируют друг друга
UML описывает систему слишком подробно, часть знаний можно хранить и передавать в устном виде либо в форме текста
UML неявно подразумевает водопадную модель разработки

UML

Слайд 91

ICONIX – это методология разработки программного обеспечения, сфокусированная на анализе требований

и моделировании
В рамках ICONIX используется подмножество UML для анализа требований:
диаграмма вариантов использования
диаграмма классов
диаграмма робастности
диаграмма последовательности

ICONIX – это методология анализа требований, основанная на прецедентах использования

ICONIX

Слайд 92

UML
ICONIX
Диаграмма
взаимодействия
Диаграмма
пакетов
Диаграмма
активности
Диаграмма
компонентов
Диаграмма
вариантов
использования
Диаграмма
классов
Диаграмма
последовательности
Диаграмма
размещения
Диаграмма
робастности
Диаграмма
компонентов
Диаграмма
объектов
Диаграмма
состояний

Слайд 93

Плюсы и минусы работы в Scrum в Канбане меняются местами: здесь

аналитик работает наравне со всеми членами команды в потоке задач. Обычно ему выделяют дополнительный столбец на доске

Важным элементом работы системного аналитика является создание прототипа

В рамках Scrum прототипы рекомендуется делать к конкретным историям пользователей в сочетании с текстовым описанием и диаграммами

Слайд 94

Организационная структура (оргструктура) – это способ упорядочить сотрудников организации для достижения

ее целей. Прежде всего, оргструктура создается и поддерживается для:
координации деятельности работников
обозначения границ ответственности

Слайд 95

Виды оргструктур
Дивизионная оргструктура
Функциональная оргструктура
Командная (проектная) оргструктура
Матричная оргструктура
Основная цель скрам-митинга –

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

Слайд 96

В качестве базовой структуры митинга можно предложить каждому скрам-мастеру ответить на

следующие вопросы:
Что было сделано с прошлого Scrum of Scrum?
Какие были проблемы?
Что будет сделано к следующему Scrum of Scrum?

Scrum of Scrum

Team 1

Team 2

Team 3

Слайд 97

Следующим уровнем масштабирования является Scrum of Scrum of Scrum
Для масштабирования деятельности

продуктовых команд владельцы продуктов (Product Owner, PO) проводят Meta Scrum под руководством главного владельца продукта (Chief Product Owner)

Слайд 98

У тестировщиков в Scrum есть две основные функции:
регрессионное тестирование
функционала с

предыдущих спринтов
приемочное тестирование спринтов и релизов

Количество тестировщиков определяется многими факторами:
количеством разработчиков
наличием автоматических приемочных тестов
наличием практики написания
модульных тестов разработчиками
общим качеством продукта

Слайд 99

У тестировщиков есть пять основных активностей:
планирование итерации
автоматизация приемочного тестирования
тестирование историй

пользователей
регрессионное тестирование
демонстрация

Слайд 100

Принципы бережливого производства можно применить и в разработке программного обеспечения
Уменьшение потерь

Фокусировка на обучении
Встроенное качество
Позднее принятие решений
Быстрая поставка
Уважение к людям
Оптимизация системы целиком

Слайд 101

На практике кайзен – это стратегия постоянного улучшения путем небольших изменений.

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

Фокус на клиентах
Непрерывные изменения
Открытое признание проблем
Создание сообществ
Управление проектами с помощью межфункциональных команд

Формирование поддерживающих взаимоотношений
Развитие самодисциплины
Информирование каждого сотрудника
Делегирование полномочий каждому сотруднику

Слайд 102

Карта потока создания ценности (Value Stream Mapping) – инструмент, который отображает

стадии производственного процесса и время между ними

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

Т ЦИКЛА - 3920 МИН: 3560 МИН - ПОЛЕЗНАЯ РАБОТА 360 МИН - ПОТЕРИ

график производства

Управление
производством

Передав-ливание

420 мин

30 мин

120 мин

240 мин

2700 мин

60 мин

260 мин

30 мин

60 мин

Слайд 103

На ней также отображаются проблемы, но они заранее сгруппированы по нескольким

областям, например, таким:
методология
требования
разработка
контроль качества

Рациональное планирование
операций и действий

Рабочее место
(среда)

Материал

Зонирование и компоновка
рабочего места наладчика

Качество ТУМ

Человек

Оборудование

Ручные операции

Квалификация

Мотивация, лояльность,
заинтересованность

Резерв запчастей

Нестандартное дооснащение
(самодельное)

Производительность
линии «Пастпак»

(один
производитель

Слайд 104

Контрольные карты - данный инструмент используется для выявления несистематических отклонений и

устранения вариаций

Средние значение
количества дефектов

Номер выборки

Слайд 105

Диаграмма Парето - этот инструмент позволяет выявить модули, которые содержат определенный

процент дефектов

Именно на эти модули стоит обратить внимание:
покрыть их дополнительно тестами
провести дополнительные инспекции кода

Слайд 106

Crystal Clear – это легковесная гибкая методология, созданная Алистером Кокберном
Crystal Clear

использует семь методов/практик, три из которых являются обязательными
Частая поставка продукта
Улучшения через рефлексию
Личные коммуникации
Чувство безопасности
Фокусировка
Простой доступ к экспертам
Качественное техническое окружение

Слайд 107

Методология DSDM (Dynamic Systems Development Method – метод разработки динамических систем)

основана на подходе RAD (Rapid Application Development – быстрая разработка приложений) и включает в себя три стадии:
Предпроектная стадия
Жизненный цикл проекта представляет собой реализации проекта и включает в себя пять этапов
Постпроектная стадия обеспечивает качественную эксплуатацию системы

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

Создание функциональной модели
Проектирование и разработка
Реализация

Слайд 108

Agile Unified Process (AUP) – упрощенная версия IBM Rational Unified Process,

созданная Скоттом Амблером (Scott Ambler) и состоящая из семи методов
Моделирование используется для понимания бизнес-требования и предметной области
Реализация
Тестирование
Размещение
Управление конфигурациями
Управление проектом
Среда

AUP

Слайд 109

Цикл Деминга (PDCA-цикл)
Традиционным методом в данном случае является цикл Деминга,

который состоит из четырех шагов
Plan (планирование). Производится анализ системы, вырабатываются возможные подходы к улучшениям, и определяются желаемые результаты
Do (исполнение). Решения, выработанные на предыдущем шаге, реализуются
Check (проверка). Производится анализ результатов, полученных на предыдущем шаге
Act (корректировка). Выполняются корректирующие действия для уменьшения отклонений от плана

PLAN

CHECK

ACT

Слайд 110

План внедрения Agile за 14 дней состоит из трех частей
Подготовка компании

к трансформации
Первый релиз – знакомство с основными элементами Scrum и Lean
Второй релиз – адаптация Agile к бизнесу компании

Слайд 111

Неделя № 1 (подготовка к трансформации)
Неделя № 2 (нулевой спринт)

Неделя № 3 (старт первого «калибровочного» спринта)
Неделя № 4 (завершение первого «калибровочного» спринта)
Неделя № 5 (старт второго спринта)
Неделя № 6 (завершение второго спринта)
Неделя № 7 (старт третьего спринта)

Неделя № 8 (завершение третьего спринта)
Неделя № 9 (старт четвертого спринта)
Неделя № 10 (завершение четвертого спринта)
Неделя № 11 (старт пятого спринта)
Неделя № 12 (завершение пятого спринта)
Неделя № 13 (старт «идеального» шестого спринта)
Неделя № 14 (завершение «идеального» шестого спринта)

Слайд 112

Применение Agile на практике
06
Вопрос

Слайд 113

Новые правила и роли в HR
Традиционный менеджмент
Фокус на контроле и согласованности
Исполнительность,

порядок, контроль

Работа HR: внедрять контроль, стандарты и системы для управления согласованностью и исполнением

Agile менеджмент

Фокус на скорости и пользователях

Адаптивность, инновационность, скорость. Работа HR: внедрять программы, системы и стратегии, которые поддерживают экспертизу, сотрудничество
и принятие решений

Слайд 114

Три направления, где Agile работает эффективно:
Agile в разработке программного обеспечения (софт, сайты,

моб. приложения)
Agile в маркетинге (в первую очередь в интернет-маркетинге)
Agile в управлении

Слайд 115

Такие методологии позволяют:
повышать навыки самообразования и саморазвития
улучшать мотивацию к обучению
развивать

умение делать осознанный выбор в профессии
разрабатывать траекторию собственного дальнейшего обучения
формировать ответственное отношение к учёбе
развивать навык саморефлексии и прогнозирования результатов
воспитывать целостное мировоззрение
получить опыт успешного взаимодействия с другими
развивать навыки общения и умение вести переговоры
развивать другие гибкие умения и навыки (soft skills)

Слайд 116

Традиционный подход в обучении
Agile-подходы в образовании
Период обучения
Формат обучения
Форма организации
Форма восприятия
информации

от трёх месяцев до полугода

обучение построено как игра

общие лекции и семинары

пассивное восприятие

короткие спринты от одной до двух недель

практические группы от 6 до 8 человек

активная самостоятельная работа в группах

соответствие строгому учебному плану

Оценка результатов

Роль преподавателя

внешняя оценка

полностью контролирует весь учебный процесс

внутренняя оценка

направляет и корректирует

Слайд 117

Заинтересованные стороны
Agile
Государственное управление и управление, основанное на данных
Государственные услуги для граждан
Работа отраслей и

проекты в разных сферах жизнедеятельности

Государственные служащие одного или нескольких органов власти различных уровней, которые участвуют в реализации проекта и используют его результаты

Ускорение, оптимизация, снижение количества ошибок во внутренних процессах работы государственных органов либо при взаимодействии государственных органов. Улучшение качества / скорости принятия решений за счет применения данных

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

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

Значительное снижение издержек для участников взаимодействия, уменьшение количества ошибок. Существенные экономические эффекты как для участников оборота, так и для государства

Тип проекта

Государственные служащие, сторонние пользователи услуг (частные лица либо организации)

Слайд 118

Текст
Текст
Чем более масштабен цифровой проект и чем сильнее трансформационный эффект, тем

больше заинтересованных сторон и тем сложнее задача согласовать их позиции.

Текст

Цифровая среда меняется очень быстро

Применение гибких подходов эффективно по нескольким причинам:

Цифровые проекты являются инновационными
по своему результату

Слайд 119

Создание суперсервисов — это значительный прорыв в отношениях государства и граждан,

новый подход, который сопоставим с наиболее перспективными практиками оказания государственных услуг на Западе

Слайд 120

В подходе к созданию суперсервисов заложены основные принципы, отвечающие философии гибких

подходов:
проектирование без привязки к географическому расположению участников проектных команд
отправная точка в виде экранных форм и с учетом пользовательского опыта (UХ), понимание потребности клиента
создание нового целевого процесса оказания сервиса и проектирование требований к информационным системам для поддержки нового процесса
гибкое проектирование сквозных процессов с участием множества ведомств

Слайд 121

* По результатам опроса в телеграм-канале Aglie Thinking

Слайд 122

Согласно исследованиям 2021 года, 95% респондентов заявили, что их компании частично либо

полностью используют Agile методологии ведения проектов

Разработка программного обеспечения (37%)
IT (26%)
Управление операциями (12%)
Маркетинг (7%)
Отдел кадров или HR (6%)
Отдел продаж (5%)

Разработка ПО

ИТ

Маркетинг

Управление операциями

Отдел кадров

Отдел продаж

Гибкие методологии управления проектами

Содержание

Вопросы темы:Сравнение гибких методов с традиционным подходомИстория появления AgileЧто такое управление

Вопросы темы:Анализ и внедрение проекта с AgileПрименение Agile на практике

Сравнение гибких методов с традиционным подходом01Вопрос

Принципыметодов

Начнем с инкрементального подхода – это быстрое создание продукта с ограниченным,

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

В этом примере совмещаются инкрементальный и итеративный подходыИтеграция подходов

Классическое проектное управление («водопад») основано на последовательности выполнения этапов работ и

Классический подходAgileОтношение к изменениямТип мышления, отношенийМетрики проектаКак правило имеет негативный характер

Классический подходAgileНаличие руководств, методикОбласть эффективного примененияХорошо структурированы, детально описаны (PMBoK, PRINCE2).

Феномен гибридных методологий проектного управления — следствие конкуренции между гибкими и

WBS используется для планирования высокоуровневой дорожной карты проекта, Гибрид методовВ гибридном

Компоненты#1#2#3#n1-й повтор2-й повтор3-й повтор

История появления Agile02Вопрос

Software engineering - менеджмента разработки программ Первое электронное устройство, в названии которого

ЗаказчикФилиал:Или кончились деньгиИли кончилось терпениеFixХватит, больше не надоFixFixFixFixFixFixFixFixFixFixFixFixFixFixCode&FixПрограммист

Проекты всегда превышали бюджетыРеализация проекта всегда превышала оговоренные срокиИтоговое ПО неэффективно

В исходной «каскадной модели» стадии шли в таком порядке:Определение требованийПроектированиеКонструирование (также

На первом этапе делалась самая простая реализация, которая доводилась до стадии

Этот итеративный подход позволял использовать наработки первого этапа и получить гораздо

ВремяЭто дает возможность разным специалистам раньше получить обратную связь и внести

Waterfall with SubprojectsМодуль 1Модуль 2Модуль 3ПроектированиеРазработкаТестированиеПроектированиеРазработкаТестированиеПроектированиеРазработкаТестированиеВремя

Компания IBM официально перешла к политике разделения продаж «железа» и софтаРазрастающийся

Софтверный рынокX2 раза каждые 3 года

В 1971 году резко изменился и рынок «железа», в связи с

Итеративно-инкрементальная модельПо итогам каждой итерации происходит обновление требований на основе оценки

Важным также было появление в 1985 году «Спиральной модели» Барри Боэма.

1. Determine Objectives2. Identify $ resolve risks3. Development $ Test4. Plan

В 1986 году были представлены результаты исследований успешного опыта быстрого создания

Туре А - Каскадныйпроцесс. Специалистыработают изолированноТуре В - Интеграция в точке

40млн. компьютеровРост продаж основных игроков рынка составил 20млн. компьютеровX8 раз за

V-Model (Verification and Validation Model)AcceptanceTestingRequirementsAnalysisSystem DesignSystemTestingHigh-LevelDesignIntegrationTestingUnitTestingLow-LevelDesignImplementationCode ReviewStatic CodeAnalysisReview System DesignReview ArchitecturalDesignReview

Спиральную модельV-МодельPRINCE2 другие, основанные на WaterfaК «тяжеловесным» моделям и подходам относили8

К легковесным методам причисляли следующие: Crystal ClearExtreme Programming (XP)Rapid Application Development

Параллельно со всем этим, развивались методы в концепции управления качеством (quality

Четыре основные ценности:Люди и взаимодействие важнее процессов и инструментовРабочее программное обеспечение

03ВопросЧто такое управление ИТ-проектом

Семейство гибких методологий буквально ворвалось на софтверную сцену и перевернуло все

Мы всегда готовы к изменениям, так как понимаем, что мир вокруг

ВажнееВажнееВажнееВажнее

Наш высший приоритет – это удовлетворение заказчика с помощью частых и

Успешные проекты строятся мотивированными людьмиСамый эффективный метод взаимодействия и обмена информацией

Команда должна постоянно искать способы стать эффективнее путем настройки и адаптации

Требования потенциальных пользователейСкрам-мастерДиаграмма сгорания задачЕжедневное совещание (скрам)Каждые 24 часа1-4 недели СпринтОбзор

Владелец продукта – человек отвечающий за требования и их приоритеты, работая

Экстремальное программированиеУправленческие практики Игра в планирование Частые небольшие релизы Заказчик всегда

Канбан – это высокоадаптивный инструмент, который требует от команды, решившей использовать

ПулОчередьВыполнениеПроверкаГотовоПроект 1Проект 2Проект 3Проект 4 Специалист 1Специалист 2Специалист 3Специалист 4Специалист 5Специалист

Scrum вовсе не методология, это гибкий управленческий фреймворк Scrum используют не

Владелец продукта (Product Оwner, менеджер продукта) – это член команды, ответственный

Скрам-мастер (Scrum Master) – член команды, который дополнительно отвечает за процессы,

Что будет сделано к следующему скрам-митингу? Спринт – это ограниченная по

В долгосрочном плане ретроспективы (или сокращенно «ретро») являются самой важной практикой

Инкремент продукта – новая функциональность продукта, созданная во время спринтаВ Scrum

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

Практика анализа персон пришла в управление продуктами из практик User Experience

2.ПРОБЛЕМА1-3 ключевыхпроблемысуществующие альтернативыСписок того, как эти проблемыуже решаются сегодня7. СТРУКТУРА ИЗДЕРЖЕКСписок

Верхний слой подзадач представляет собой простейшую возможную реализацию функционала и обычно

ВремяВажность

Уникальный числовой идентификатор истории – обычно совпадает с идентификатором истории пользователя

Подробное описание – текстовое и графическое описание истории пользователя Демонстрация –

Как вы отнесетесь к отсутствию данной функциональности в продукте? Таким образом,

Закон Мерфи: «Если есть несколько способов понять задачу, то кто-то обязательно

В соответствии с навыками и знаниями человека задачи можно категоризировать следующим

«Любая работа увеличивается в объеме, чтобы заполнить все отпущенное на нее

Команда – это небольшая группа людей, взаимодополняющих и взаимозаменяющих друг друга,

Фокусирование на результатеФормированиеБурлениеНормализацияФункционированиеРасформированиеФокусирование на отношениях

Поддерживающие поведениеДирективное поведениеВысокийНизкийВысокий

Команды уровня 1 Командам данного уровня требуется предписывающий стиль лидерства. Лидер

Покер-планирование (Planning poker) – консенсусная относительная оценка историй пользователей командой. Этот

Покер-планирование проводится следующим образомКаждому участнику раздается колода карт с числовыми весами

Вопросы темы:
Сравнение гибких методов с традиционным подходом
История появления Agile
Что такое управление

Вопросы темы:
Анализ и внедрение проекта с Agile
Применение Agile на практике

Сравнение гибких методов с традиционным подходом
01
Вопрос

Принципы
методов

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

В этом примере совмещаются инкрементальный и итеративный подходы
Итеграция подходов

Классический подход
Agile
Отношение к изменениям
Тип мышления, отношений
Метрики проекта
Как правило имеет негативный характер

Классический подход
Agile
Наличие руководств, методик
Область эффективного применения
Хорошо структурированы, детально описаны (PMBoK, PRINCE2).

WBS используется для планирования высокоуровневой дорожной карты проекта,
Гибрид методов
В гибридном

Компоненты
#1
#2
#3
#n
1-й
повтор
2-й
повтор
3-й
повтор

История появления Agile
02
Вопрос

Software engineering - менеджмента разработки программ
Первое электронное устройство, в названии которого

Заказчик
Филиал:
Или кончились деньги
Или кончилось терпение
Fix
Хватит, больше не надо
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Code&Fix
Программист

Проекты всегда превышали бюджеты
Реализация проекта всегда превышала оговоренные сроки
Итоговое ПО неэффективно

В исходной «каскадной модели» стадии шли в таком порядке:
Определение требований
Проектирование
Конструирование (также

Время
Это дает возможность разным специалистам раньше получить обратную связь и внести

Компания IBM официально перешла к политике разделения продаж «железа» и софта
Разрастающийся

Софтверный рынок
X2 раза
каждые 3 года

Итеративно-инкрементальная модель
По итогам каждой итерации происходит обновление требований на основе оценки

1. Determine Objectives
2. Identify $ resolve risks
3. Development $ Test
4. Plan

Туре А - Каскадный
процесс. Специалисты
работают изолированно
Туре В - Интеграция в точке

40млн. компьютеров
Рост продаж основных игроков рынка составил
20млн. компьютеров
X8 раз
за

V-Model (Verification and Validation Model)
Acceptance
Testing
Requirements
Analysis
System Design
System
Testing
High-Level
Design
Integration
Testing
Unit
Testing
Low-Level
Design
Implementation
Code Review
Static Code
Analysis
Review System Design
Review Architectural
Design
Review

Спиральную модель
V-Модель
PRINCE2
другие, основанные на Waterfa
К «тяжеловесным» моделям и подходам относили
8

К легковесным методам причисляли следующие:
Crystal Clear
Extreme Programming (XP)
Rapid Application Development

Четыре основные ценности:
Люди и взаимодействие важнее процессов и инструментов
Рабочее программное обеспечение

03
Вопрос
Что такое управление ИТ-проектом

Важнее
Важнее
Важнее
Важнее

Успешные проекты строятся мотивированными людьми
Самый эффективный метод взаимодействия и обмена информацией

Требования потенциальных пользователей
Скрам-мастер
Диаграмма сгорания задач
Ежедневное совещание (скрам)
Каждые 24 часа
1-4 недели Спринт
Обзор

Экстремальное программирование
Управленческие практики
Игра в планирование
Частые небольшие релизы
Заказчик всегда

Пул
Очередь
Выполнение
Проверка
Готово
Проект 1
Проект 2
Проект 3
Проект 4
Специалист 1
Специалист 2
Специалист 3
Специалист 4
Специалист 5
Специалист

Scrum вовсе не методология, это гибкий управленческий фреймворк
Scrum используют не

Что будет сделано к следующему скрам-митингу?
Спринт – это ограниченная по

Инкремент продукта – новая функциональность продукта, созданная во время спринта
В Scrum

Управление проектом с Agile
04
Вопрос

2.ПРОБЛЕМА
1-3 ключевых
проблемы
существующие альтернативы
Список того, как эти проблемы
уже решаются
сегодня
7. СТРУКТУРА ИЗДЕРЖЕК
Список

Время
Важность

Подробное описание – текстовое и графическое описание истории пользователя
Демонстрация –

Как вы отнесетесь к отсутствию данной функциональности в продукте?
Таким образом,

Фокусирование на результате
Формирование
Бурление
Нормализация
Функционирование
Расформирование
Фокусирование на отношениях

Поддерживающие поведение
Директивное поведение
Высокий
Низкий
Высокий

Команды уровня 1
Командам данного уровня требуется предписывающий стиль лидерства. Лидер

Покер-планирование проводится следующим образом
Каждому участнику раздается колода карт с числовыми весами