Uploaded byReturn on Intelligence
Lean Software Development
Документ освещает принципы бережливого производства (БП) и их применение в разработке программного обеспечения, подчеркивая важность устранения потерь и постоянного совершенствования. Основные методы, такие как канбан и метод «пять почему», используют для повышения эффективности процессов разработки. Также обсуждаются проблемы, приводящие к провалам проектов, и предложены метрики для оценки бережливой разработки.
More Related Content
Similar to Lean Software Development
Lean Software Development
- 1. Core Systems TransformationSolutions Lean Software Development Мордвинов Олег 2015
- 2. 1 Return on Intelligence,Inc. ©2014 All Rights Reserved. Содержание Причины провалов проектов по разработке ПО Происхождение концепции «бережливого производства» (БП) Принципы БП Применение принципов БП к процессу разработки ПО • Устранять потери • Делать правильно с первого раза • Поддерживать тех, кто создаёт ценность • Культура постоянного совершенствования (Кайдзен) • Метод «Защита от дурака» • Вытягивать спросом (Канбан) • Метод «Пять почему» Метрики бережливой разработки
- 3. 2 Return on Intelligence,Inc. ©2014 All Rights Reserved. Часто и неожиданно изменяющиеся требования заказчика Централизованное принятие решений Жесткое управление объёмом работ по проекту Накопленный технический долг Причины провалов проектов по разработке ПО
- 4. 3 Return on Intelligence,Inc. ©2014 All Rights Reserved. Происхождение концепции «бережливого производства» 無駄 (му́да) - затраты, потери, мусор 無理 (му́ри) - перегрузка 斑 (му́ ра) - неравномерность lean production, lean manufacturing - «тощее» производство
- 5. 4 Return on Intelligence,Inc. ©2014 All Rights Reserved. Происхождение концепции «бережливого производства» Тайити Оно, создатель производственной системы в Toyota Сигео Синго, создатель концепций «защита от дурака» и SMED (Single-Minute Exchange of Dies, метод быстрой переналадки)
- 6. 5 Return on Intelligence,Inc. ©2014 All Rights Reserved. Lean в России
- 7. 6 Return on Intelligence,Inc. ©2014 All Rights Reserved. Принципы бережливого производства Создавать ценность и ничего более • Устранять потери • Сокращать уровень запасов • Делать качественно с первого раза Акцент на тех, кто добавляет ценность • Поддерживать (назначать, поощрять) тех, кто добавляет ценность • Постоянно совершенствоваться Вытягивать ценность •Соответствовать требованиям потребителей •Вытягивать спросом (ориентируясь на спрос) •Улучшать поток создания ценности Помогать окружающим в оптимизации •Запрет локальной оптимизации •Партнерство с поставщиками
- 8. 7 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО 1. Перепроизводство 2. Излишние запасы 3. Излишняя обработка 4. Ненужные перемещения 5. Выпуск дефектной продукции 6. Ожидание 7. Ненужная транспортировка 1. Экстра функциональность 2. Излишние требования 3. Дополнительные шаги разработки 4. Поиск информации 5. Баги 6. Ожидание решений, ожидание клиентов 7. Передача требований, знаний Устранять потери Lean Software Development:Lean Manufacturing: 7 видов потерь
- 9. 8 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Устранять потери Пример цепочки формирования ценности процесса устранения дефекта
- 10. 9 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Гибкая архитектура Юнит и регрессионное тестирование Рефакторинг Делать правильно с первого раза
- 11. 10 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Делегирование Люди и взаимодействие нежели документы и процессы Кросс-функциональные команды Поддерживать тех, кто добавляет ценность
- 12. 11 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Создавать культуру постоянного совершенствования: Кайдзен 改善 (кайдзэн) - непрерывное совершенствование
- 13. 12 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Создавать культуру постоянного совершенствования: Кайдзен Командная работа Персональная дисциплина Моральное состояние Кружки качества Предложения по улучшению Элементы Кайдзен:
- 14. 13 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Создавать культуру постоянного совершенствования: Кайдзен Принципы Кайдзен:
- 15. 14 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Создавать культуру постоянного совершенствования: Кайдзен Организация рабочего места Принципы Кайдзен:
- 16. 15 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Создавать культуру постоянного совершенствования: Кайдзен
- 17. 16 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Создавать культуру постоянного совершенствования: Кайдзен Организация рабочего места Устранение неоправданных потерь Принципы Кайдзен:
- 18. 17 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Создавать культуру постоянного совершенствования: Кайдзен Организация рабочего места Устранение неоправданных потерь Стандартизация Принципы Кайдзен:
- 19. 18 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Plan Do Check Act Создавать культуру постоянного совершенствования: Кайдзен
- 20. 19 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Создавать культуру постоянного совершенствования: Кайдзен Применение Кайдзен: Постоянные команды Команды по решению возникших проблем Кросс-функциональные команды Команды по реализации решений Малые группы
- 21. 20 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Принцип «Защита от дурака»
- 22. 21 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Принцип «Защита от дурака» Уровни защиты: I. Обнаружение несоответствий
- 23. 22 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Принцип «Защита от дурака» Уровни защиты: II. Недопущение несоответствия
- 24. 23 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Принцип «Защита от дурака» Уровни защиты: III. Конструкционная защита
- 25. 24 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Вытягивать спросом: Канбан 看板 (канбан) - рекламный щит, вывеска, сигнал дословный перевод: “кан” - видимый, визуальный “бан” - карточка или доска
- 26. 25 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Вытягивать спросом: Канбан Визуализация производства Ограничение WIP на каждом этапе производства Постоянная оптимизация процесса Правила Канбан:
- 27. 26 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Вытягивать спросом: Канбан
- 28. 27 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Метод «Пять почему» Формулировка проблемы Определение причин «Почему это произошло?» для каждой из причин Проверка возможности детализации каждой из причин Определение ключевых причин
- 29. 28 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Метод «Пять почему» Почему? – Не работает функционал, который работал в предыдущей версии Почему? – Новый код «сломал» старый Почему? – Не проверено влияние нового функционала на старый Почему? – Не было проведено регрессионное тестирование Почему? – Регрессионное тестирование не внедрено на проекте Пример: продукт не работает после поставки заказчику
- 30. 29 Return on Intelligence,Inc. ©2014 All Rights Reserved. Применение принципов БП к разработке ПО Метод «Пять почему» Достоинства: • Один из простейших инструментов • Помогает установить первопричину проблемы • Определяет взаимосвязи между различными причинами проблемы Недостатки: • Чем более глубокую проблему мы находим, тем сложнее ее решить • В некоторых случаях требуются существенные финансовые вложения и пересмотр устоявшихся правил и подходов к работе
- 31. 30 Return on Intelligence,Inc. ©2014 All Rights Reserved. Метрики бережливой разработки Cycle time Work in progress (WIP) Lead time Wasted time Effectiveness Throughput
- 32. 31 Return on Intelligence,Inc. ©2014 All Rights Reserved. Спасибо! Oleg Mordvinov Project Manager Pulkovskoe shosse 40/4 Saint Petersburg, 196158 Russia oleg.mordvinov@returnonintelligence.com Вопросы?
Editor's Notes
- #3 Сначала кратко рассмотрим основные причины провалов проектов, потому что это поможет лучше понять, зачем нам нужно внедрять и использовать бережливую разработку, и как она помогает избежать нижеперечисленных проблем.
- #4 Часто и неожиданно изменяющиеся требования заказчика Проблема стандартного подхода к разработке программного обеспечения лежит в предположении, что требования заказчика неизменны и могут быть идентифицированы заранее. Но поскольку требования меняются достаточно часто в течение жизни большинства систем, они не всегда могут быть адекватно отражены с помощью жесткого, негибкого дизайна системы. С другой стороны, если изменения разрешены в течение проекта, у компании будут проблемы с поставкой ПО согласно основной линии проекта. Централизованное принятие решений Крупные компании по разработке программного обеспечения до сих пор используют традиционный директивный подход при принятии решений. Каждый раз, когда решение принимается, оно должно пройти весь путь с самой верхушки организационной структуры проекта к конечным исполнителям. Такой подход увеличивает время разработки и делает весь процесс негибким и медленным. Жесткое управление объёмом работ по проекту Удержание проекта в рамках, согласованных на начальной стадии, приносит мало пользы заказчикам, требования которых изменяются. В действительности такой подход только сеет тревогу и парализует способность принимать решения, обеспечивая лишь то, что система будет частично устаревшей к моменту её запуска. Таким образом, управление работами, которые не нужны заказчику, являются прямыми потерями времени и ресурсов. Тем не менее, до тех пор, пока ограничение проекта своим изначальным объёмом работ будет ключевой задачей менеджера, локальная оптимизация будет процветать за счет качества всего проекта. Накопленный технический долг Большинство проблем с качеством при разработке программных компонентов возникает из-за того, что разработка продолжается даже тогда, когда существуют проблемы с качеством («баги»). В результате накапливаются баги или технический долг, как следствие – к завершению проекта уже нет времени закрывать такие долги. Принципы бережливого производства, о которых я расскажу чуть дальше, могут использоваться как основа или руководство для решения большинства проблем в мире разработки программного обеспечения
- #5 Отправная точка концепции — оценка ценности продукта для конечного потребителя, на каждом этапе его создания. В качестве основной задачи предполагается создание процесса непрерывного устранения потерь, то есть устранение любых действий, которые потребляют ресурсы, но не создают ценности (не являются важными) для конечного потребителя. Первые три термина происходят из производственной системы компании Toyota, которая была создана в 50-е годы прошлого века. Американские специалисты изучили систему и концептуализировали под наименованием lean production (lean manufacturing), термин «lean» был впервые предложен Джоном Крафчиком в 1988 году, до этого использовался термин «тойотизм». Сначала концепцию бережливого производства применяли в отраслях с дискретным производством, прежде всего в автомобилестроении. Затем концепцию адаптировали к условиям процессного производства. Позднее идеи «бережливого производства» стали применяться в торговле, сфере услуг, коммунальном хозяйстве, здравоохранении, системе образования, вооружённых силах, секторе государственного управления и во многих других видах деятельности.
- #6 Основателем концепции «бережливого производства» считается Тайити Оно, создававший производственную систему в Toyota в 1950-е годы. Значительный вклад в развитие теории и практики бережливого производства внёс коллега и помощник Тайити Оно — Сигео Синго, создавший в числе прочего метод быстрой переналадки (SMED). И если Тайити Оно знал что нужно для устранения потерь, Сигео Синго знал как это осуществить. Впервые методология «Бережливая разработка ПО» была освещена в одноимённой книге (англ. Lean Software Development) Мэри Поппендик и Toма Поппендика. В книге представлены традиционные принципы бережливого производства применительно к разработке программного обеспечения, также набор из практик и их сравнение с гибкой методологией разработки.
- #7 Карта распространенности бережливого производства на сентябрь 2015 года. На карте обозначены предприятия, где применяются методы и инструменты бережливого производства.
- #9 В основном принципы бережливого производства могут быть применены к разработке программного обеспечения для решения существующих проблем и улучшения самого процесса. Перепроизводство Перепроизводство == расточительство. Распознавание расточительства основано на понимании кризисного положения –анализируется все, что простаивает, не работает, независимо от того, идет ли речь о людях, информации или механическом оборудовании. --Методы устранения: MVP (Most Valuable Part), приоритизация задач Излишние запасы Наличие любых, кроме минимально необходимых, запасов. Ненужное складирование и слишком большие запасы являются замораживанием капитала. Запасы требуют расходы на хранение, порождают плохое качество, требуют площади, время на поиски, скрывают простои и т.д. --Методы устранения: конкретизация требований, MVP, расстановка приоритетов Излишняя обработка На практике причинами являются несовершенная технология, плохая организация процесса, недостаточно понятные для разработчиков требования. --Методы устранения: совершенствование технологий, процесса, уточнение требований Ненужные перемещения Чаще всего это ненужное перемещение людей в ходе работы (например, в поисках деталей, инструментов, документов, помощи и пр.). --Методы устранения: стандартизация работ, повышение квалификации, создание общей базы знаний (например, wiki) Выпуск дефектной продукции Дефектная продукция требует дополнительного контроля, дополнительной транспортировки, дополнительной доработки, дополнительного рабочего места. --Методы устранения: юнит и регрессионное тестирование. Использование юнит-тестов _без перепроизводства_. Ожидание Примеры: ожидание из-за простоя, ожидание контроля качества, ожидание предшествующих или последующих технологических процессов, ожидание информации. --Методы устранения: proxy-product owner, on-side customer Ненужная транспортировка Ненужная транспортировка материалов или информации. Движение материала не создает ценности. Передача требований, знаний, развертывание систем --Методы устранения: создание и совместное использование хранилищ для проектной документации (wiki), систем планирования и контроля (Jira, V1)
- #10 При использовании цепочек формирования ценности рекомендуется измерять продуктивное время и потери (затраченное время минус продуктивное время). В этом примере продуктивное время исправления дефекта составляет в среднем 4.24 часа, а затраченное – 16.25 часа, т.е. 12 часов составляют потери. Один из способов экономии времени – acceptance тесты для разработчика.
- #11 «Делать правильно с первого раза» не означает «заморозить спецификацию». Наоборот, требования (спецификация) к системе постоянно изменяются. Дисциплина бережливого производства требует мгновенной адаптации к изменяющимся условиям рынка и требованиям заказчика. Правило «делать правильно с первого раза» часто используется для того, чтобы оправдать разработку детальной спецификации перед написанием кода, но это неверно. Точно так же, как бережливое производство встраивает проверку качества в производственный процесс для определения того, когда процесс нарушен, бережливая разработка должна «встраивать тесты» на различных стадиях процесса разработки. В случае, если происходят изменения во время разработки, необходимо использовать юнит и регрессионное тестирование. Если тесты не проходят удачно, программирование должно быть остановлено до тех пор, пока проблема не будет обнаружена и исправлена. Всеобъемлющее тестирование – лучший способ быть готовым к изменениям в течение процесса разработки. Также покрытие юнит-тестами должно быть достаточным, но без перепроизводства. Если мы принимаем за аксиому, что клиенты могут не знать, что они хотят в начале процесса разработки и что их требования могут измениться, мы должны встроить в процесс разработки возможность получения обратной связи от клиента. Это лучше всего реализуется с помощью гибкой архитектуры, которая позволяет системе легко приспосабливаться к изменениям, а также технологии мониторинга, определяющей ошибки перед тем, как они происходят, и тестов разработанных перед началом разработки. Архитектура строится постепенно и через постоянный рефакторинг. Рефакторинг помогает сфокусироваться на изначальном дизайне и текущих возможностях системы, нежели на функциональности, которая может гипотетически понадобиться в будущем. Далее, используя технику рефакторинга, можно добавлять дополнительные характеристики, когда они потребуются, позволяя легко приспосабливать к будущему, когда оно становится настоящим. Рефакторинг проводится постоянно, но маленькими шагами.
- #12 Базовый принцип бережливого производства — это делегирование полномочий и права принимать решения на по возможности нижний уровень организационной структуры. Часто, когда проект по разработке ПО не справляется со своими задачами, интуитивной реакцией менеджмента является установление более жестких процессов, которые с большой детальностью указывают людям как, они должны делать свою работу. Принцип бережливого производства предлагает абсолютно противоположный подход. Бережливое производство ставит на первое место людей и командное взаимодействие, нежели бумажную работу и процессы. Оно фокусируется на методах формирования и поддержки команд в их стремлении находить и решать собственные проблемы, признавая, что люди выполняющие работу, должны сами определить детали выполнения работы. Люди – это не просто ресурс. Разработка программного обеспечения включает в себя передачу информации, как минимум один раз (от пользователя разработчику) но, как правило, более одного раза (от пользователя дизайнеру (аналитику), от дизайнера разработчику). При этом традиционный подход предполагает, что лучше всего передавать всю подобную информацию в письменном виде. В свою очередь бережливый подход предполагает, что наиболее эффективно создавать небольшие кросс-функциональные команды, которые работают сквозь информационные границы, тем самым уменьшая бумажную работу и улучшая коммуникацию. Кросс-функциональная команда – это самодостаточная команда, которая может выполнить все задачи в рамках проекта. Определение: Кросс-функциональная команда ( т.е. коллектив с перекрестной ответственностью) - это группа сотрудников из различных функциональных подразделений организации, которые все фокусируются на определенной цели и должны работать как единая команда для улучшения координации между отделами, введения инноваций и решения насущных проблем. Наличие в проектной команде специалистов с различным опытом и знаниями позволяет максимально полно и подробно рассмотреть и проанализировать задачу, ее потенциальные выгоды и риски, а также выбрать оптимальный вариант решения.
- #13 Кайдзен (kaizen) – это один из подходов к улучшению работы организации. Этот термин появился в Японии и стал обозначать систему взаимосвязанных действий, приводящих к повышению качества продукции, процессов и системы управления. В современном понимании кайдзен - это система непрерывного улучшения качества, технологий, процессов, корпоративной культуры, производительности труда, надежности, лидерства и других аспектов деятельности компании. Основной фокус внимания система кайдзен направляет на «качество» персонала, потому что именно от персонала зависит качество выпускаемой продукции и услуг. Эта система вовлекает в процесс улучшения каждого работника – от руководителя самого верхнего звена, до рядового сотрудника. Улучшая стандартизованные действия и процессы, цель кайдзен — производство без потерь. В основе системы кайдзен находятся 5 ключевых элементов. Чтобы она могла нормально работать, и быть эффективным инструментом повышения качества, в организации необходимо создать условия для их реализации.
- #14 Первый элемент – командная работа. Все сотрудники должны работать как одна команда для достижения общей цели и желаемого улучшения в работе. Сотрудники всех уровней должны делать все возможное для блага своих коллег и компании. Работа в команде предполагает постоянный обмен информацией, взаимное обучение, своевременное выполнение своих обязанностей и прочее. Второй элемент – персональная дисциплина. Дисциплина имеет первостепенное значение для достижения успеха. Кайдзен требует чтобы каждый сотрудник повышал свою самодисциплину во всех аспектах труда – управлении своим временем, качеством исполнения работы, соблюдении требований и регламентов, расходовании материальных и финансовых ресурсов и пр. Третий элемент – моральное состояние. Независимо от того, удается компании добиться успеха в реализации изменений или нет, персонал должен стремиться сохранить высокий моральный дух. Высшее руководство должно внедрить в практику работы различные мотивационные инструменты, такие как хорошие условия труда, учет заслуг, система поощрений и вознаграждений, оплачиваемый отпуск, пособия, оплата медицинских услуг, предоставление работникам кредитов и пр. Четвертый элемент – кружки качества. Это один из принципиальных элементов системы кайдзен. В организации необходимо организовать работу кружков качества. В состав этих кружков должны входить работники разного уровня. В кружках качества сотрудники имеют возможность обмениваться идеями, навыками, технологиями и другими важными для совместной работы ресурсами. Обмен информацией и взаимодействие в рамках кружков качества позволяет сотрудникам оценивать эффективность своей работы на основе сравнения с работой других, и тем самым пытаться улучшить свою деятельность. Пятый элемент – предложения по улучшению. Необходимо дать сотрудникам возможность свободно предлагать улучшения независимо от ранга, занимаемого в системе управления. Предложения сотрудников могут быть любыми, даже абсурдными, и все они должны быть учтены и рассмотрены. Каждый сотрудник организации предлагает небольшие улучшения на регулярной основе. Предложения делаются не эпизодически в течении месяца или года, а постоянно. В большинстве своем они не носят глобального характера, а являются незначительными усовершенствованиями. _В этом и заключается суть системы кайдзен_ – большое количество малых, незначительных улучшений приводит к существенному улучшению качества. Предложения по улучшению, которые вносят сотрудники, могут не ограничиваться какой-то конкретной областью, например, производством или маркетингом. Кайдзен основана на внесение изменений везде, где можно добиться улучшений.
- #16 Организация рабочего места – это управление рабочим местом с целью оптимизации деятельности. Кайдзен уделяет этому большое внимание. Для правильной организации рабочего места применяются соответствующие инструменты управления, которые получили название 5S методология.
- #17 5S — это пять японских слов или 5 Шагов : «сортировка» (нужное-ненужное) — чёткое разделение вещей на нужные и ненужные и избавление от последних. «соблюдение порядка» (всему своё место) — организация хранения необходимых вещей, которая позволяет быстро и просто их найти и использовать. «содержание в чистоте» (уборка) — содержание рабочего места в чистоте и опрятности. «стандартизация» (поддержание порядка) — необходимое условие для выполнения первых трёх правил. «совершенствование (буквальный перевод — воспитание)» (формирование привычки) — воспитание привычки точного выполнения установленных правил, процедур и технологических операций. Цели 5S Снижение числа несчастных случаев; Повышение уровня качества продукции, снижение количества дефектов; Создание комфортного психологического климата, стимулирование желания работать; Унификация и стандартизация рабочих мест; Повышение производительности труда за счёт сокращения времени поиска предметов в рамках рабочего пространства.
- #18 Устранение неоправданных потерь – это процесс поиска и устранения действий, которые не добавляют ценности, в производственных процессах. Большинство работ представляют собой последовательность действий, которые преобразуют исходный материал в конечный готовый продукт. Часть этих действий добавляет ценность продукту, а часть нет. Та часть, которая не добавляет ценности является потерями и должна быть устранена.
- #19 Стандартизация – это процесс стандартизации работы. Стандартизация создает основу для стабильной работы, однако стандарты должны быть изменены при изменении как внешнего, так и внутреннего окружения. В системе кайдзен процесс стандартизации не завершается никогда. Стандарты постоянно совершенствуются. Совершенствование стандартов выполняется по циклу PDCA (цикл Деминга).
- #20 Цикл Деминга следует простому Plan-Do-Check-Act принципу: Plan (Планирование): установление целей и процессов, необходимых для достижения целей, планирование работ по достижению целей процесса и удовлетворения потребителя, планирование выделения и распределения необходимых ресурсов. Do (Выполнение): Выполнение запланированных работ. Check (Проверка): сбор информации и контроль результата, полученного в ходе выполнения процесса, выявление и анализ отклонений, установление причин отклонений. Act (Воздействие – управление, корректировка): принятие мер по устранению причин отклонений от запланированного результата, изменение в планировании и распределение ресурсов. В некотором смысле использование итераций во время разработки ПО делает его похожим на производственный процесс, поскольку процессы разработки повторяются, что позволяет применять цикл Деминга. Улучшение продукта/решения так же является итеративным процессом, частично благодаря использованию рефакторинга.
- #21 Применение системы кайдзен осуществляется за счет создания и постоянной работы так называемых кайдзен–команд. По задачам, которые они решают, можно выделить 5 основных видов команд. Постоянные команды – эти команды работают каждый день. В состав команд входят специалисты (рабочие, служащие) выполняющие работы на местах. Команды по решению возникших проблем – формируются для поиска решений конкретной проблемы в работе. В состав команды входят участники из нескольких постоянных команд. Общее количество участников такой команды составляет, как правило, от шести до восьми человек. После выработки решения команда расформировывается. Кросс-функциональные команды – формируются для оценки существующих процессов организации и поиска возможностей по их улучшению. В состав команд входят рядовые специалисты и руководители из различных подразделений. Команды по реализации решений – формируются для внедрения разработанных улучшений процессов. Эти команды создаются из участников постоянных команд, команд по решению возникших проблем и кросс-функциональных команд. Малые группы – формируются для разработки, внедрения и применения специфических или новых процессов. В состав команд входят специалисты низового звена (рабочие, исполнители) и руководители подразделений из постоянных команд и команд по решению возникших проблем. Работа команд (за исключением постоянных) осуществляется в течении кайдзен-сессий. Продолжительность кайдзен-сессий составляет от 2 до 5 дней. Проведение каждой сессии нацелено на решение какой-либо конкретной бизнес-задачи. Организация работы в рамках кайдзен-сессии строится по принципу цикла PDCA.
- #22 Защита от дурака — защита предметов пользования (в особенности, техники), программного обеспечения и т. п. от очевидно неверных действий человека, как при пользовании, так и при техническом обслуживании или изготовлении. Концепция была формализована Сигэо Синго, японским инженером-производственником, который в своё время создал производственную систему Toyota, поэтому во многих языках защита от дурака называется заимствованным японским выражением пока-ёкэ — «защита от ошибки». Способы защиты от дурака делятся на уровни (по возрастанию эффективности)
- #23 1-й уровень — обнаружение несоответствий продукции (система обнаруживает несоответствующую деталь, но не отбрасывает её);
- #24 2-й уровень — недопущение несоответствия (исключается возможность обработать несоответствующую деталь на следующей операции);
- #25 3-й уровень — конструкционная защита (пример — изделие имеет такую конструкцию, что установить или собрать его по-иному невозможно).
- #26 Бережливое производство = создание ценности «точно вовремя» В производстве: использование маленьких партий, которые вытягиваются заказами потребителей В разработке ПО: разделение проблемы на небольшие части, которые «вытягиваются» требованиями заказчиков Пример: рабочий на заводе Toyota, который прикручивает двери
- #27 Весь Канбан можно описать всего тремя основными правилами: 1. Визуализируйте производство — Разделите работу на задачи, каждую задачу напишите на карточке и поместите на стену или доску. — Используйте названные столбцы, чтобы показать положение задачи в производстве. 2. Ограничивайте WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства. 3. Измеряйте время цикла (среднее время на выполнение одной задачи) и оптимизируйте постоянно процесс, чтобы уменьшить это время.
- #28 elaboration acceptance – проработка дизайна или уточнение требований expedite – срочная задача (не более одной!) wait time == lead time Число одновременных задач подбирается экпериментально (в среднем, кол-во разработчиков/2). Команда должна быть максимально сбалансирована: без перепроизводства, bottlenecks и лишних запасов. Что нового и полезного дает такая доска с лимитами? Во-первых, уменьшение числа параллельно выполняемых задач сильно уменьшает время выполнения каждой отдельной задачи. Нет нужды переключать контекст между задачами, отслеживать разные сущности, планировать их и т.д. — делается только то, что нужно. Нет нужды устраивать спринт планнинги и 5% воркшопы, т.к. планирование уже сделано в столбце «очередь задач», а детальная проработка задачи начинается ТОЛЬКО тогда, когда задача начинает выполняться. Во-вторых, сразу видны затыки. Например, если тестеры не справляются с тестированием, то они очень скоро заполнят весь свой столбец и программисты, закончившие новую задачу, уже не смогут переместить ее в столбец тестирования, т.к. он заполнен. Что делать? Тут время вспомнить, что «мы — команда» и решить эту проблему. Например, программисты могут помочь тестерам завершить одну из задач тестирования и только тогда передвинуть новую задачу на освободившееся место. Это позволит выполнить обе задачи быстрее. В-третьих, можно вычислить время на выполнение усредненной задачи. Мы можем помечать на карточке дату, когда она попала в очередь задач, потом дату, когда ее взяли в работу и дату, когда ее завершили. По этим трем точкам для хотя бы 10 задач можно уже посчитать среднее время ожидания в очередь задач и среднее время выполнения задачи. А из этих цифр менеджер или product owner может уже рассчитывать всё, что ему угодно.
- #29 Одной из основ бережливого производства является стремление к предотвращению возникновения проблем, а не к устранению их последствий. Методика 5 Whys (5 «Почему») была придумана Сакиши Тойода – основателем компании Toyota - для одной простой, но чрезвычайно важной вещи – понимания корня проблемы, ее базовой причины. Считается, что если сформулировать проблему и задать 5 раз вопрос «почему?» обязательно найдется ее корневая причина. Процедура проведения анализа главной (коренной) причины заключается в следующем: 1) Определите отправную проблему или причину высокого уровня, предназначенную для последующего анализа; 2) Методом мозгового штурма определите причины, соответствующие уровню более низкому, чем уровень отправной точки; 3) Для каждой идентифицированной причины поставьте вопрос: «Почему именно она служит причиной возникновения исходной проблемы?»; 4) После каждого нового ответа на поставленный вопрос задавайте его снова и снова до тех пор, пока никаких других ответов не останется. Возможно, это будет одна из коренных причин проблемы. Как показывает практика, число таких итераций равняется пяти «Почему?».
- #30 Простой пример, иллюстрирующий данный метод. Итак, продукт после поставки на прод не работает. Задаем вопросы, ищем ответы. Ответ на пятый вопрос и есть суть проблемы. Устранив ее, мы уберем основную причину, тогда как, остановившись на промежуточном вопросе, мы рано или поздно наткнемся на эту же или очень схожую поломку. Методика «5 почему» позволяет выявить системные проблемы, устранение которых может предотвратить повторение проблемы либо очень надолго, либо вообще навсегда. Важный момент — ответы на вопросы не должны уводить от сути и решения вопроса. Например, если на второй вопрос ответить: «Программисты написали некачественный код», то этот ответ при дальнейшем анализе будет уводить в сторону от настоящей причины в сторону мнимой, которая формируется из ложной предпосылки «кто-то другой, а не я, несет ответственность за работоспособность продукта». Поэтому на практике очень важно перепроверять каждый ответ, оценивая, остается ли проблема в зоне нашего влияния, или мы упускаем возможность повлиять на нее, погружаясь на следующий уровень.
- #31 Достоинства и недостатки метода
- #32 В Kanban внимание уделяется каждой задаче. Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик.. Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей Lead Time – время от появления задачи до ее конечной поставки. Включает Cycle Time и время ожидания в очереди на реализацию Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц) Этот простой список метрик позволяет полностью понимать и контролировать процесс разработки, постоянно анализируя и улучшая его. В идеале данные метрики считаются в разрезе категорий задач (по размеру, по типу, по срочности), чтобы еще улучшить понимание происходящего и позволить точнее прогнозировать результаты работы команды.