Post on 13-Jan-2015
description
Lean и Agile
Никита Филиппов
Филиппов Никита
• ScrumTrek• Agile Coach• Управляющий партнер
• В прошлом• Программист, менеджер
проектов, методолог
Agenda
• Мир современных процессов разработки ПО
• Проблемы в разработке ПО• Lean
– Kanban • Agile
– Scrum
Henrik Kniberg 4
Lean
XPScrum
Agile
TDD
KanbanContinuous Integration
RUP
Что это за фигня?
Pair programming
Refactoring
ЧЕМУ МЫ НАУЧИЛИСЬ?
Каскадная модель (Waterfall)• Заказчик знает чего
хочет• Разработчик знает,
как разработать • Ничего не поменяется
Большинство проектов неуспешны
Henrik Kniberg 7
Успешные проекты в 1994: 15% Среднее значение выхода за бюджет и сроки: ≈170%
Успешные проекты в 2004: 34% Среднее значение выхода за бюджет и сроки: ≈70%
The Standish Group исследовало более 40 000 проектов в течении 10 лет.
Источник:http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standishhttp://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
План: €1,000,000
Факт : €2,700,000
План: €1,000,000
Факт: €1,700,000
Дефекты в самом процессе
• Влияние длины спецификации на сроки• Влияние избыточной детализации на сроки• Влияние изменения требований на сроки• Влияние мнения со стороны на сроки со
стороны
Источник: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
Ненужная функциональность
Функциональность, используемая в типичной системе
Standish Group Study Report
Всегда7%
Часто13%
Иногда16%
Редко19%
Никогда45%
Функциональность
Слож
ност
ь
Цена
# функций в системе
Чему мы научилисьУспешные проекты в 1994: 15%
Среднее значение выхода за бюджет и сроки: ≈170%
Успешные проекты в 2004: 34% Среднее значение выхода за бюджет и сроки: ≈70%
ТОП 5 ПРИЧИН УСПЕХА: 1. Вовлечение заказчика2. Поддерживающий менеджмент
от руководства3. Ясные бизнес цели4. Управление скоупом5. Гибкий процесс
СрокиСтоимость
Функциональность(features)
Quality
«Делая проекты итеративным процессом , решалось много проблем, которые не решал водопадный процесс требующий полное проектирование «СВЕРХУ»»
“Главная причина [для улучшений]что проекты стали меньшего размера.”
Не существует серебряной пули но Гибкие методологии очень близки к этому определению
Jim JohnsonГлава Standish Group
С чем приходилось бороться
• Требования меняются (change requests)• Качеством жертвуют • Люди увольняются• Системы невозможно поддерживать из-за
сильной зависимости человек-модуль/система
• Проблемы интеграции подсистем • Общаемся с заказчиком через документ
Agile разработка• Заказчик понимает о продукте по
мере самой разработки, как он должен выглядеть.
• Разработчики принимают решения о том, как разработать исходя из потребностей заказчика
• Все может меняться с течением времени
Взаимодействие и документация
Agile:
Манифест гибкой разработки
• Люди и взаимодействия важнее чем процессы и инструменты
• Работающий код важнее совершенной документации
• Сотрудничество с заказчиком важнее контрактных обязательств
• Реакция на изменения важнее следования плану
www.agilemanifesto.org
Agile-подход
• Итеративность– Движемся к цели короткими шагами
• Инкрементальность– В конце каждой итерации законченный продукт– Возможность получить обратную связь,
скорректировать и обработать ожидания заказчика
Lean Бережливая разработка ПО
• Lean - aдаптация TPS в США и Европе• Бережливая разработка ПО – адаптация TPS
в разработке ПО (и шире в ИТ)
Том ПоппендикМэри Поппендик
Основные Принципы Лин
• Сформировать поток работ• Контролировать объем единичной работы• Снижать вариативность• Ограничивать количество одновременно
выполняющейся работы (Work In Progress)• Уничтожать потери
7 потерьПроизводственная Система Toyota
Бережливая разработка ПО
Запасы Недоделанная работа
Перепроизводство Ненужная функциональность
Излишняя обработка Повторное изучение (relearning)
Перевозка Передача (handoff)
Движения Переключение между задачами
Ожидание Ожидание
Дефекты Дефекты
Lean Agile
Lean
Agile
Scrum
XPKanban
FDD, DSDM,
OpenUP etc…
Материалы для изучения
Case studies
• http://www.infoq.com/news/2010/08/agile-lean-validation-studies
Agile World (1)
• IBM – http://www.infoq.com/presentations/dancing-agil
e-elephant• Microsoft
– http://www.ademiller.com/tech/reports/agility_and_the_inconceivably_large.pdf
• Nokia– http://agilesoftwaredevelopment.com/files/Scrum
%20in%20Multiproject%20Environment.pdf
AgileWorld (2)
• Google– http://weblogs.asp.net/jsemeniuk/archive/2008/
01/03/lessons-learned-implementing-scrum-at-google.aspx
• AMDocs– http://www.slideshare.net/yyeret/lean-conf-amd
ocs-case-study• Intel
– http://danube.com/docs/case_studies/Intel_case_study.pdf
Цель Agile и Lean
• Создать процесс со стабильными поставками
• Обеспечить прозрачность между Бизнесом и Разработкой
• Самое важное заказчику, как можно быстрее• Постоянно улучшать процесс в контексте
своей компании (нет универсального процесса)
ОТ ФИЛОСОФИИ К ПРАКТИКАМ
Роли в Scrum: Product Owner
• Цель: Развивать продукт/проект с максимальной доходностью (пользой)
• Ответственность:
• Представляет интересы заказчика и заинтересованных лиц
• Формирует и координирует Backlog
• Отвечает за Product Vision
• Управляет датой релиза и его содержанием
Кем Product Owner не является
• Не Руководитель разработки– Не влияет на решения по архитектуре– Не назначает задачи– Не оценивает
Роли в Scrum: TEAM
• Самоорганизованная / самоуправляемая
- Коллективно принимают решения
- Сами координируют и организуют свою работу
• Кросс-функциональная
Роли в Scrum: ScrumMasterЦель: Поддерживать «здоровье» команды, сделать команду самоорганизующейся
Ответственность:
• Фасилитирует (модерирует) митинги
• Поддерживает прозрачность, доверие и взаимную ответственность
• Устраняет внешние препятсвия
• Отвечает за процесс
• Коммуникационный лидер
Кем ScrumMaster не является
• Не технический лидер команды– Не назначает задачи
• Не менеджер проекта– Не принимает решения в отрыве от команды– Не назначает задачи
БАКЛОГ ПРОДУКТА
Product Backlog
• Список всей известной работы (features)
• Фичи из баклога планируются на итерации
• За баклог отвечает Product Owner
Баклог
Баклог продукта
• Приоритезированный список– Истории, баги, технологические улучшения,
открытые вопросы• Более приоритетные элементы баклога
определены детальнее• PO приоритезирует список• Все могут добавлять элементы баклога
ПРОЦЕСС РАБОТЫ
Планирование релиза
Планирование итерации
Скрам (стендап)
ДемонстрацияРетроспектива
ПЛАНИРОВАНИЕ РЕЛИЗА
Планирование релиза
Планирование релиза
Планирование релиза
Планирование релиза
Итерация 1
Итерация 2
Итерация 3
Итерация 4
Планирование релиза
Velocity = 14
5 3 5 2 5 2 1 8 5 5 3 8 2
1 2 3 4
Планирование релиза
Release BurnUp Chart• Предсказать, когда будет выполнен объем
работ
Планирование релиза
ПЛАНИРОВАНИЕ ИТЕРАЦИИ
Планирование итерации
Plan
ning
Poke
r Backlog
Планирование итерации
TaskBoard Планирование итерации
Длительность итерации
• Количество задач– ~20-40 задач
• Частота изменений требований– За итерацию требования не меняются
• Возможность получить значимый результат – ~ 10 Историй
© ScrumTrek.ru, 2008
Планирование итерации
РАБОТА ВНУТРИ ИТЕРАЦИИ
Работа внутри итерации: Доска задач
© scrumtrek.ru
TO DO In progress Done
© scrumtrek.ru
TO DO In progress Done
Работа
по приоритета
м
Работа внутри итерации: Доска задач
© ScrumTrek.ru, 2008Daily Scrum
Скрам (стендап)
Daily SCRUM meeting
• Цель митинга: поделиться информацией• Не предназначен для решения проблем!• Его ведет один человек (ScrumMaster)• Аудитория – команда• Все проблемы становятся видны сразу• Вопросы
– Что ты сделал вчера?– Что ты будешь делать сегодня?– Какие у тебя проблемы?
Скрам (стендап)
Скрам (стендап)
Demo Демонстрация
SMART-цели
• Specific – Конкретный / Понятный• Measurable – Измеримый • Achievable – Достижимый • Relevant – Обоснованный / Соответствующий• Time-bound – Ограниченный по времени
KANBAN – ИНСТРУМЕНТ ДЛЯ НЕ ИТЕРАТИВНОЙ РАЗРАБОТКИ
Цели Kanban
• Визуализировать поток работ• Ограничить количество незавершенной
работы (работы в процессе)• Снизить среднее время выполнения задач• Искать потери, чтобы улучшать процесс
Баклог РазработкаОчередь Тестирование Готово!
2 3 2В прогрессе Готово
12
34
56
78
A10
11
PO
Баклог РазработкаОчередь Тестирование Готово!
2 3 2В прогрессе Готово
1
234
56
78
A10
11
PO
Баклог РазработкаОчередь Тестирование Готово!
2 3 2В прогрессе Готово
1
234
56
78
A10
11
PO
Баклог РазработкаОчередь Тестирование Готово!
2 3 2В прогрессе Готово
1
2
3
4
56
78
A10
11
PO
Баклог РазработкаОчередь Тестирование Готово!
2 3 2В прогрессе Готово
123
4
5
6
78
A10
11
PO
?
Баклог РазработкаОчередь Тестирование Готово!
2 3 2В прогрессе Готово
1
3
2
4
78
A10
11
PO ?5
6
1
Баклог РазработкаОчередь Тестирование Готово!
2 3 2В прогрессе Готово
3
2
478
A10
11
5
6
PO
1
Баклог РазработкаОчередь Тестирование Готово!
2 3 2В прогрессе Готово
3
247
8A10
11
5
6
PO
Баклог РазработкаОчередь Тестирование Готово!
2 3 2В прогрессе Готово
3
2478
A10
11
5
6
1PO
Поиск по вакансиям
Devprom:10241
Заказчик: Пупкин В.
Анализ: 11/03/11Разработка: 18/03/11Тест: 22/03/11
Срок: 24/03/11Приоритет:
Баклог РазработкаОчередь Тестирование Готово!
2 3 2В прогрессе Готово
1
2
3
4
5
6
7
AA
A
BUG
POА-а-а-а!!!
Анализ
6
BUG
– Баг из «СРОЧНО!»– Приоритетные– Риск нарушения сроков
– Остальные в порядке очередности поступления
ПРИОРИТЕТ Разработка
!
ДЕКОМПОЗИЦИЯ В KANBAN
АналитикаОчередь Разработка Тестирование2 3 2
В прогрессе Готово В прогрессе Готово В прогрессе Готово
2
АналитикаОчередь Разработка Тестирование2 3 2
В прогрессе Готово В прогрессе Готово В прогрессе Готово
2
АналитикаОчередь Разработка Тестирование2 3 2
В прогрессе Готово В прогрессе Готово В прогрессе Готово
2
АналитикаОчередь Разработка Тестирование2 3 2
В прогрессе Готово В прогрессе Готово В прогрессе Готово
2
BUG
BUG
АналитикаОчередь Разработка Тестирование2 3 2
В прогрессе Готово В прогрессе Готово В прогрессе Готово
2
BUGBU
G
ПУЛЬС ПРОЕКТА: КАДЕНЦИИ
Каденции
Итерации week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Sprint 1
Plan & commit Review(release?)
Каденции week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Planning cadence (2w)
Sprint 2
Retrospective
Release cadence (1w)
Retrospectives (4w)
События week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Planning (on demand)
Release (on demand)
Retrospectives (on demand)
By Henrik Kniberg
Различные способы лимитировать WIP
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Big item
Big item
Scrum• Не указывается WIP • Таймбоксинг итерации
Kanban• Указывается WIP• Можно комбинировать
большие и малые истории
WIP limit = 3 items
Velocity = 15 story points
Оценка
Задачи Фичи1. Не оценивать. Просто посчитать.
2. Оценивать в T-shirt
1. Без задач
2. Не оценивать задачи, просто сосчитать
3. Оценит задачи в днях1d
2d0.5d
4. Оценить задачи в часах
12h8h4h
S M LЧасы?
Дни?Недели?
S ML
3. Оценивать в story-points
1sp2sp
5sp
4. оценивать в идеальных человеко-днях
1d3d
6d
”типичный”Kanban
”типичный”Scrum
2009-08-29
orem ipsum dolor sit amet, nse ctetur adi pis cing elit nisl
2009-09-01
orem ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl
2009-09-02
orem ipsum dolor sit
amet, nse ctetur adi
pis elit nisl
Analysis Development Acceptance ProdNext
Definition of Done:•Customer accepted•Ready for production
Ongoing Done
Definition of Done:• Code clean & checked in on trunk• Integrated & regression tested• Running on UAT environment
Ongoing DoneOngoing Done
Definition of Done:• Goal is clear• First tasks defined• Story split (if necessary)
2 3 3 2
Feature / story
= completed
= blocked
= who is doing this right now
2009-08-20 2009-09-30
(description)
• Panicfeatures(should be swarmed and kept moving. Interrupt other work and break WIP limits as necessary)
• Priority features• Hard deadline features
(only if deadline is at risk)• Oldest features
2009-09-03ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl
2009-09-02
orem ipsum dolor sit amet, co nse
2009-08-27
orem ipsum dolor sit
amet, ctetur adi pis
cing elit nisl
2009-08-27
orem ipsum dolor sit amet, adi pis cing elit nisl
2009-08-20
orem olor sit amet, co nse ctetur adi pis cing elit nisl
2009-08-30
orem ipsum dolor sit amet, co adi pis cing elit nisl
2009-09-08
2009-08-20
orem ipsum dolor sit
amet, co nse ctetur
adi pis cing elit nisl
2009-08-25
2009-08-22orem ipsum dolor sit amet, co
2009-08-25
orem ipsum dolor sit ctetur adi pis cing elit nisl
Task / defectHard deadline(if applicable)Date when added to
board
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit
amet, co nse ctetur
orem ipsum dolor sit
amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
orem ipsum dolor sit amet, co nse ctetur
(description)
(description)
(description)Why
(description)
Who is analyzing / testing right now
= priority
= panic
What to pull first
xxxx kjd dj d xxx
Пример канбанHenrik Kniberg www.crisp.se/kanban/example
version 1.22009-11-16
(description)
orem ipsum dolor sit amet, co nse ctetur
2009-08-26
orem adi pis cing elit nisl
orem ipsum dolor sit amet, co nse ctetur
=task =defect
Внедрение
• Shu – следуй процессу• Ha – адаптируй• RI – забудь о процессе
Итог
• Scrum и Kanban – инструмент снижения рисков и повышения прозрачности
• Процесс может строиться в виде итераций либо потока
• Поток ограничивается для повышения пропускной способности либо по timebox либо по WIP
• Должен постоянно улучшаться, чтобы отвечать текущим реалиям
• Лучше начинать с «книжных вариантов» и потом адаптировать.
Материалы для изучения
• http://scrum.org.ua/scrum-i-xp-zametki-s-peredovoj/
• Succeeding with Agile by Mike Cohn
• Элияху Голдрат «Цель: процесс непрерывного совершествования»
Мэрри Поппиндик: «Бережливая разработка ПО»
Вопросы
• Детальнее на наших тренингахhttp://Scrumtrek.ru
• Конференции http://Agiledays.ru • Skype: nikita_filippov• @nfilippov• http://Blog.scrumtrek.ru • nfilippov@scrumtrek.ru
• Спасибо !