В бережливых методологиях разработки ПО и оказания ИТ-услуг появляются следующие отходы:
• невостребованные функции программного обеспечения;
• задержки при общении;
• замедленный отклик приложения;
• бюрократические процессы.
Отходы в контексте бережливости противоположны ценностям. Мэри Поппендик и Томас Поппендик сопоставили отходы бережливого производства с отходами производства программного обеспечения. В результате появился следующий список[12]:
• частично выполненная работа;
• дополнительные возможности;
• переучивание;
• ненужные передачи обслуживания;
• переключение между задачами;
• задержки;
• дефекты.
Как и в случае с devops, не существует единственно верного способа внедрения бережливой разработки программного обеспечения. В процессе бережливой разработки ПО применяются два основных подхода: фокус на устранении отходов с помощью набора инструментов и улучшение рабочего потока, также известное под названием «путь Тойоты»[13]. Оба подхода направлены на достижение одной и той же цели, но в силу их различий могут приводить к разным результатам.
Концепции разработки, релиза и развертывания ПО
При рассмотрении разработки, релиза и развертывания программного обеспечения следует упомянуть еще несколько концепций, которые ранее не рассматривались в этой главе. Эти концепции описывают порядок разработки и развертывания программного обеспечения и дают представление о степени связи между ними. После ознакомления с этими концепциями у читателя выработается более зрелое понимание способов использования инструментов, облегчающих применение требуемых практик.
Контроль версий
Система контроля версий фиксирует изменения файлов или наборов файлов, которые хранятся в системе. Это могут быть файлы исходного кода, ресурсы и другие документы, которые являются частью процесса разработки программного обеспечения. Разработчики вносят изменения в форме пакетов, называемых фиксациями, или ревизиями. Каждая ревизия, наравне с метаданными, такими как «кто внес изменения и когда», «хранится в системе в той или иной форме», находится в системе в каком-либо виде.
При наличии возможностей по фиксации, сравнению, выполнению слияния и восстановлению прежних ревизий объектов в хранилище можно организовать расширенную кооперацию и сотрудничество внутри команды и между командами. Это сводит к минимуму возможные риски, поскольку появляется способ вернуться к предыдущим версиям объектов.
Разработка через тестирование
При выполнении разработки через тестирование (Test Driven Development; TDD) разработчик начинает с написания проверяемого функционал-теста, применяемого для проверки функциональности нового кода. После этого создается сам код, затем начинается тестирование этого кода. Благодаря тестированию гарантируется безупречная работа новых функций, а также становится более очевидным назначение кода.