Игорь Лужанский “Потери в процессе разработки ПО”

«Учитесь видеть потери!» или

«Принципы бережливого производства в разработке ПО»

Доклад

23 января 2010 года

Игорь Лужанский

2

Цели выступления:

Проиллюстрировать и классифицировать потери в процессе разработке ПО

Поделиться опытом избавления от конкретных потерь

Вдохновить участников на совершенствование собственных процессов разработки и повышение эффективности разработки

3

Бережливое производство – набор методов и принципов которые работают везде

Бережливое производство рождено в Японской автомобильной индустрии

Широко применяется в большом спектре индустрий

Фокусируется на сокращении потерь и создании плавного потока ценности для потребителей

Парадигма бережливого производства используется так же и для оптимизации процесса разработки

4

7 принципов lean

Сокращать потери Действия не приносящие ценности заказчику – потери

Уважать / вдохновлять людей Большинство ошибок от системы, а не от людей

Принимать решения как можно позже

Учиться, учиться и ещё раз учиться

Создавать как можно быстрее

Встраивать качество в процесс разработки

Оптимизировать всю систему

5

Ценность это то, за что готов платить заказчик

Клиент готов заплатить только за те процессы, которые добавляют ценность продукту

Клиент определяет ценность продукта

Действия, добавляющие ценность продукту, приближают продукт к тому, что именно требуется заказчику

Любые действия, не добавляющие ценности продукту, считаются потерями.

6

Потери – это то, что не добавляет ценности продукту

ПОТЕРИ

Увеличение затрат на разработку

Увеличение срока окупаемости инвестиций

Снижение мотивации

разработчиков

Перепроизводство

Дефекты

Поиск информации

Транспортировка

Излишняя обработка

Ожидание

Частично выполненная работа

Лишние действия и операции

Простои в работе

7

СЛЕДСТВИЯ

Перепроизводство – функционал, который не нужен заказчику

Недостатки планирования

Большие заделы на будущее

Длительные циклы разработки

Слабые контакты с заказчиками

ПЕРЕПРОИЗВОДСТВО

Увеличение затрат на разработку

и тестирование

Увеличение затрат на поддержку

Уменьшение гибкостисистемы

Экстра функциональность

ПРИЧИНЫ

Завышенные системные требования

8

Короткий цикл разработки позволяет исключить перепроизводство

Описание проблемы: Заказчик не знает точно, чего он хочет (у проектной

команды на руках только высокоуровневое описание бизнес-процессов, которые должна покрывать система)

Сжатые сроки и отсутствие времени на переделку

Решение проблемы Сокращать цикл разработки Получать регулярную обратную связь о реализуемой

функциональности Делать только то, что нужно заказчику

Пример из жизни: как делать только то что нужно заказчику

9

Исправление дефектов на стадии эксплуатации дороже, чем на стадии разработки

СЛЕДСТВИЯ

Отсутствие превентивной

системы контроля

Отсутствие чётких критериев качества

ДЕФЕКТЫ(ПЕРЕДЕЛКА)

Затраты на исправлениедефектов в

продуктивной системе

Затраты на исправлениерезультатов

некорректной работы

Снижение лояльности и удовлетворенности

заказчика

Ошибки спецификации

ПРИЧИНЫ

Баги в системеЧастично

выполненная работа

Необходимость переделывать то, чтоуже было сделано

Пример из жизни: необходимость вносить изменение в спецификацию и сценарии тестирования при изменении требований

10

Тестирование требований до начала процесса разработки

Покрытие бизнес - логики системы Unit-тестами

Автоматизация процесса тестирования

Встраивание качества в процесс разработки позволяет уменьшить количество дефектов

11

Излишняя обработка вызвана сложной внутренней структурой приложения

СЛЕДСТВИЯ

Завышенные требования к качеству

Сложная архитектура системы

ИЗЛИШНЯЯ ОБРАБОТКА

Увеличение времениразработки

Уменьшение гибкости и масштабируемости

системы

Увеличение риска возникновения ошибок

Сложность доступа к внутренним функциям системы

ПРИЧИНЫ

Создание ненужных артефактовИспользование

«передовых» технологий

Стремление создать универсальную систему

12

Откладывание архитектурных решений позволяет уменьшить сложность системы

Пример из жизни: архитектура текущего проекта

Написание кода, который не нужен

Сильная связанность программного кода

Увеличение сложности системы

Потери времени из-за сложной архитектуры

Увеличение риска возникновения ошибок

Использование шаблонов проектирования для создания

гибкой архитектуры

Разработка только того, что важно заказчику

в данный момент

Создание гибкой и простой системы

Сокращение времени разработки

Уменьшение риска возникновения ошибок

13

Поиск необходимой информации приводит к простоям в работе

СЛЕДСТВИЯ

Отсутствие стандартов исходного кода

Отсутствие централизованной

базы знаний

ПОИСК НЕОБХОДИМОЙ ИНФОРМАЦИИ

Простои в работе разработчиков

Риск появления ошибок

Риск написания некачественного кода

Поиск необходимых классов, методови т.п.

ПРИЧИНЫ

Получение ответов на вопросы

Удаленность членов команды друг от друга

Бюрократические процессы

14

Построение базы знаний позволяет сократить время на поиск информации

Пример из жизни: разрешение инцидентов в команде поддержки

Описание проблемы В процессе поддержки ПО, команда разработки

привлекается для разрешения инцидентов Разные инженеры поддержки обращаются с одними и

теми же вопросами

Решение проблемы Создание единой базы знаний Контроль за результатами решения каждого инцидента

15

СЛЕДСТВИЯ

Транспортировка – передача знаний, системыи переключение между задачами

Распределенная команда разработки

Участие разработчиков в нескольких проектах ТРАНСПОРТИРОВКА

Увеличение длительности разработки

Увеличение количества и

длительности простоев

Переключение между задачами

ПРИЧИНЫ

Передача знаний и системы

Бюрократические процессы

16

Специализация на одном виде задач эффективна благодаря отсутствию переключений между задачами

Описание проблемы Один и тот же человек выполняет 2 различные задачи:

разработку и поддержку ПО Потери времени при переключении между задачами Конфликт интересов

Решение проблемы Разделение команды на 2 части (команда поддержки и

разработки) Разделение обязанностей и приоритетов для различных

задач

17

СЛЕДСТВИЯ

Плохое планирование

Недоступность участников процесса

ОЖИДАНИЕ

Увеличение времениразработки

Увеличение временивозврата инвестиций

Увеличение затрат на разработку

Ожидание необходимых для работы ресурсов

ПРИЧИНЫ

Ожидание принятия решений

Дискретность поставок

Ожидание – простой процесса из-за ожиданиярезультатов работы предыдущего процесса

Пример из жизни: аналитик ожидающий решений заказчика

18

Способность разрабатывать, выпускать маленькие релизы – уменьшает ожидание

Описание проблемы Отсутствие четких требований Сжатые сроки разработки, при которых не может быть

простоев

Решение проблемы Разрабатывать маленькими партиями Находиться близко к заказчику, регулярно получать

обратную связь

Пример из жизни: ночные build’ы и проект в котором сложно выжить

19

СЛЕДСТВИЯ

Подстраховка на случай

отсутствия работы

Ограниченная доступность ресурсов

ЧАСТИЧНО ВЫПОЛНЕННАЯРАБОТА

Риск морального устаревания

результатов работы

Увеличение временивозврата инвестиций

Увеличение затрат на разработку

Функциональность ожидающая тестирования

ПРИЧИНЫ

Требования ожидающие реализации

Асинхронность спроса и потребления

Частично выполненная работа – артефакты, которые ждут своего использования

Требования ожидающие анализа

20

Маленькие релизы позволяют уменьшить риски внедрения систем

Пример из жизни: система контроля качества или как большой слон был съеден по кусочкам

Описание проблемы Текущая система ужасно написана и требует

рефакторинга У системы отсутствует какая–либо документация В системе необходимо сделать серьёзные изменения

Решение проблемы Разделить внедрение и развертывание на 2 части

(система после рефакторинга и система с новой функциональностью)

Последовательно запускать одну часть за другой

21

Необходимо начинать с устранения потерь второго вида

Сложно исключить из процесса разработки

ПОТЕРИ ПЕРВОГО ВИДА

Ошибки архитектуры

ДЕЙСТВИЯ СОЗДАЮЩИЕ ЦЕННОСТЬ ДЛЯ ПОТРЕБИТЕЛЯ

Кодирование, анализ требований, развертывание системы, контроль качества

Легко исключить из процесса разработки

ПОТЕРИ ВТОРОГО ВИДА

Простои в работе, излишние требования,

сложности коммуникации

22

Завершение

Принципы бережливого производства применяются в различных индустриях и при правильном подходе работают и в разработке ПО

Не существует универсальных решений, каждая практика должна быть хорошо обдумана перед её применением

Любые начинания в бережливой разработке бессмысленны без вовлечения и поддержки всех членов команды

23

Послесловие ….

8-я потеря – нерациональное использование творческого и интеллектуального потенциала сотрудников

Мы достаточно знаем и умеем для эффективной и качественной разработки.

….так чего же мы ждем….. ?