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

1.

Онлайн-курс
Гибкие методологии
управления проектами
Тема: Гибкая методология управления проектамиAgile
Автор: Халимдарова Гюзелия Ринатовна
Спикер: Верхотуров Евгений Валерьевич

2.

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

3.

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

4.

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

5.

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

6.

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

7.

Итеративный подход
Итеративный подход заключается в повторении операций
улучшения результатов предыдущего этапа (итерации)
Портрет
Лизы
Герардины
для

8.

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

9.

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

10.

Характеристика
Поставка ценности (работающего
результата)
Проверка гипотез
Планирование
Стиль менеджмента, руководства
Классический подход
Agile
Происходит в конце проекта
Осуществляется по мере реализации
проекта в виде работающих
элементов
продукта.
Использует
Как правило, выполняется
на предпроектной стадии,
до старта проекта
Выполняется командой в ходе проекта
для улучшения продукта. Часть
гипотез может быть признана
несостоятельными
Детальное, до конца проекта.
Для оценки сроков используется
Метод критического пути.
В проектах с высокой
неопределенностью используется
метод «набегающей волны»
Вертикаль управления: Управляющий
комитет -> Куратор, Заказчик ->
Руководитель проекта
Эмпирическое, на основе исторических
данных
о
реализованных элементов продукта
Самоорганизация
внутри команды. Плоская команда
без внутренней иерархии

11.

Характеристика
Отношение к изменениям
Тип мышления, отношений
Метрики проекта
Классический подход
Agile
Как правило имеет негативный
характер – изменения как следствия
реализации рисков
и
наступления проблем. Требует
формального процесса по анализу
последствий и пересчету критического
пути проекта, анализа альтернатив
Изменения являются частью процесса
разработки. Источником изменений
является в т.ч. более лучшее
понимание продукта
на основе опыта
Как правило определяется культурой
организации,
зачастую
фиксированный mindset
% реализации, отклонение
от плана, Метод освоенного объема,
прогнозная дата завершения проекта
В проектах с высокой
неопределенностью используется
метод «набегающей волны»
Необходим гибкий mindset
для успешной работы в среде
с высокой неопределенностью
Диаграмма сгорания задач
(Burn down chart), Накопительная
диаграмма реализованных функций
(Burn Up Chart),
Дата
выхода на рынок
(Time to market)

12.

Характеристика
Наличие руководств, методик
Область эффективного применения
Классический подход
Agile
Хорошо структурированы, детально
описаны (PMBoK, PRINCE2).
Отраслевые стандарты и практики
Верхнеуровневые фреймворки
(например, Скрам). Множество
отдельных практик (ежедневное
собрание, ретроспектива, спринт и
др.)
«Сложные системы» по модели Киневин
(Cynefin) – много работ, агентов
(стейкхолдеров). Продукт
и
требования к нему известны, состав
работ может быть описан
и
зафиксирован. Границы проекта
фиксированы
«Сложные системы» по модели
Киневин (Cynefin) – много работ,
агентов (стейкхолдеров).
Продукт и требования к нему
известны, состав работ может быть
описан и зафиксирован.
Границы проекта фиксированы.
«Запутанные системы» по модели
Киневин (Cynefin) – не знаем продукт
и/или процесс его создания. Состав
работ проекта
не определен.
Границы проекта размыты

13.

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

14.

Гибрид методов
В гибридном методе используется классический
метод декомпозиции работ на более мелкие
управляемые компоненты
Это нужно для построения
иерархической структуры работ проекта —
ИСР (Work Breakdown Structure, WBS)
WBS используется для планирования высокоуровневой
дорожной карты проекта,
Agile — для разработки, уточнения
выпуска каждого компонента и подкомпонента продукта
и

15.

Компоненты
Требования
к продукту
Обратная связь от
заказчика
Поток
1-й
повтор
2-й
повтор
3-й
повтор
#1
ИСР
Бэклог
Спринт
Спринт
Спринт
#2
ИСР
Бэклог
Спринт
Спринт
Спринт
#3
ИСР
Бэклог
Спринт
Спринт
Спринт
#n
ИСР
Бэклог
Спринт
Спринт
Спринт
Релиз 1
Релиз 2
Релиз 3
Отзыв

16.

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

17.

Software engineering
Software engineering - менеджмента
разработки программ
Первое электронное устройство,
названии которого было слово «computer», это ENIAC
(Electronic Numerical Integrator
and
Computer), который разрабатывался
1942–1945 годах и работал 10 лет, до 1955 года
в
в
Начало массовой разработке ПО было положено
в 1957 году, когда компания IBM презентовала первый язык
программирования высокого уровня Fortran (Formula
Translator)

18.

Code&Fix
Хватит, больше
не надо
Fix
Fix
Fix
Заказчик
Программист
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
Fix
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.

Софтверный рынок
Рост мирового софтверского рынка 1964-1985
гг.
$45
млрд.
2
X
$23
млрд.
каждые 3 года
$9,5
млрд.
$0
млрд.
$0,2
млрд.
1964
$0,5
млрд.
1967
1970
$1
млрд.
1973
$2
млрд.
1976
$3
млрд.
1979
1982
раза
1985
1988

27.

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

28.

Итеративно-инкрементальная модель
Требования
Требования
Анализ
Анализ
Анализ
Разработка
Разработка
Тестирование
Тестирование
Поставка
Поставка
Поставка
Готовая версия
продукта 1
Готовая версия
продукта 2
Финальная версия
продукта
Разработка
Тестирование
Итерация N
Требования
Итерация 2
Итерация 1
По итогам каждой итерации происходит обновление требований на
основе оценки и эксплуатации новой версии продукта
Время

29.

Важным также было появление в 1985 году
«Спиральной модели» Барри Боэма. Она была универсальная, но
довольно сложная для понимания
По итогу каждой итерации (витка) мы
должны получить готовый
протестированный прототип, который
дополняет существующий продукт
Эта модель хорошо работает
в сложных, высокорисковых проектах, где
важно получить гарантированный,
качественный результат,
и чрезвычайно высока цена ошибки

30.

Cost
2. Identify $
resolve risks
1. Determine
Objectives
Requirements
plan
Concept
of Operation
Prototype 1
Prototype 2
Concept of Requirements
Detailed
Design
Operational
Prototype
Review
Code
Development
Plan
4. Plan the next
iteration
Verification & Validation
Integration
Test
Test plan
Implementation
3. Development $
Test

31.

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

32.

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

33.

EXHIBIT 1
Sequential (A) vs. overlapping (B and C) phases of development
Туре А
Phase
1
2
3
4
5
Туре B
Phase
1
Туре C
2
3
4
5
Phase
1
2
3
4
5
6
Туре C
Туре А
6
6
Туре А - Каскадный
процесс. Специалисты
работают изолированно
Туре В - Интеграция
в точке передачи
эстафеты от этапа
к этапу
Туре С - Процесс
с перекрытием этапов.
Высокое вовлечение
всех специалистов
во все этапы работы

34.

Рынок персональных компьютеров
45
40млн.
компьютеров
30
Рост продаж
основных
игроков рынка
составил
20млн.
компьютеров
15
0
1985
8
X
1986
1987
Commodore 64
1988
Atari ST
1989
Amiga
1990
1991
Macintosh
1992
Apple 2
1993
1994
IBM PC based
раз
за 10 лет

35.

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

36.

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

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 часа
Product Owner
(представитель
заказчика)
Выбор задач
на день
1.
2.
3.
4.
5.
6.
1-4
недели
Спринт
Команда
разработчиков
Ежедневное
совещание
(скрам)
Список
требований
по приоритетам
7.
Команда
выбирает
важнейшие
задачи, которые
успеет решить
за время спринта
Sprint Backlog
(техническое
задание
на спринт)
Обзор
итогов
спринта
Готовое ПО
8.
Product Backlog
(техническое
задание)
Планирование
спринта
Ретроспективное
совещание

48.

Определение
Всю работу ведите короткими
(от одной до четырех недель)
фиксированными итерациями –
и
спринтами, поставляя в конце
каждого из них законченный
Владелец продукта – человек отвечающий
при
за требования
и ихфункционал, который можно
необходимости вывести
на
приоритеты, работая
рынок, – инкремент продукта
с заинтересованными лицами
Скрам-мастер – человек
отвечающий за соблюдение
процессов в команде
конструктивную атмосферу
Команда согласно своей скорости набирает задачи
на неизменяемую по времени итерацию – СПРИНТ

49.

Экстремальное
программирование
Управленческие
практики
Игра в планирование
Частые небольшие релизы
Заказчик
всегда рядом
40-часовая рабочая
Коллективное
владение
кодом
Инженерные
практики
Непрерывная
интеграция
Парное
программирование
Разработка через
тестирование
Рефакторинг
Простота
Метафора системы
Стандарт кодирования

50.

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

51.

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

52.

Scrum используют не только для
разработки ПО,
он отлично подходит для многих
процессов по созданию продукта,
от венчурных
до маркетинговых продуктов
Scrum вовсе не методология,
это гибкий управленческий
фреймворк
Scrum обычно дополняют инженерными
практиками
из
других гибких методологий
Роли
Владелец продукта
Скрам-мастер
Команда
Артефакты
Бэклог продукта
Бэклог спринта
Инкремент продукта
Процессы
Планирование спринта
Обзор спринта
Ретроспектива
Ежедневный Скрам

53.

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

54.

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

55.

Спринт – это ограниченная по времени итерация,
которая является контейнером для других процессов
в Scrum. В конце спринта создается потенциально готовый
к поставке продукт и начинается следующий спринт
Спринт длится от одной до четырех недель
Скрам-митинг – собрание членов команды для синхронизации
деятельности команды и обозначения проблем.
Каждый член команды отвечает на три вопроса
Что было сделано с предыдущего скрам-митинга?
Какие есть проблемы?
Sprint
1-4 Weeks
Что будет сделано к следующему скрам-митингу?
Обзор спринта– демонстрация владельцу продукта
и заинтересованным лицам работающего функционала продукта,
сделанного за спринт

56.

В долгосрочном плане ретроспективы
(или
сокращенно «ретро») являются самой важной практикой Scrum,
ведь именно они позволяют адаптировать
и настроить Scrum,
делая из него по-настоящему гибкий фреймворк для управления
проектами
Обычно ретроспектива занимает от 30 минут до четырех часов
и ее продолжительность зависит от таких факторов, как:
длина спринта
размер команды
наличие проблем
01
02
03
04
05
Открытие
Сбор мнений
Обсуждение
и генерации идей
Составление плана
действий
Закрытие

57.

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

58.

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

59.

Практика анализа персон пришла
в управление продуктами из
практик
User
Experience
(опыт использования)
Story Mapping (стори маппинг) –
способ визуализации
и планирования функционала

60.

2.ПРОБЛЕМА
1-3 ключевых
проблемы
существующие
альтернативы
Список того,
как эти проблемы
уже решаются
сегодня
7. СТРУКТУРА ИЗДЕРЖЕК
Список постоянных
переменных издержек
3. УНИКАЛЬНАЯ
ЦЕННОСТЬ
Простое четкое
сообщение,
которое отличает
от конкурентов
и привлекает внимание
4. РЕШЕНИЕ
Возможные решения
для каждой проблемы
конкуренты
Список товаров/услуг,
которыми можно
заменить ваш
продукт
(в том числе согласно
концепции JTBD)
8. КЛЮЧЕВЫЕ метрики
Список ключевых цифр,
которые говорят о том,
как обстоит бизнес
и
9. СКРЫТОЕ
ПРЕИМУЩЕСТВО
Ваша особенность,
которую сложно купить
вас или подделать
5. КАНАЛЫ
Списки входящих
и исходящих каналов
на пути к вашим
клиентам
6. ПОТОКИ ПРИБЫЛИ
Список источников прибыли
1. СЕГМНТЫ ПОТРЕБИТЕЛ
Список целевых
покупателей
и пользователей
ранние последователи
Список характеристик
идеального
потребителя

61.

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

62.

Важность
Люди
и взаимодействие
Активность
Время
Задача
Задача
Задача
Задача
Задача
Подзадача
Подзадача
Подзадача
Подзадача
Подзадача
Подзадача
Подзадача
Подзадача
Подзадача
Подзадача
Подзадача

63.

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

64.

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

65.

Таким образом, можно выделить три типа функций продукта
Обязательные функции
Линейные функции
Привлекательные функции
Задаем по каждой истории пользователю два вопроса.
Как вы отнесетесь к
наличию данной
функциональности в
продукте?
Как вы отнесетесь к
отсутствию данной
функциональности в
продукте?

66.

Закон Мерфи: «Если есть несколько способов понять задачу,
то кто-то обязательно поймет ее неправильно»
Английская
буква
Английское
слово
Русский
перевод
S
Specific
Конкретная
Цель должна быть конкретной
и четко сформулированной
Измеримая
Цель должна иметь количественные
или качественные параметры, по которым
ее можно оценить
M
Measurable
A
Achievable
Достижимая
R
Relevan
Уместная
Time-bound
Ограниченная
во времени
T
Что это означает?
Цель должна быть реалистичной и достижимой
в тех временных рамках, которые для нее
отводятся
Цель должна быть адекватной и согласованной
с другими целями
Цель должна быть ограничена временными
рамками и иметь определенный срок
достижения

67.

В соответствии с навыками и знаниями
человека задачи можно категоризировать
следующим образом:
Недостижимые
Труднодостижимые
Достижимые
Легкодостижимые
Общий вывод можно сделать
следующий: необходимо
чередовать достижимые
и труднодостижимые задачи

68.

Закон Паркинсона
«Любая работа увеличивается в объеме, чтобы заполнить
все отпущенное на нее время»
Срочность целей тесно связана с
достижимостью:
чем
меньше срок исполнения задачи,
тем более
она
труднодостижимая,
что надо учитывать при
постановке задач
Концепция ограничения
по срокам встроена
в Scrum: итерации всегда
фиксированного размера
и команда четко знает,
когда будет проводиться
демонстрация результатов
спринта

69.

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

70.

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

71.

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

72.

Высокий
Поддерживающие поведение
Высокий уровень
Поддержки
и низкий
Директивности
Низкий
Высокий уровень
Директивности
и высокий
Поддержки
S3
S2
S4
S1
Низкий уровень
Поддержки и
Низкий
Директивности
Высокий уровень
Директивности
и низкий Поддержки
Директивное поведение
Высокий

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), или
метод оценки по трем точкам
Метод заключается в получении трех оценок:
оптимистичной (Мин)
вероятной (Сред)
пессимистичной (Макс)
Вероятная дата
Отклонение
завершения
( Мин + 4 × Сред + Макс )
( Макс – Мин ) / 6

80.

Особенности Scrum
Первый вопрос, который обычно
возникает, – как продать Scrum клиенту
На данном этапе очень важно объяснить
заказчику, что он сможет:
Каждые две недели получать новый
функционал, который можно попробовать и
выпустить на рынок
для
зарабатывания денег

81.

Особенности Scrum
Каждые две недели менять требования,
чтобы изменения
в
бизнесе отражались и в ПО
Регулировать сроки и стоимость работ по
проектам за счет возможности остановить
проект
после любого спринта
Второй вопрос, который появляется
сразу после первого, – как отразить
процесс в контракте

82.

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

83.

Программа-минимум – это посещение
заказчиком всех демонстраций
Программа-максимум – это
присутствие представителя
заказчика и на других
мероприятиях
В самом простом случае клиентов
можно разделить
на три группы: нелояльные, средние
и лояльные

84.

Худший вариант – создать Excel-файл
с
рисками (в самом укромном уголке)
и
при провале проекта сказать: «Этот риск у
меня есть в реестре под номером 37»
Самый гибкий вариант – сделать доску
с рисками и отслеживать их жизненный цикл
Выявление
Извлечение
уроков
Анализ и
приоритезация
Коррекция
Планирование
Мониторинг

85.

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

86.

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

87.

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

88.

Рефакторинг – это изменения
исходного кода без изменения
функциональности для улучшения
внутреннего качества (простота
кода, гибкость архитектуры и т. д.)
Формальные инспекции кода не
относятся к экстремальному
программированию,
эту практику представляет парное
программирование

89.

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

90.

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

91.

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

92.

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

93.

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

94.

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

95.

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

96.

Scrum of Scrum
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) –
инструмент, который отображает
стадии производственного
процесса и время между ними
Диаграммы причинноследственной связи - на них
отображается множество проблем
и их связи цель– выявление
коренных причин
Заказчик
Поставщик
график производства
Подъем
1x
Загрузка
компонентов
2x
Дробление
420 мин
Передавливание
Разогрев
30 мин
Т ЦИКЛА - 3920 МИН:
120 мин
240 мин
2x
Синтез
2700 мин
Перемещение
2x
Гранулирование
60 мин
3560 МИН - ПОЛЕЗНАЯ РАБОТА
260 мин
1x
Склад
30 мин
360 МИН - ПОТЕРИ
60 мин

103.

На ней также отображаются проблемы,
но они заранее сгруппированы по
нескольким областям, например, таким:
методология
требования
разработка
контроль качества
Рабочее место
(среда)
Материал
Качество ТУМ
Зонирование и компоновка
рабочего места наладчика
Рациональное планирование
операций и действий
Мотивация, лояльность,
заинтересованность
Ручные операции
(один
производитель
Производительность
линии «Пастпак»
Нестандартное дооснащение
(самодельное)
Резерв запчастей
Квалификация
Человек
Оборудование

104.

Контрольные карты - данный инструмент используется
для выявления несистематических отклонений и устранения вариаций
5,2
Средние значение
количества дефектов
5
4,8
4,6
4,4
4,2
CL
4
UCL
3,8
3,6
LCL
3,4
Значения Y
3,2
3
2,8
2,6
2,4
1
3
5
7
9
11
13
15
17
Номер выборки
19
21
23
25

105.

Диаграмма Парето - этот
инструмент позволяет выявить
модули, которые содержат
определенный процент дефектов
Именно на эти модули стоит
обратить внимание:
покрыть их дополнительно
тестами
провести дополнительные
инспекции кода
80
100%
70
90%
80%
60
70%
50
60%
40
50%
30
40%
30%
20
20%
10
10%
0
0%
Сумма
Кумулятивный процент

106.

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

107.

Методология DSDM (Dynamic Systems Development Method – метод
разработки динамических систем) основана на подходе RAD
(Rapid Application Development – быстрая разработка приложений)
и
включает в себя три стадии:
Предпроектная стадия
Жизненный цикл проекта представляет собой реализации
проекта и
включает в себя пять этапов
Постпроектная стадия обеспечивает качественную
эксплуатацию
системы
Жизненный цикл проекта
включает в себя:
Определение реализуемости
Экономическое обоснование
Создание функциональной
модели
Проектирование
и
разработка
Реализация

108.

AUP
Agile Unified Process (AUP) – упрощенная версия IBM Rational
Unified Process, созданная Скоттом Амблером (Scott Ambler)
и
состоящая из семи методов
Моделирование используется для понимания
бизнестребования и предметной области
Реализация
Тестирование
Размещение
Управление конфигурациями
Управление проектом
Среда

109.

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

110.

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

111.

Неделя № 1 (подготовка к трансформации)
Неделя № 2 (нулевой спринт)
Неделя № 3 (старт первого «калибровочного» спринта)
Неделя № 4 (завершение первого «калибровочного» спринта)
Неделя № 5 (старт второго спринта)
Неделя № 6 (завершение второго спринта)
Неделя № 7 (старт третьего спринта)
Неделя № 8 (завершение третьего спринта)
Неделя № 9 (старт четвертого спринта)
Неделя № 10 (завершение четвертого спринта)
Неделя № 11 (старт пятого спринта)
Неделя № 12 (завершение пятого спринта)
Неделя № 13 (старт «идеального» шестого спринта)
Неделя № 14 (завершение «идеального» шестого спринта)

112.

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

113.

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

114.

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

115.

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

116.

Традиционный подход
в обучении
Agile-подходы в
образовании
Период обучения
от трёх месяцев
до полугода
короткие спринты
одной до двух недель
Формат обучения
соответствие строгому
учебному плану
обучение построено
как игра
общие лекции и семинары
практические группы
6 до 8 человек
пассивное восприятие
активная самостоятельная
работа в группах
Форма организации
Форма восприятия
информации
Оценка результатов
внешняя оценка
Роль преподавателя
полностью контролирует
весь учебный процесс
от
от
внутренняя оценка
направляет и корректирует

117.

Тип проекта
Государственное управление
и управление, основанное
на данных
Заинтересованные стороны
Государственные служащие одного или
нескольких органов власти различных
уровней, которые участвуют в
реализации проекта
и
используют его результаты
Государственные услуги для
граждан
Государственные служащие, сторонние
пользователи услуг (частные лица либо
организации)
Работа отраслей
и проекты в разных сферах
жизнедеятельности
Предприятия и участники деятельности в
конкретных отраслях, отраслевые ассоциации,
научное сообщество, государственные
служащие, ответственные за развитие и
мониторинг состояния отрасли
Agile
Ускорение, оптимизация, снижение
количества ошибок во внутренних
процессах работы государственных
органов либо при взаимодействии
государственных органов. Улучшение
качества / скорости принятия решений
за счет применения данных
Перевод услуг в полностью цифровую
форму, ускорение, оптимизация работы,
снижение количества ошибок, удобство
для потребителей услуг
Значительное снижение издержек для
участников взаимодействия,
уменьшение количества ошибок.
Существенные экономические эффекты
как для участников оборота, так и для
государства

118.

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

119.

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

120.

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

121.

Сферы применения метода Канбан
ИТ
0,56
Производственные компании
0,11
HR-сервис
0,07
Маркетинг
0,07
Поддержка клиентов
0,05
Ритейл
0,05
Другое
0,1
* По результатам опроса в телеграм-канале Aglie Thinking

122.

Согласно исследованиям
2021 года, 95%
респондентов заявили,
что их компании частично либо
полностью используют Agile
методологии ведения проектов
Разработка программного
обеспечения (37%)
IT (26%)
Управление операциями (12%)
Маркетинг (7%)
Отдел кадров или HR (6%)
Отдел продаж (5%)
Разработка ПО
Управление
операциями
Отдел кадров
12%
Отдел продаж
ИТ
37%
6%
5%
26%
7%
Маркетинг

123.

Обычный хлебозавод в России
Технолог получает от генерального
директора задание на разработку нового
вида хлебной продукции
технолог создаст хлебную новинку
на свой вкус и представит ее директору
Agile-хлебозавод в России
У генерального директора рождается идея о
выпуске нового сорта хлеба
каждое из действующих лиц оценивает
результат и выдает обратную связь
для лучших показателей