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