-
1.
Основы Agile
Борис Вольфсон
HeadHunter
-
2.
Поднимите руки, те кто использует
Agile более полугода
-
3.
Данный доклад предназначен только для
новичков, поэтому все, кто уже работает по
Agile идите слушать Shannon Ewan
-
4.
CTO HeadHunter
Вольфсон
Борис
Автор книги «Гибкое
управление проектами и
продуктами»
Спикер и тренер
-
5.
История программирования
Если программирование - это индустрия, то
почему бы не использовать методы управления
из других областей?
-
6.
Водопадная модель
http://www.serena.com/docs/agile/papers/Managing-The-Development-of-Large-Software-Systems.pdf
-
7.
Кто-то использует тяжеловесные
методологии?
-
8.
Это в западных странах, а у нас
-
9.
Россия
•Отсутствие
процессов
Запад
•Тяжеловесные
процессы
-
10.
Кто-то работает без методологии?
-
11.
Зачем нужен Agile?
-
12.
Agile-манифест разработки программного
обеспечения
Мы постоянно открываем для себя более совершенные методы разработки
программного обеспечения, занимаясь разработкой непосредственно и помогая
в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то,
что слева.
http://www.agilemanifesto.org/iso/ru/
-
13.
Ценности Agile
Мы постоянно открываем для себя более совершенные методы разработки
программного обеспечения, занимаясь разработкой непосредственно и помогая
в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то,
что слева.
http://www.agilemanifesto.org/iso/ru/
-
14.
Принципы Agile
1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика,
благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-
процессы позволяют использовать изменения для обеспечения заказчику конкурентного
преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары
недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно
работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была
сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом
обмена информацией как с самой командой, так и внутри команды.
-
15.
Принципы Agile
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать
постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс
разработки.
9. Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
10.Простота — искусство минимизации лишней работы — крайне необходима.
11.Самые лучшие требования, архитектурные и технические решения рождаются у
самоорганизующихся команд.
12.Команда должна систематически анализировать возможные способы улучшения
эффективности и соответственно корректировать стиль своей работы.
-
16.
Что такое Agile
Agile – подходы к созданию продуктов, путем
непрерывной быстрой поставки ценного
рабочего функционала самоорганизованной
командой профессионалов в сотрудничестве с
заказчиком
© Борис Вольфсон
-
17.
Принципы, ценности, практики
http://www.slideshare.net/TechWellPresentations/to-presentation-30268801
Ценности
Принципы
Практики
-
18.
Гибкие практики
http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf
-
19.
Итеративность
Водопадные Итеративные
А А
В В
-
20.
Высокая турбулентность
Водопадные Итеративные
А А
В В
C C
-
21.
Итеративно, но неинкрементально
http://jpattonassociates.com/dont_know_what_i_want/
-
22.
Итеративно и инкрементально
http://jpattonassociates.com/dont_know_what_i_want/
-
23.
Треугольник ограничений
Водопад Agile
Содержание Ресурсы Время
Ресурсы Время
Зафиксировано
Планируется Содержание
-
24.
Agile треугольник
Ценность
Качество Ограничения
http://theagileexecutive.com/2010/07/22/the-devops-triangle/
http://www.brighthubpm.com/agile/50212-the-agile-triangle-value-quality-and-constraints/
Меняется определение
успешности проекта
-
25.
Что такое Agile с точки зрения процессов
Agile – семейство методологий программного
обеспечения, которые соответствуют
ценностям и принципам Agile-манифеста
© Борис Вольфсон
-
26.
Agile-зонтик
Henrik Kniberg
-
27.
Гибкие методологии
http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf
-
28.
Scrum
-
29.
Кто-то работает по Scrum?
-
30.
Хиротака Такэути и Икудзиро Нонака
-
31.
The New New Product Development Game
-
32.
Что значит Scrum?
-
33.
Кен Швабер и Джеф Сазерленд
-
34.
http://www.scrumguides.org
-
35.
Scrum в двух словах
Беклог продукта Беклог спринта
Скам-митинг
15 минут
Готовый продукт с
новой
функциональностью
Владелец
продукта
Владелец
продукта
8 часов
Спринт
1-4 недели
Ретроспектива
Обзор спринта
Планирование
спринта
Скрам-мастер
Команда
7±2 человек
-
36.
Определение
Фреймворк, в рамках которого возможно решать
сложные адаптивные проблемы и в то же время
продуктивно и креативно разрабатывать продукты
наивысшего качества.
-
37.
Элементы Scrum
Роли
• Владелец
продукта
• Скрам-мастер
• Команда
разработки
• Команда
Артефакты
• Бэклог
продукта
• Бэклог
спринта
• Инкремент
продукта
Процессы
• Планирование
спринта
• Обзор спринта
• Ретроспектива
• Скрам-митинг
• Спринт
-
38.
Роли
• Скрам Команда состоит из Владельца Продукта, Команды
Разработки и Скрам Мастера. Скрам Команды являются
самоорганизующимися и кросс-функциональными
Скрам Команда
• Владелец Продукта ответственен за достижение максимальной
ценности продукта и работы, выполняемой Командой
Разработки.
Владелец
Продукта
• Команда Разработки состоит из профессионалов, выполняющих
работу по разработке потенциально “Готового” к выпуску
Инкремента продукта каждый Спринт
Команда
Разработки
• Скрам Мастер отвечает за то, чтобы Скрам был понят всеми
участниками и работал.Скрам Мастер
-
39.
Процессы
• Сердцем Скрама является Спринт длительностью в один месяц или менее, в течение
которого создается потенциально готовый̆ к выпуску и использованию Инкремент
продукта.
Спринт
• Работа на предстоящий Спринт планируется во время Планирования Спринта. План
действий создается при совместной работе всей Скрам Команды.Планирование Спринта
• Ежедневные Скрамы –это 15-минутные мероприятия для Команды Разработки с целью
синхронизации действий и создания плана работы на ближайшие 24 часа.Ежедневный Скрам
• Встреча по Обзору Спринта проводится в конце Спринта для инспекции Инкремента и
при необходимости адаптации Беклога Продукта. Во время Обзора Спринта Скрам
Команда и заинтересованные лица обсуждают выполненную во время Спринта работу
Обзор Спринта
• Ретроспектива Спринта дает Скрам Команде возможность инспектировать себя и создать
план улучшений для следующего Спринта.Ретроспектива Спринта
-
40.
Артефакты
• Упорядоченный список всего, что может быть нужным в
продукте, он является единственным источником требований
для любых изменений, которые может потребоваться внести в
продукт.
Беклог
Продукта
• Набор Элементов Беклога Продукта, выбранных для
выполнения в текущем Спринте, а также план разработки
Инкремента продукта
Беклог
Спринта
• Сумма всех выполненных требований Беклога Продукта,
реализованных во время текущего Спринта, и ценности всех
предыдущих Спринтов
Инкремент
-
41.
Оценка проекта
-
42.
Шкала оценок
0 0,5 1 2 3 5 8 13 20 40 100
-
43.
Покер-планирование
-
44.
1453
Пользователь вводит логин
и пароль для того, чтобы
авторизоваться на сайте
-
45.
2
3
5 3
8
5
1453
Пользователь вводит логин
и пароль для того, чтобы
авторизоваться на сайте
-
46.
Ла-ла-ла
ла-ла ла-
ла-ла-ла
Ла-ла-ла
ла-ла ла-
ла-ла-ла
2
3
5 3
8
5
1453
Пользователь вводит логин
и пароль для того, чтобы
авторизоваться на сайте
-
47.
3
3
3 3
5
5
1453
Пользователь вводит логин
и пароль для того, чтобы
авторизоваться на сайте
-
48.
3
3
3 3
3
3
1453
Пользователь вводит логин
и пароль для того, чтобы
авторизоваться на сайте
Оценка: 3
-
49.
Отбор задач на спринт на основе скорости
36
37
38
39
40
41
42
43
44
45
46
1 2 3 4 5 6 7 8
Скорость
Средняя скорость
Спринты
Сторипоинты
-
50.
Отбор задач на спринт на основе скорости
А
B
C
D
F
G
H
I
J
Важность
А
B
C
D
F
Беклог продукта Беклог спринта
Скоростькоманды
-
51.
Диаграмма сгорания
0
2
4
6
8
10
12
0
5
10
15
20
25
30
35
40
45
50
1 2 3 4 5 6 7 8 9 10
Диаграмма сгорания в конце спринта
Сторипоинты Идеал Истории пользователя
Дни
Сторипоинты
Историипользователей
-
52.
Диаграмма сгорания с отставанием
0
5
10
15
20
25
30
35
40
45
50
1 2 3 4 5 6 7 8 9 10
Диаграмма сгорания с отставанием
Сторипоинты Идеал
Дни
Сторипоинты
-
53.
Диаграмма сгорания с опережением
0
5
10
15
20
25
30
35
40
45
50
1 2 3 4 5 6 7 8 9 10
Диаграмма сгорания с опережением
Сторипоинты Идеал
Дни
Сторипоинты
-
54.
Доска задач
План Аналитика Разработка Тестирование Готово
A
B
C
D
E
Важность
-
55.
Обзор спринта
Поставляет
Владелец продуктаВладелец продукта
КомандаКоманда
Изменения
в требованиях
Разрабатывает
Инкремент
продукта
Демонстрируется
-
56.
Ретроспектива
Не хочешь пропустить со
мной по пиву?
Не могу, я делаю
список, в чем я
могу
усовершенствовать
себя в следующем
году
Не-
плохая
идея,
сделаю
тоже
самое
Ничего.
Совершенство достигнуто
Мда, вот
это
конструк-
тивность.
Какая едкая
зависть,
тебе бы
поработать
над этим
«Совершенствоваться не
обязательно. Выживание – дело
добровольное»
-
57.
Ретроспектива
Открытие – 5%
Сбор данных – 30%-50%
Проникновение в суть – 20%-30%
Принятие решение – 10%
Закрытие – 5%-10%
-
58.
Цикл Деминга-Шухарта
Plan
Do
Check
Act
-
59.
Канбан
-
60.
Кто-то работает, использую Kanban?
-
61.
Девять ценностей
-
62.
Принципы
1. Начать с того, что делаем сейчас
2. Придти к соглашению идти путём
эволюционных перемен
3. Изначально уважать существующие роли,
должности и обязанности
4. Поощрять инициативные действия на всех
уровнях организации
-
63.
Практики
Визуализация
Ограничение работы в процессе
Управление потоком
Явные правила
Обратные связи
Улучшения с помощью экспериментов,
используя модели и научный подход
-
64.
Визуализация
План
5
Аналитика
3
Разработка
4
Тестирование
4
Готово
A
B
C
D
E
F
G
H
I
J
K
M
N
O
P
Q
-
65.
Визуализация
-
66.
Диаграмма кумулятивного поток
http://paulklipp.com/blog/
-
67.
Scrumban
Scrum
• Роли
• Артефакты
• Процессы
• Псевдоитерации
Kanban
• WIP
• Уменьшение
Lead Time
-
68.
Алтернативный путь к гибкости
-
69.
Материалы
-
70.
• http://www.piter.com/product/gibkoe-upravlenie-
proektami-i-produktami
• http://www.ozon.ru/context/detail/id/30003058/
• http://www.litres.ru/boris-volfson/gibkoe-upravlenie-
proektami-i-produktami/
-
71.
Материалы
www.slideshare.net/Askhat/scrum-5545482
http://www.slideshare.net/Nfilippov/scrum-4432989
http://www.slideshare.net/azheglov/agile-piter
http://www.slideshare.net/f0g/kanban-sketches
Видео с AgileDays’14
-
72.
Контакты
• borisvolfson86@gmail.com
• www.twitter.com/borisvolfson
• www.facebook.com/borisvolfson
http://www.allaboutagile.com/impediment-management-and-the-agile-triangle/
Организуйте работу в вашей организации в небольших кроссфункциональных командах, которые содержат всех необходимых специалистов для реализации проекта. Выделите человека - скрам-мастера, который будет отвечать за соблюдение процессов в команде и конструктивную атмосферу.
Требования разбейте на небольшие, ориентированные на пользователей, функциональные части, которые максимально независимы друг от друга, в результате чего получите бэклог продукта. Затем упорядочите элементы бэклога по их важности и произведите относительную оценку объемов каждого элемента. Выделите отдельного человека – владельца продукта, который будет отвечать за требования и их приоритеты, работая с заинтересованными лицами.
Всю работу ведите короткими (от 1 до 4 недель) фиксированными итерациями – спринтами, поставляя в конце каждого из них законченный функционал, который можно при необходимости вывести на рынок – инкремент продукта. Команда согласно своей скорости набирает задачи на неизменяемую по времени итерацию – спринт. Каждый день проводится скрам-митинг, на котором команда синхронизирует свою работу и обсуждает проблемы. В процессе работы члены команды берут в работу элементы бэклога согласно приоритету.
В конце каждого спринта проводите обзор спринта, чтобы получить обратную связь от владельца продукта, и ретроспективу спринта, чтобы оптимизировать ваши процессы. После этого владелец продукта может изменить требования и их приоритеты и запустить новый спринт.
Роли
В Scrum принято выделять три основных роли, которые составляют в Scrum-команду: владелец продукта, скрам-мастер и команда разработки.
Владелец продукта (Product owner, Продукт оунер, Менеджер продукта) – это член команды, ответственный за максимизацию ценности продукта и управление бэклогом продукта;
Скрам-мастер (Scrum Master) – член команды, который дополнительно отвечает за процессы, координацию работы команды и поддержание социальной атмосферы в команде.
Команда разработки (Development Team) – это кроссфункциональная и самоорганизующаяся группа специалистов, которая создает инкремент продукта.
Владелец продукта
Основной задачей владельца продукта является максимизация ценности продукта через управление бэклогом продукта включая:
Создание и обработку элементов бэклога;
Приоритезацию элементов бэклога;
Выработку понимания элементов бэклога у команды;
Часть из этих задач владелец продукта может делегировать членам команды, но он остается ответственным за них. Кроме того, владелец продукта – это всегда один человек, а не группы или комитет, и все требования в виде элементов бэклога поступают команде через него.
Команда разработки
Команда разработки каждый спринт поставляет потенциально готовый к релизу продукт. Она состоит из кроссфункциональных специалистов без разделение на профессии, хотя возможны специализации отдельных ее членов, но ответственность за поставку все равно лежит на команде в целом.
Важным свойством команды разработки является ее самоорганизация: она сама определяет способ, которым сделает из элементов бэклога инкремент продукта.
Минимальный размер команды разработки – 3 человека, не считая владельца продукта и скрам-мастера, если они непосредственно не участвуют в создании инкремента. Максимальный размер команды - 9 человек, так как при дальнейшем увеличении теряется эффективность.
Скрам-мастер
Скрам-мастер – это член команды, который ответственен за понимание и реализацию Scrum’а, и помогает в этом следующим субъектам:
Владелец продукта
Помогает в планировании и оценке элементов бэклога
По необходимости помогает в организации процессов
Команда разработки
Обучает команду самоорганизации и кроссфункциональности
Устраняет внешние препятсвия
По необходимости помогает в организации процессов
Организация в целом
Адаптирует Scrum в соответствии с потребностями организации
Помогает понять внешним к команде людям Scrum
Обменивается лучшими практиками с другими скрам-мастерами
К сожалению даже в 21-ом веке оценки программных проектов производятся очень плохо. Фактически менеджер просто высказывает догадки на основе своего опыта…
Фундаментальная проблема лежит в области того, что я бы назвал «корпоративной психологии». Дело в том, что для оценки DM-проектов необходимо база знаний не по обычным проектам (да и такие базы не всегда ведутся в наших компаниях), а именно формализованные знания по DM-проектам. Но компании предпочитают как можно быстрей забывать про такие проекты, как на уровне менеджмента, так и на уровне команд.
Таким образом, использую опыт обычных проектов оценки делают достаточно оптимистичные, что еще больше загоняет проект в разряд неподъемных.
В долгосрочном плане ретроспективы (или сокращенно «ретро») являются самой важной практикой Scrum: ведь именно они позволяют адаптировать и кастомизировать Scrum, делая из него по-настоящему гибкий фреймворк для управления проектами.
Ретроспективу традиционно проводят после обзора спринта спустя небольшое количество времени, чтобы оперативно получить фидбек. Скрам-мастер собирают всю команду для обсуждения результатов спринта. Рекомендуется на ретроспективу приглашать владельца продукта для получения дополнительной обратной связи.
Структура ретроспективы
Обычно ретроспектива занимает от 30 минут до 4 часов и ее продолжительность зависит от следующих факторов:
Длина спринта: чем длиннее спринт, тем больше команда успевает сделать и тем больше материала для обсуждения;
Размер команды: чем команда больше, тем больше надо времени, чтобы у каждого ее члена была возможность высказаться и тем больше функционала команда успевает сделать;
Наличие проблем: со временем команда решает проблемы и ретроспективы сокращаются по времени.
В процентном соотношении принято выделять такую структуру.
Также традиционным является формат по сбору данных, который заключается в ответах каждого участника на три вопроса:
Что было сделано хорошо?
Что можно улучшить?
Какие улучшения будем делать?
Количество улучшений, которые команда берет в реализацию, не должно превышать 2-3, чтобы не снизить скорость реализации бизнес-функционала и не потерять фокус. Команда должна обязательно в том или ином виде составить план улучшений для контроля их исполнения.
Для максимальной открытости и прозрачности обсуждения необходимо использовать основное правило ретроспективы, которое можно озвучивать в начале:
«В независимости от того, что удастся выяснить в результате ретроспективы, каждый член команды сделал всё, чтобы добиться успеха»
Если у команды отсутствуют яркие проблемы, то желательно следующие темы обсудить на ретроспективе:
скорость команды и ее изменение по сравнению с предыдущими спринтами;
нереализованные истории пользователей и причины опоздания;
дефекты и их причины;
качество процессов (нарушения, отступления).
К паттернам можно отнести анализ сделанных улучшений за несколько прошлых спринтов. Такая «ретроспектива ретроспектив» может проводить раз в 4 спринта и позволяет контролировать уровень сделанных улучшений.
Акцент делаем на научном подходе.
Plan (планирование)
Производится анализ системы и вырабатываются возможные подходы к улучшениям и определяются желаемые результаты
Do (исполнение)
Решения, выработанные на предыдущем шаге, реализуются.
Check (проверка)
Производится анализ, полученных результатов, на предыдущем шаге.
Act (корректировка)
Выполняются корректирующие действия, для уменьшения отклонений от плана.