• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Введение в Lean и Agile
 

Введение в Lean и Agile

on

  • 11,134 views

Презентация Никиты Филиппова (Scrumtrek) с вебинара для сообщества Смартсорсинг (http://smartsourcing.ru/events/scrumwebinar072011)

Презентация Никиты Филиппова (Scrumtrek) с вебинара для сообщества Смартсорсинг (http://smartsourcing.ru/events/scrumwebinar072011)

Statistics

Views

Total Views
11,134
Views on SlideShare
5,544
Embed Views
5,590

Actions

Likes
5
Downloads
100
Comments
0

6 Embeds 5,590

http://smartsourcing.ru 4783
http://cherepnin.ru 788
http://yandex.ru 7
http://cloudforyou.ru 6
http://77.246.145.63 5
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Цель этой презентации показать как некоторые из этих вещей друг с другом сочетаются.Смысл пролететь над всеми современными практиками Agile и Lean, не ради того, чтобы вы побежали завтра делать все что здесь описано, но чтобы знали куда и как копать.
  • Both are incremental – break work into smaller piecesKanban teams try to minimize lead time and maximize flow, so that indirectly creates an incentive to break items into relatively small pieces. But no explicit rule. Can mix sizes.
  • TODO quicker animation

Введение в Lean и Agile Введение в Lean и Agile Presentation Transcript

  • Lean и Agile
    Никита Филиппов
  • Филиппов Никита
    ScrumTrek
    • Agile Coach
    • Управляющий партнер
    В прошлом
    • Программист, менеджер проектов, методолог
  • Agenda
    Мир современных процессов разработки ПО
    Проблемы в разработке ПО
    Lean
    Kanban
    Agile
    Scrum
  • Henrik Kniberg
    4
    Что это за фигня?
    TDD
    Scrum
    XP
    Continuous Integration
    Kanban
    Pair programming
    Refactoring
    Lean
    Agile
    RUP
  • Чему мы научились?
  • Каскадная модель (Waterfall)
    • Заказчик знает чего хочет
    • Разработчик знает, как разработать
    • Ничего не поменяется
  • Большинство проектов неуспешны
    Henrik Kniberg
    7
    The Standish Group исследовало более 40 000 проектов в течении 10 лет.
    Успешные проекты в 1994: 15%
    Среднее значение выхода за бюджет и сроки: ≈170%
    Успешные проекты в 2004: 34%
    Среднее значение выхода за бюджет и сроки: ≈70%
    План: €1,000,000
    Факт : €2,700,000
    План: €1,000,000
    Факт: €1,700,000
    Источник:
    http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish
    http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
  • Дефекты в самом процессе
    Влияние длины спецификации на сроки
    Влияние избыточной детализации на сроки
    Влияние изменения требований на сроки
    Влияние мнения со стороны на сроки со стороны
    Источник: 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
  • Чему мы научились
    Сроки
    Успешные проекты в 1994: 15%
    Среднее значение выхода за бюджет и сроки: ≈170%
    Успешные проекты в 2004: 34%
    Среднее значение выхода за бюджет и сроки: ≈70%
    Стоимость
    “Главная причина [для улучшений]что проекты стали меньшего размера.”
    Функциональность
    (features)
    «Делая проекты итеративным процессом , решалось много проблем, которые не решал водопадный процесс требующий полное проектирование «СВЕРХУ»»
    Jim Johnson
    Глава Standish
    Group
    ТОП 5 ПРИЧИН УСПЕХА:
    Вовлечение заказчика
    Поддерживающий менеджмент от руководства
    Ясные бизнес цели
    Управление скоупом
    Гибкий процесс
    Quality
    Не существует серебряной пули но Гибкие методологии очень близки к этому определению
  • С чем приходилось бороться
    Требования меняются (change requests)
    Качеством жертвуют
    Люди увольняются
    Системы невозможно поддерживать из-за сильной зависимости человек-модуль/система
    Проблемы интеграции подсистем
    Общаемся с заказчиком через документ
  • Agile разработка
    • Заказчик понимает о продукте по мере самой разработки, как он должен выглядеть.
    • Разработчики принимают решения о том, как разработать исходя из потребностей заказчика
    • Все может меняться с течением времени
  • Взаимодействие и документация
    Agile:
  • Манифест гибкой разработки
    Люди и взаимодействияважнее чем процессы и инструменты
    Работающий кодважнее совершенной документации
    Сотрудничество с заказчикомважнее контрактныхобязательств
    Реакция на измененияважнее следования плану
    www.agilemanifesto.org
  • Agile-подход
    Итеративность
    Движемся к цели короткими шагами
    Инкрементальность
    В конце каждой итерации законченный продукт
    Возможность получить обратную связь, скорректировать и обработать ожидания заказчика
  • Lean Бережливая разработка ПО
    Lean - aдаптацияTPS в США и Европе
    Бережливая разработка ПО – адаптация TPS в разработке ПО (и шире в ИТ)
    Мэри Поппендик
    Том Поппендик
  • Основные Принципы Лин
    Сформировать поток работ
    Контролировать объем единичной работы
    Снижать вариативность
    Ограничивать количество одновременно выполняющейся работы (WorkInProgress)
    Уничтожать потери
  • 7 потерь
  • Lean  Agile
    Lean
    Agile
    FDD, DSDM, OpenUP etc…
    Scrum
    XP
    Kanban
  • Материалы для изучения
  • Case studies
    http://www.infoq.com/news/2010/08/agile-lean-validation-studies
  • Agile World (1)
    IBM
    http://www.infoq.com/presentations/dancing-agile-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-amdocs-case-study
    Intel
    http://danube.com/docs/case_studies/Intel_case_study.pdf
  • 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 приоритезирует список
    Все могут добавлять элементы баклога
  • Процесс работы
  • Планирование релиза
  • Планирование релиза
  • Планирование релиза
  • Планирование релиза
  • Планирование релиза
    Планирование релиза
  • Velocity = 14
    Планирование релиза
    1
    2
    3
    4
  • Release BurnUp Chart
    Планирование релиза
    Предсказать,когдабудетвыполненобъемработ
  • Планирование итерации
  • Планированиеитерации
    Планирование итерации
    Planning Poker
    Backlog
  • TaskBoard
    Планирование итерации
  • Длительность итерации
    Количество задач
    ~20-40 задач
    Частота изменений требований
    За итерацию требования не меняются
    Возможность получить значимый результат
    ~10 Историй
    © ScrumTrek.ru, 2008
    Планирование итерации
  • Работа внутри итерации
  • Работа внутри итерации: Доска задач
    © scrumtrek.ru
    TO DO
    In progress
    Done
  • © scrumtrek.ru
    Работа внутри итерации: Доска задач
    TO DO
    In progress
    Done
    Работа по приоритетам
  • © ScrumTrek.ru, 2008
    Daily Scrum
    Скрам (стендап)
  • Daily SCRUMmeeting
    Скрам (стендап)
    Цель митинга: поделиться информацией
    Не предназначен для решения проблем!
    Его ведет один человек (ScrumMaster)
    Аудитория – команда
    Все проблемы становятся видны сразу
    Вопросы
    Что ты сделал вчера?
    Что ты будешь делать сегодня?
    Какие у тебя проблемы?
  • Скрам (стендап)
  • Demo
    Демонстрация
  • SMART-цели
    Specific – Конкретный / Понятный
    Measurable – Измеримый
    Achievable – Достижимый
    Relevant – Обоснованный / Соответствующий
    Time-bound – Ограниченный по времени
  • Kanban – инструмент для не итеративной разработки
  • Цели Kanban
    Визуализировать поток работ
    Ограничить количество незавершенной работы (работы в процессе)
    Снизить среднее время выполнения задач
    Искать потери, чтобы улучшать процесс
  • Баклог
    Разработка
    Очередь
    Тестирование
    Готово!
    2
    3
    2
    Впрогрессе
    Готово
    1
    2
    3
    4
    5
    6
    7
    8
    A
    10
    11
    PO
  • Баклог
    Разработка
    Очередь
    Тестирование
    Готово!
    2
    3
    2
    Впрогрессе
    Готово
    1
    3
    2
    4
    5
    6
    7
    8
    A
    10
    11
    PO
  • Баклог
    Разработка
    Очередь
    Тестирование
    Готово!
    2
    3
    2
    Впрогрессе
    Готово
    1
    3
    2
    4
    5
    6
    7
    8
    A
    10
    11
    PO
  • Баклог
    Разработка
    Очередь
    Тестирование
    Готово!
    2
    3
    2
    Впрогрессе
    Готово
    1
    3
    4
    2
    5
    6
    7
    8
    A
    10
    11
    PO
  • Баклог
    Разработка
    Очередь
    Тестирование
    Готово!
    2
    3
    2
    Впрогрессе
    Готово
    ?
    5
    1
    3
    2
    4
    6
    7
    8
    A
    10
    11
    PO
  • Баклог
    Разработка
    Очередь
    Тестирование
    Готово!
    2
    3
    2
    Впрогрессе
    Готово
    ?
    5
    1
    2
    4
    6
    3
    7
    8
    A
    10
    11
    PO
  • Баклог
    Разработка
    Очередь
    Тестирование
    Готово!
    2
    3
    2
    Впрогрессе
    Готово
    5
    1
    2
    6
    3
    7
    4
    8
    A
    10
    11
    PO
  • Баклог
    Разработка
    Очередь
    Тестирование
    Готово!
    2
    3
    2
    Впрогрессе
    Готово
    5
    1
    6
    3
    7
    4
    2
    8
    A
    10
    11
    PO
  • Баклог
    Разработка
    Очередь
    Тестирование
    Готово!
    2
    3
    2
    Впрогрессе
    Готово
    5
    1
    6
    3
    7
    4
    2
    8
    A
    10
    11
    PO
  • Devprom:10241
    Приоритет:
    Срок: 24/03/11
    Поиск по вакансиям
    Заказчик: Пупкин В.
    Анализ: 11/03/11
    Разработка: 18/03/11
    Тест: 22/03/11
  • Баклог
    Разработка
    Очередь
    Тестирование
    Готово!
    2
    3
    2
    Впрогрессе
    Готово
    BUG
    А-а-а-а!!!
    7
    1
    3
    5
    2
    6
    4
    A
    A
    A
    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
    Впрогрессе
    Готово
    Впрогрессе
    Готово
    Впрогрессе
    Готово
    BUG
    BUG
  • Пульс проекта: каденции
  • Каденции
    Итерации
    Sprint 2
    week 1
    week 2
    week 3
    week 4
    week 5
    week 6
    week 7
    week 8
    week 1
    week 2
    week 3
    week 4
    week 5
    week 6
    week 7
    week 8
    week 1
    week 2
    week 3
    week 4
    week 5
    week 6
    week 7
    week 8
    Sprint 1
    Review
    (release?)
    Plan & commit
    Retrospective
    Каденции
    Retrospectives (4w)
    Planning cadence (2w)
    Release cadence (1w)
    События
    Retrospectives (on demand)
    Planning (on demand)
    Release (on demand)
    By HenrikKniberg
  • Различные способы лимитировать WIP
    Velocity = 15 story points
    Scrum
    • Не указывается WIP
    • Таймбоксинг итерации
    Sprint 1
    Sprint 2
    Sprint 3
    Sprint 4
    Kanban
    • Указывается WIP
    • Можнокомбинировать большие и малые истории
    Big item
    Big item
    WIP limit = 3 items
  • Оценка
    ”типичный”
    Kanban
    Задачи
    Фичи
    1. Не оценивать. Просто посчитать.
    1. Без задач
    2. Не оценивать задачи, просто сосчитать
    2. Оценивать в T-shirt
    M
    S
    L
    M
    S
    L
    Часы?
    Дни?
    Недели?
    ”типичный”
    Scrum
    3. Оценивать в story-points
    3. Оценит задачи в днях
    2sp
    1d
    0.5d
    1sp
    2d
    5sp
    4. Оценить задачи в часах
    4. оценивать в идеальных человеко-днях
    12h
    4h
    3d
    8h
    1d
    6d
  • version 1.2
    2009-11-16
    Пример канбан
    Henrik Kniberg
    www.crisp.se/kanban/example
    Acceptance
    Analysis
    Development
    Prod
    Next
    2
    2
    3
    3
    2009-09-03
    2009-08-29
    2009-09-01
    2009-09-02
    2009-08-27
    2009-08-27
    2009-08-20
    2009-08-22
    2009-08-25
    2009-08-26
    2009-09-02
    2009-08-30
    2009-08-20
    2009-08-25
    2009-09-08
    Done
    Ongoing
    orem ipsum dolor sit amet, nse ctetur adi pis cing elit nisl
    orem ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl
    orem ipsum dolor sit amet, nse ctetur adi pis elit nisl
    ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl
    orem ipsum dolor sit amet, co nse
    orem ipsum dolor sit amet, ctetur adi pis cing elit nisl
    orem ipsum dolor sit amet, adi pis cing elit nisl
    orem olor sit amet, co nse ctetur adi pis cing elit nisl
    orem ipsum dolor sit amet, co adi pis cing elit nisl
    orem ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl
    orem ipsum dolor sit amet, co
    orem ipsum dolor sit ctetur adi pis cing elit nisl
    orem adi pis cing elit nisl
    Done
    Ongoing
    Done
    Ongoing
    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
    xxxx kjd dj d xxx
    orem ipsum dolor sit amet, co nse ctetur
    orem ipsum dolor sit amet, co nse ctetur
    Definition of Done:
    • Customer accepted
    • Ready for production
    Definition of Done:
    • Code clean & checked in on trunk
    • Integrated & regression tested
    • Running on UAT environment
    Definition of Done:
    • Goal is clear
    • First tasks defined
    • Story split (if necessary)
    Feature / story
    Task / defect
    What to pull first
    Hard deadline(if applicable)
    =task
    =defect
    • 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
    Date whenaddedto board
    (description)
    (description)
    = completed
    (description)
    = priority
    2009-08-20
    2009-09-30
    = blocked
    Why
    = panic
    (description)
    (description)
    = who is doing this right now
    Who is analyzing / testing right now
    (description)
  • Внедрение
    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
    Спасибо !