Применение Лин в масштабах предприятия<br />АсхатУразбаев<br />Agile Coach<br />ScrumTrek<br />
АсхатУразбаев<br />ScrumTrek<br /><ul><li>Agile Coach
Управляющий партнер</li></ul>В прошлом<br /><ul><li>Программист, менеджер проектов, методолог</li></li></ul><li>ЛИН тривиа...
ЛИН нетривиален<br />Большие проекты и продукты, <br />Распределенные команды, <br />Сложные взаимодействия, <br />Синхрон...
Супер-быстрая команда<br />Производительность команды вырастает<br />Дизайнеры не успевают предоставлять интерфейсы<br />Р...
Вы опять сделали не то! Переделывайте<br />Производительность команды вырастает<br />Аналитики/заказчик не умеют качествен...
Классическое проектное управление и пул ресурсов<br />Основная задача менеджера – выбить «ресурсы» на реализацию<br />Ресу...
Проектная разработка / командная разработка<br />
Оптимизация всего процесса<br />Сисадмин не может задеплоить продукт<br />Команда разработки ждет (6 человек)<br />Бизнес-...
Опыт Тойоты<br />
Производственная система Toyota<br />Развивалась с 1948 по 1975 на заводах Тойота. <br />С 2007 года Тойота – крупнейший п...
$1,000,000<br />
$1,000,000<br />
$1,000,000<br />
$1,000,000<br />
Характеристики массового производства<br />Громоздкое и дорогое оборудование<br />Склад готовых деталей<br />Перемещение д...
TaiichiOhno<br />Отец Toyota Production System<br />
3<br />
3<br />
Основа TPS – «вытягивание»<br />Меньше времени от заказа до продажи<br />Меньше запасов на складе <br />Канбан<br />Исполь...
Ответственность за процесс<br />перегрузка<br />неравномерность<br />потери<br />Выравнивай объем работ (хейдзунка)<br />
Встроенное качество (дзидока)<br />АНДОН<br />Сделай остановку производства с целью решения проблем частью производственно...
Текст<br />
Устранение потерь<br />Перепроизводство<br />Ожидание<br />Лишняя транспортировка<br />Излишняя обработка<br />Избыток зап...
используй визуальный контроль, чтобы ни одна проблема не осталась незамеченной<br />
Пять этапов Лин<br />
Пять этапов Лин<br />
Выстраивание последовательного потока создания ценности<br />От грустного заказчика до веселого заказчика<br />Эффективнос...
1 день<br />1 час<br />5 минут<br />2 недели<br />1 день<br />Технический анализ<br />Занести идею в SPS<br />Месячное пла...
7 потерь<br />
Недоделанная работа<br />Незапрограммированные требования<br />Неинтегрированный код<br />Нетестированный код<br />Недокум...
Ненужная функциональность<br />Функциональность, используемая в типичной системе<br />Standish Group Study Report<br />
Повторное изучение<br />Получение новой информации о продукте, коде, заказчике несет ценность для заказчика<br />Повторное...
Передача<br />Разделение <br />Ответственности<br />Знаний<br />Действий<br />Обратной связи<br />Самая распространенная п...
Переключение между задачами<br />
Ожидание<br />Ожидание согласования с заказчиком<br />Внутренние согласования<br />Бесполезные митинги<br />
Дефекты<br />ПОТЕРИ = ВЛИЯНИЕ ДЕФЕКТА *ВРЕМЯ ПОКА ДЕФЕКТ НЕ ОБНАРУЖЕН<br />Чем позже дефект найден, тем он дороже<br />
5 копеек про поток<br />Очень полезен!<br />Иногда выглядит тривиально<br />Выводы иногда понятны и без всякого построения...
1 день<br />1 час<br />5 дней<br />1 день<br />1 день<br />Выкладка на production<br />Идея<br />Разработка<br />5 дней / ...
Реальный пример<br />Начальник отдела документирования: «Я раньше техписом был. Теперь сделали меня начальником отдела док...
Кого на этом потоке НЕТ?<br />Это важнее измерения эффективности потока<br />Проверьте маркетологов<br />HR-ов<br />Архите...
В каких участники отношениях?<br />Цепочка должна быть непрерывной<br />Отношения внутри потока: заказчик-исполнитель<br />
Кто у кого заказывает работу?<br />Конечный пользователь<br />Менеджер продукта<br />Маркетинг<br />Разработчики<br />Архи...
Что тут делает ТАКАЯ ПРОРВА ЛЮДЕЙ?<br />Слишком длинная цепочка – потенциальный источник потерь<br />
Передача<br />Разделение <br />Ответственности<br />Знаний<br />Действий<br />Обратной связи<br />Самая распространенная п...
1 день<br />1 час<br />5 минут<br />2 недели<br />1 день<br />Технический анализ<br />Занести идею в SPS<br />Месячное пла...
Внедряем Agile<br />Внедрение «снизу» в большой компании<br />Итеративность, самоорганизация, ретроспективы, технические п...
1 день<br />1 час<br />5 минут<br />2 недели<br />1 день<br />Технический анализ<br />Занести идею в SPS<br />Месячное пла...
Feature Team<br />Команда, включающая всех специалистов  для решения проблемы заказчика<br />
1 день<br />1 час<br />5 минут<br />2 недели<br />1 день<br />Технический анализ<br />Занести идею в SPS<br />Месячное пла...
1 день<br />1 час<br />5 минут<br />2 недели<br />1 день<br />Технический анализ<br />Занести идею в SPS<br />Месячное пла...
1 день<br />1 час<br />5 минут<br />2 недели<br />1 день<br />Технический анализ<br />Занести идею в SPS<br />Месячное пла...
Пять этапов Лин<br />
Канбан<br />Разработка<br />Анализ<br />Backlog<br />Готово<br />5<br />3<br />Done<br />Ongoing<br />
Канбан+ Скрам<br />Анализ<br />Разработка<br />In progress<br />Next<br />Ready<br />In progress<br />ToDo<br />Done<br />...
Верстка и бэкенд<br />Выделение верстки и бекенда в последовательные стадии замедляет разработку<br />
«Сворачиваем» цепочку где можем!<br />Берем в команду<br />Аналитика<br />Разработчиков<br />Тестировщиков<br />Сисадминов...
Принцип ЛИН – минимизация Cycle Time<br />Минимизация времени цикла фичи ускоряет проект по закону Литтла<br />Увеличивает...
Низкий Cycle Time<br />Снижаем Cycle Time<br />Меньше Work In Progress<br />Малейшая проблема – застреваем<br />Меняется о...
Dancing Elephants<br />http://www.infoq.com/presentations/dancing-agile-elephant<br />
Способ выйти из зоны комфорта<br />Высокая прозрачность<br />Любая неоптимальность – все начнетбуксовать<br />Сотрудники и...
Pain = no motivation?<br />Так работать МЕНЕЕ комфортно и БОЛЕЕ интересно<br />Pain = motivation!<br />
Пример - баг в production<br />Баг в production<br />Работа останавливается<br />Пока баг не исправлен продолжать работу в...
Самая спорная потеря<br />Согласование требований это потеря<br />Работа по несогласованным требованиям это потеря<br />
Достигай консенсуса<br />Принимай решение не торопясь, на основе консенсуса, взвесив возможные варианты, внедряя его – не ...
Потери?<br />Backlogэто потери<br />Оценка это потери<br />
Пять этапов Лин<br />
Пример<br />Вы не знаете, где расположить блок с рекламой<br />Что делать? <br />
Пример<br />
От чего зависит ответ?<br />Имеете ли вы информацию для принятия решений?<br />Нет. Контролируемый эксперимент для получен...
Постоянный поиск новых знаний<br />
Команда обретает самосознание<br />Демо<br />Планирование<br />
Что говорит команда <br />
Принятие решений командой<br />Сдвигать уровень принятия решений как можно ниже<br />
Потери<br />Переделывать Wording<br />Переделывать функциональность<br />Исправлятьпроблемы с Usability<br />Исправлять вн...
Делать сразу правильно<br />Делать сразу правильно там, где информация доступна или ее можно получить<br />Разрабатывать п...
Уничтожение потерь<br />Это возможно, если<br />Научиться разбираться в бизнес-домене<br />Научиться разбираться в смежных...
К чему это приводит с практической точки зрения<br />Внятный Vision до начала разработки<br />Ready/ready – требования гот...
Определение ценности – важнейший элемент Лин<br />Постоянно продолжающийся и неустанный процесс<br />Создание баклога, при...
Этапы развития организации<br />
Пять этапов Лин<br />
Принципы лидерства<br />Ничто не заменит непосредственного наблюдения. <br />Изменения вводятся в режиме эксперимента. <br...
АсхатУразбаев<br />askhat@scrumtrek.ru<br />Twitter: zibsun<br />Skype: askhatu<br />ЖЖ: zibsun.livejournal.com<br />
Вопросы?<br />
Upcoming SlideShare
Loading in …5
×

Применение принципов Lean в масштабах предприятия

2,257 views

Published on

Слайды с конференции AgileDays-2011 о применении Лин http://agiledays.ru

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,257
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
76
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Применение принципов Lean в масштабах предприятия

  1. 1. Применение Лин в масштабах предприятия<br />АсхатУразбаев<br />Agile Coach<br />ScrumTrek<br />
  2. 2. АсхатУразбаев<br />ScrumTrek<br /><ul><li>Agile Coach
  3. 3. Управляющий партнер</li></ul>В прошлом<br /><ul><li>Программист, менеджер проектов, методолог</li></li></ul><li>ЛИН тривиален<br />Если отбросить «философию», все «реальные» практики ЛИН есть в Scrum, XP, Kanban<br />
  4. 4. ЛИН нетривиален<br />Большие проекты и продукты, <br />Распределенные команды, <br />Сложные взаимодействия, <br />Синхронизация программы проектов, <br />Работа всей организации<br />Сложные ситуации, там где Agileнапрямую не работает<br />
  5. 5. Супер-быстрая команда<br />Производительность команды вырастает<br />Дизайнеры не успевают предоставлять интерфейсы<br />Работают по несогласованным экранам<br />Много переделок<br />
  6. 6. Вы опять сделали не то! Переделывайте<br />Производительность команды вырастает<br />Аналитики/заказчик не умеют качественно продумывать требования<br />Обвиняют нижнего в иерархии ответственности <br />Команда виновата<br />
  7. 7. Классическое проектное управление и пул ресурсов<br />Основная задача менеджера – выбить «ресурсы» на реализацию<br />Ресурс «попилен» на проценты между несколькими проектами<br /> Проекты тянутся долго<br />
  8. 8. Проектная разработка / командная разработка<br />
  9. 9. Оптимизация всего процесса<br />Сисадмин не может задеплоить продукт<br />Команда разработки ждет (6 человек)<br />Бизнес-пользователи ждут (50 человек)<br />Конечные пользователи ждут (50000 человек)<br />Компания теряет деньги<br />У сотрудника FIN заказ серверов – низкоприоритетная задача<br />
  10. 10. Опыт Тойоты<br />
  11. 11. Производственная система Toyota<br />Развивалась с 1948 по 1975 на заводах Тойота. <br />С 2007 года Тойота – крупнейший производитель автомобилей в мире<br />Адаптирована американскими учеными под названием Lean Manufacturing (Бережливое производство) (1988)<br />Адаптирована к другим отраслям (медицина, логистика, почта, офис и так далее)<br />Адаптирована к разработке ПО <br />
  12. 12.
  13. 13. $1,000,000<br />
  14. 14. $1,000,000<br />
  15. 15. $1,000,000<br />
  16. 16. $1,000,000<br />
  17. 17. Характеристики массового производства<br />Громоздкое и дорогое оборудование<br />Склад готовых деталей<br />Перемещение деталей<br />Дефекты долго не обнаруживается<br />
  18. 18. TaiichiOhno<br />Отец Toyota Production System<br />
  19. 19. 3<br />
  20. 20. 3<br />
  21. 21.
  22. 22. Основа TPS – «вытягивание»<br />Меньше времени от заказа до продажи<br />Меньше запасов на складе <br />Канбан<br />Используй систему вытягивания, чтобы избежать перепроизводства<br />
  23. 23. Ответственность за процесс<br />перегрузка<br />неравномерность<br />потери<br />Выравнивай объем работ (хейдзунка)<br />
  24. 24. Встроенное качество (дзидока)<br />АНДОН<br />Сделай остановку производства с целью решения проблем частью производственной культуры, если того требует качество<br />
  25. 25. Текст<br />
  26. 26. Устранение потерь<br />Перепроизводство<br />Ожидание<br />Лишняя транспортировка<br />Излишняя обработка<br />Избыток запасов<br />Лишние движения<br />Дефекты<br />Нереализованный творческий потенциал сотрудников.<br />Процесс в виде непрерывного потока способствует выявлению проблем<br />
  27. 27. используй визуальный контроль, чтобы ни одна проблема не осталась незамеченной<br />
  28. 28. Пять этапов Лин<br />
  29. 29. Пять этапов Лин<br />
  30. 30. Выстраивание последовательного потока создания ценности<br />От грустного заказчика до веселого заказчика<br />Эффективность цикла = полезная работа / полное время<br />Создаем совместно со ВСЕМИ заинтересованными лицами<br />
  31. 31. 1 день<br />1 час<br />5 минут<br />2 недели<br />1 день<br />Технический анализ<br />Занести идею в SPS<br />Месячное планирование<br />3 дня<br />3 дней<br />3 дня<br />2 недели<br />Backend Dev<br />FrontEnd Dev<br />2 день<br />30 минут<br />1 день<br />1 неделя<br />Test<br />Deploy<br />8 дней / 38 дней = 21%<br />
  32. 32. 7 потерь<br />
  33. 33. Недоделанная работа<br />Незапрограммированные требования<br />Неинтегрированный код<br />Нетестированный код<br />Недокументированный код<br />Незадеплоеный код<br />
  34. 34. Ненужная функциональность<br />Функциональность, используемая в типичной системе<br />Standish Group Study Report<br />
  35. 35. Повторное изучение<br />Получение новой информации о продукте, коде, заказчике несет ценность для заказчика<br />Повторное изучение – потери <br />
  36. 36. Передача<br />Разделение <br />Ответственности<br />Знаний<br />Действий<br />Обратной связи<br />Самая распространенная проблема – разделение принятие решений и ответственности <br />
  37. 37. Переключение между задачами<br />
  38. 38. Ожидание<br />Ожидание согласования с заказчиком<br />Внутренние согласования<br />Бесполезные митинги<br />
  39. 39. Дефекты<br />ПОТЕРИ = ВЛИЯНИЕ ДЕФЕКТА *ВРЕМЯ ПОКА ДЕФЕКТ НЕ ОБНАРУЖЕН<br />Чем позже дефект найден, тем он дороже<br />
  40. 40. 5 копеек про поток<br />Очень полезен!<br />Иногда выглядит тривиально<br />Выводы иногда понятны и без всякого построения потока <br />(если вы только не закоренелый “вотерфольщик”)<br />
  41. 41. 1 день<br />1 час<br />5 дней<br />1 день<br />1 день<br />Выкладка на production<br />Идея<br />Разработка<br />5 дней / 7 дней = 71%<br />Code &Fix<br />Переключение контекста, лишняя работа, повторное изучение, дефекты<br />Идея <br />???<br />PROFIT!<br />
  42. 42. Реальный пример<br />Начальник отдела документирования: «Я раньше техписом был. Теперь сделали меня начальником отдела документирования. Я должен заставлять разработчиков писать техническую документацию к продукту. Иначе потом будет очень много проблем у команды поддержки. Проблемы? Разработчики не хотят писать документацию! Еще мне трудно сформулировать требования к схеме развертывания, я в этом далеко не спец»<br />В чем причина проблем и как их можно исправить? <br />
  43. 43. Кого на этом потоке НЕТ?<br />Это важнее измерения эффективности потока<br />Проверьте маркетологов<br />HR-ов<br />Архитекторов<br />Сервисные команды/компонентные команды<br />И просто Важные Принимающие Решения Шишки<br />Чем они все занимаются?<br />
  44. 44. В каких участники отношениях?<br />Цепочка должна быть непрерывной<br />Отношения внутри потока: заказчик-исполнитель<br />
  45. 45. Кто у кого заказывает работу?<br />Конечный пользователь<br />Менеджер продукта<br />Маркетинг<br />Разработчики<br />Архитектор<br />Поддержка (support)<br />HR-менеджер<br />
  46. 46. Что тут делает ТАКАЯ ПРОРВА ЛЮДЕЙ?<br />Слишком длинная цепочка – потенциальный источник потерь<br />
  47. 47. Передача<br />Разделение <br />Ответственности<br />Знаний<br />Действий<br />Обратной связи<br />Самая распространенная проблема – разделение принятие решений и ответственности <br />
  48. 48. 1 день<br />1 час<br />5 минут<br />2 недели<br />1 день<br />Технический анализ<br />Занести идею в SPS<br />Месячное планирование<br />3 дня<br />3 дней<br />3 дня<br />2 недели<br />Backend Dev<br />FrontEnd Dev<br />2 день<br />30 минут<br />1 день<br />1 неделя<br />Test<br />Deploy<br />8 дней / 38 дней = 21%<br />
  49. 49. Внедряем Agile<br />Внедрение «снизу» в большой компании<br />Итеративность, самоорганизация, ретроспективы, технические практики и т.д.<br />
  50. 50. 1 день<br />1 час<br />5 минут<br />2 недели<br />1 день<br />Технический анализ<br />Занести идею в SPS<br />Месячное планирование<br />3 дня<br />3 дней<br />2недели<br />2 недели<br />Backend Dev<br />FrontEnd Dev<br />2 день<br />30 минут<br />2 недели<br />2 недели<br />Test<br />Deploy<br />8 дней / 70 дней = 11%<br />
  51. 51. Feature Team<br />Команда, включающая всех специалистов для решения проблемы заказчика<br />
  52. 52. 1 день<br />1 час<br />5 минут<br />2 недели<br />1 день<br />Технический анализ<br />Занести идею в SPS<br />Месячное планирование<br />3 дня<br />3 дней<br />3 дня<br />2 недели<br />Backend Dev<br />FrontEnd Dev<br />2 день<br />30 минут<br />1 день<br />1 неделя<br />Test<br />Deploy<br />8 дней / 38 дней = 21%<br />
  53. 53. 1 день<br />1 час<br />5 минут<br />2 недели<br />1 день<br />Технический анализ<br />Занести идею в SPS<br />Месячное планирование<br />5 дней<br />2 дня<br />2 недели<br />Dev/Test<br />Test<br />30 минут<br />1 день<br />Deploy<br />8 дней / 30 дней = 26%<br />
  54. 54. 1 день<br />1 час<br />5 минут<br />2 недели<br />1 день<br />Технический анализ<br />Занести идею в SPS<br />Месячное планирование<br />5 дней<br />2 дня<br />Dev/Test<br />Test<br />30 минут<br />1 день<br />Deploy<br />8 дней / 20 дней = 40%<br />
  55. 55. Пять этапов Лин<br />
  56. 56. Канбан<br />Разработка<br />Анализ<br />Backlog<br />Готово<br />5<br />3<br />Done<br />Ongoing<br />
  57. 57. Канбан+ Скрам<br />Анализ<br />Разработка<br />In progress<br />Next<br />Ready<br />In progress<br />ToDo<br />Done<br />3<br />Scrum<br />
  58. 58. Верстка и бэкенд<br />Выделение верстки и бекенда в последовательные стадии замедляет разработку<br />
  59. 59. «Сворачиваем» цепочку где можем!<br />Берем в команду<br />Аналитика<br />Разработчиков<br />Тестировщиков<br />Сисадминов<br />
  60. 60. Принцип ЛИН – минимизация Cycle Time<br />Минимизация времени цикла фичи ускоряет проект по закону Литтла<br />Увеличивает накладные расходы<br />Зачем ЕЩЕ нужно минимизировать время цикла?<br />
  61. 61. Низкий Cycle Time<br />Снижаем Cycle Time<br />Меньше Work In Progress<br />Малейшая проблема – застреваем<br />Меняется отношение к проблемам<br />
  62. 62. Dancing Elephants<br />http://www.infoq.com/presentations/dancing-agile-elephant<br />
  63. 63. Способ выйти из зоны комфорта<br />Высокая прозрачность<br />Любая неоптимальность – все начнетбуксовать<br />Сотрудники исправят процесс<br />Pain = no motivation?<br />
  64. 64. Pain = no motivation?<br />Так работать МЕНЕЕ комфортно и БОЛЕЕ интересно<br />Pain = motivation!<br />
  65. 65. Пример - баг в production<br />Баг в production<br />Работа останавливается<br />Пока баг не исправлен продолжать работу в итерации нельзя<br />
  66. 66. Самая спорная потеря<br />Согласование требований это потеря<br />Работа по несогласованным требованиям это потеря<br />
  67. 67. Достигай консенсуса<br />Принимай решение не торопясь, на основе консенсуса, взвесив возможные варианты, внедряя его – не медли (немаваси)<br />Работает в области технических решений<br />В области избытка информации<br />В бизнесе работает НЕ ВСЕГДА<br />
  68. 68. Потери?<br />Backlogэто потери<br />Оценка это потери<br />
  69. 69. Пять этапов Лин<br />
  70. 70. Пример<br />Вы не знаете, где расположить блок с рекламой<br />Что делать? <br />
  71. 71. Пример<br />
  72. 72. От чего зависит ответ?<br />Имеете ли вы информацию для принятия решений?<br />Нет. Контролируемый эксперимент для получения знаний<br />Да. Анализ, расчет и валидация результатов<br />
  73. 73. Постоянный поиск новых знаний<br />
  74. 74. Команда обретает самосознание<br />Демо<br />Планирование<br />
  75. 75. Что говорит команда <br />
  76. 76. Принятие решений командой<br />Сдвигать уровень принятия решений как можно ниже<br />
  77. 77. Потери<br />Переделывать Wording<br />Переделывать функциональность<br />Исправлятьпроблемы с Usability<br />Исправлять внешний дизайн<br />… <br />
  78. 78. Делать сразу правильно<br />Делать сразу правильно там, где информация доступна или ее можно получить<br />Разрабатывать пробный вариант там, где информации недостаточно или она в принципе недоступна<br />Везде, где можно, добывать новую информацию<br />
  79. 79. Уничтожение потерь<br />Это возможно, если<br />Научиться разбираться в бизнес-домене<br />Научиться разбираться в смежных с разработкой областях (например, UX)<br />Учить заказчика взаимодействовать с командой<br />Свободно обмениваться информацией внутри команды и с заказчиком<br />
  80. 80. К чему это приводит с практической точки зрения<br />Внятный Vision до начала разработки<br />Ready/ready – требования готовы к началу итерации<br />Вовлечение команды в подготовку требований<br />
  81. 81. Определение ценности – важнейший элемент Лин<br />Постоянно продолжающийся и неустанный процесс<br />Создание баклога, приоритезация и т.д. – часть процесса понимания ценности заказчика<br />
  82. 82. Этапы развития организации<br />
  83. 83. Пять этапов Лин<br />
  84. 84. Принципы лидерства<br />Ничто не заменит непосредственного наблюдения. <br />Изменения вводятся в режиме эксперимента. <br />Как можно больше экспериментов. <br />Менеджер не решает проблем, а учит этому других.<br />Воспитывай лидеров, которые досконально знают свое дело, исповедуют философию компании и могут научить этому других<br />
  85. 85. АсхатУразбаев<br />askhat@scrumtrek.ru<br />Twitter: zibsun<br />Skype: askhatu<br />ЖЖ: zibsun.livejournal.com<br />
  86. 86. Вопросы?<br />

×