Бережливая разработка

Бережливая разработка программного обеспечения

Источник: Мэри Поппендик, Toм Поппендик. Бережливое производство программного обеспечения: от идеи до прибыли.

Некоторые практики бережливой разработки аналогичны практикам быстрой разработки, а некоторые несколько различаются. Примеры практик:

•     Обнаружение потерь («en:Muda (Japanese term)»)
•     Систематизирование потока ценности (Value stream mapping)
•     Теория ограничений
•     «Вытягивающая» система (Канбан)
•     Теория массового обслуживания
•     Мотивация
•     Измерения

Принципы

•     Исключение потерь. Потерями считается всё, что не добавляет ценности для потребителя. В частности: излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение.
•     Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.
•     Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.
•     Предельно быстрая доставка заказчику. Короткие итерации.
•     Мотивация команды. Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий.
•     Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.
•     Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, делать мало, ошибаться быстро; учиться стремительно».

Описыает методы ухода от следующих факторов

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

Часто и неожиданно изменяющиеся требования заказчика

Проблема консервативного подхода к разработке программного обеспечения лежит в предположении, что требования заказчика неизменны и могут быть идентифицированы заранее. Но поскольку требования меняются достаточно часто в течение жизни большинства систем, они не всегда могут быть адекватно отражены с помощью жесткого, негибкого дизайна системы. «Делайте правильно» (Do it right) было так же ошибочно интерпретировано, как «Не позволяйте изменений», что в свою очередь спровоцирует недовольство клиентов. С другой стороны, если изменения разрешены в течение проекта, у компании будут проблемы с поставкой ПО согласно основной линии проекта.

Централизованное принятие решений

Крупные компании по разработке программного обеспечения до сих пор используют традиционный директивный подход при принятии решений. Каждый раз, когда решение принимается, оно должно пройти весь путь с самой верхушки организационной структуры проекта к конечным исполнителям. Такой подход увеличивает время разработки и делает весь процесс негибким и медленным.

Жесткое управление объёмом работ по проекту

Удержание проекта в рамках, согласованных на начальной стадии, приносит мало пользы заказчикам, требования которых изменяются. В действительности такой подход только сеет тревогу и парализует способность принимать решения, обеспечивая лишь то, что система будет частично устаревшей к моменту её запуска. Таким образом, управление работами, которые не нужны заказчику, являются прямыми потерями времени и ресурсов.

Тем не менее, до тех пор, пока ограничение проекта своим изначальным объёмом работ будет ключевой задачей менеджера, локальная оптимизация будет процветать за счет качества всего проекта.

Традиционный (линейный) подход к разработке

Большинство проблем с качеством при разработке программных компонентов возникает из-за линейности процесса разработки, которая не предусматривает проверку качества до того, как компонент перешел на следующую стадию цикла разработки. То есть разработка продолжается даже тогда, когда существуют проблемы с качеством («баги»)

Вывод

Организация, использующая процесс бережливой разработки ПО, может считаться бережливой, если она демонстрирует только небольшие объемы непроизводительных затрат во всех трех формах ("мура", "мури" и "муда") и может и может продемонстрировать оптимизацию поставки продукта посредством эффективного управления рисками. Преследование идеала в бережливой разработке — всегда поиск. Назначение отсутствует. Истинно бережливые организации всегда стремятся к дальнейшему улучшению.

Бережливая разработка программного обеспечения по-прежнему развивающееся поле и вероятнее всего оно будет развиваться в течение следующего десятилетия.