Введение в lean и agile

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%


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%


ТОП 5 ПРИЧИН УСПЕХА: 1. Вовлечение заказчика2. Поддерживающий менеджмент

от руководства3. Ясные бизнес цели4. Управление скоупом5. Гибкий процесс

СрокиСтоимость

Функциональность(features)

Quality

«Делая проекты итеративным процессом , решалось много проблем, которые не решал водопадный процесс требующий полное проектирование «СВЕРХУ»»

“Главная причина [для улучшений]что проекты стали меньшего размера.”

Не существует серебряной пули но Гибкие методологии очень близки к этому определению

Jim JohnsonГлава Standish Group

С чем приходилось бороться

• Требования меняются (change requests)• Качеством жертвуют • Люди увольняются• Системы невозможно поддерживать из-за

сильной зависимости человек-модуль/система

• Проблемы интеграции подсистем • Общаемся с заказчиком через документ

Agile разработка• Заказчик понимает о продукте по

мере самой разработки, как он должен выглядеть.

• Разработчики принимают решения о том, как разработать исходя из потребностей заказчика

• Все может меняться с течением времени

Взаимодействие и документация

Agile:

Манифест гибкой разработки

• Люди и взаимодействия важнее чем процессы и инструменты

• Работающий код важнее совершенной документации

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

• Реакция на изменения важнее следования плану

www.agilemanifesto.org

http://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

http://www.infoq.com/news/2010/08/agile-lean-validation-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

http://www.infoq.com/presentations/dancing-agile-elephant

http://www.infoq.com/presentations/dancing-agile-elephant

http://www.ademiller.com/tech/reports/agility_and_the_inconceivably_large.pdf

http://www.ademiller.com/tech/reports/agility_and_the_inconceivably_large.pdf

http://agilesoftwaredevelopment.com/files/Scrum%20in%20Multiproject%20Environment.pdf

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

http://weblogs.asp.net/jsemeniuk/archive/2008/01/03/lessons-learned-implementing-scrum-at-google.aspx



http://www.slideshare.net/yyeret/lean-conf-amdocs-case-study

http://www.slideshare.net/yyeret/lean-conf-amdocs-case-study

http://danube.com/docs/case_studies/Intel_case_study.pdf

http://danube.com/docs/case_studies/Intel_case_study.pdf

http://scrumtrek.ru/company/clients/

http://scrumtrek.ru/company/clients/

Цель 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

Работа

по приоритета

м

Работа внутри итерации: Доска задач

Daily SCRUM meeting

• Цель митинга: поделиться информацией• Не предназначен для решения проблем!• Его ведет один человек (ScrumMaster)• Аудитория – команда• Все проблемы становятся видны сразу• Вопросы

– Что ты сделал вчера?– Что ты будешь делать сегодня?– Какие у тебя проблемы?


Demo Демонстрация

SMART-цели

• Specific – Конкретный / Понятный• Measurable – Измеримый • Achievable – Достижимый • Relevant – Обоснованный / Соответствующий• Time-bound – Ограниченный по времени

KANBAN – ИНСТРУМЕНТ ДЛЯ НЕ ИТЕРАТИВНОЙ РАЗРАБОТКИ

Цели Kanban

• Визуализировать поток работ• Ограничить количество незавершенной

работы (работы в процессе)• Снизить среднее время выполнения задач• Искать потери, чтобы улучшать процесс

Баклог РазработкаОчередь Тестирование Готово!

2 3 2В прогрессе Готово

12

34

56

78

A10

11

PO



1

234

56

78

A10

11

PO



1

2

3

4

56

78

A10

11

PO



123

4

5

6

78

A10

11

PO

?



1

3

2

4

78

A10

11

PO ?5

6

1



3

2

478

A10

11

5

6

PO

1



3

247

8A10

11

5

6

PO



3

2478

A10

11

5

6

1PO

Поиск по вакансиям

Devprom:10241

Заказчик: Пупкин В.

Анализ: 11/03/11Разработка: 18/03/11Тест: 22/03/11

Срок: 24/03/11Приоритет:



1

2

3

4

5

6

7

AA

A

BUG

POА-а-а-а!!!

Анализ

6

BUG

– Баг из «СРОЧНО!»– Приоритетные– Риск нарушения сроков

– Остальные в порядке очередности поступления

ПРИОРИТЕТ Разработка

!

ДЕКОМПОЗИЦИЯ В KANBAN

АналитикаОчередь Разработка Тестирование2 3 2

В прогрессе Готово В прогрессе Готово В прогрессе Готово

2



2

BUG

BUG



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


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


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






amet, co nse ctetur


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)


2009-08-26

orem adi pis cing elit nisl


=task =defect

Внедрение

• Shu – следуй процессу• Ha – адаптируй• RI – забудь о процессе

Итог

• Scrum и Kanban – инструмент снижения рисков и повышения прозрачности

• Процесс может строиться в виде итераций либо потока

• Поток ограничивается для повышения пропускной способности либо по timebox либо по WIP

• Должен постоянно улучшаться, чтобы отвечать текущим реалиям

• Лучше начинать с «книжных вариантов» и потом адаптировать.

Материалы для изучения

• http://scrum.org.ua/scrum-i-xp-zametki-s-peredovoj/

http://scrum.org.ua/scrum-i-xp-zametki-s-peredovoj/

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 • [email protected]

• Спасибо !

http://Scrumtrek.ru/

http://Agiledays.ru/

http://Blog.scrumtrek.ru/

mailto:[email protected]

Введение в lean и agile

Technology