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

Не путать с Lean (помощник по доказательству) .

Бережливая разработка программного обеспечения — это перевод бережливого производства принципов и практик в область разработки программного обеспечения . Адаптировано из производственной системы Toyota , он появляется при поддержке субкультуры сторонников бережливого производства в agile -сообществе. Lean предлагает прочную концептуальную основу , ценности и принципы, а также передовые методы, основанные на опыте, которые поддерживают гибкие организации.

Происхождение

Выражение «бережливая разработка программного обеспечения» возникло в одноименной книге, написанной Мэри Поппендик и Томом Поппендиком в 2003 году. В книге заново излагаются традиционные принципы бережливого производства , а также набор из 22 инструментов и сравниваются эти инструменты с соответствующими гибкими практиками. Участие Поппендиков в сообществе гибких разработчиков программного обеспечения , включая выступления на нескольких конференциях Agile. привело к тому, что такие концепции получили более широкое признание в agile-сообществе.

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

Бережливое развитие можно резюмировать семью принципами, очень близкими по своей концепции принципам бережливого производства:

1. Устранение отходов
2. Улучшите обучение
3. Решайте как можно позже
4. Доставим как можно быстрее
5. Расширьте возможности команды
6. Создайте целостность в
7. Оптимизируйте все

Устранить отходы

Философия бережливого производства рассматривает все, что не добавляет ценности для клиента, как отходы ( муда ). К таким отходам могут относиться:

1. Частично выполненная работа
2. Дополнительные возможности
3. Переобучение
4. Переключение задач
5. Ожидающий
6. Передача
7. Дефекты
8. Управленческая деятельность

Чтобы устранить потери, нужно уметь их распознавать. Если какую-то деятельность можно было бы обойти или результат можно было достичь без нее, то это растрата. Частично выполненный код, от которого в конечном итоге отказываются в процессе разработки , — это трата. Дополнительные функции, такие как оформление документов и функции, которые не часто используются клиентами, — это пустая трата. Переключение людей между задачами — это пустая трата времени (из-за того, что люди, участвующие в переключении контекста, тратят и часто теряют время). Ожидание других действий, команд, процессов — это растрата. Повторное изучение требований для завершения работы — пустая трата времени. Дефекты и низкое качество – это отходы. Управленческие накладные расходы, не приносящие реальной пользы, являются расточительством.

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

Углублять обучение

Разработка программного обеспечения — это непрерывный процесс обучения, основанный на итерациях при написании кода. Проектирование программного обеспечения — это процесс решения проблем, в котором участвуют разработчики, пишущие код и то, чему они научились. Ценность программного обеспечения измеряется его пригодностью для использования, а не соответствием требованиям.

Вместо добавления дополнительной документации или детального планирования можно опробовать различные идеи путем написания кода и сборки. Процесс сбора пользовательских требований можно упростить, представив конечным пользователям экраны и получив от них информацию. Накопление дефектов следует предотвращать, запуская тесты сразу после написания кода.

Процесс обучения ускоряется за счет использования коротких циклов итераций, каждый из которых сопровождается рефакторингом и интеграционным тестированием . Увеличение количества отзывов посредством коротких сеансов обратной связи с клиентами помогает определить текущий этап разработки и скорректировать усилия для будущих улучшений. Во время этих коротких сессий представители клиентов и команда разработчиков узнают больше о проблеме домена и находят возможные решения для дальнейшего развития. Таким образом, клиенты лучше понимают свои потребности, основываясь на существующих результатах усилий по разработке, а разработчики учатся, как лучше удовлетворить эти потребности. Еще одна идея в процессе общения и обучения с клиентом — это разработка на основе наборов: она концентрируется на сообщении об ограничениях будущего решения, а не на возможных решениях, тем самым способствуя рождению решения посредством диалога с клиентом.

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

Поскольку разработка программного обеспечения всегда связана с некоторой неопределенностью, лучших результатов следует достигать, используя подход , основанный на наборах или опциях , максимально откладывая решения до тех пор, пока они не будут приняты на основе фактов, а не на неопределенных предположениях и прогнозах. Чем сложнее система, тем больше возможностей для изменений должно быть заложено в нее, что позволит отложить принятие важных и решающих обязательств. Итеративный подход продвигает этот принцип – способность адаптироваться к изменениям и исправлять ошибки, которые могут стоить очень дорого, если они будут обнаружены после выпуска системы.

При разработке на основе набора: если, например, для автомобиля требуется новая тормозная система, три команды могут разработать решения одной и той же проблемы. Каждая команда изучает проблемное пространство и разрабатывает потенциальное решение. Поскольку решение считается необоснованным, оно отсекается. В конце периода сравниваются сохранившиеся проекты и выбирается один, возможно, с некоторыми модификациями, основанными на опыте других – отличный пример откладывания обязательств до самого последнего момента. Принятие решений по программному обеспечению также может извлечь выгоду из этой практики, чтобы минимизировать риск, вызванный масштабным предварительным проектированием. Кроме того, тогда будет несколько реализаций, которые работают правильно, но различаются (с точки зрения реализации, внутри). Их можно использовать для реализации отказоустойчивых систем, которые одновременно проверяют все входные и выходные данные на корректность в нескольких реализациях.

Гибкий подход к разработке программного обеспечения может ускорить создание вариантов для клиентов, тем самым откладывая принятие некоторых важных решений до тех пор, пока клиенты не поймут свои потребности лучше. Это также позволяет позднее адаптироваться к изменениям и предотвратить принятие ранее дорогостоящих технологических решений. Это не означает, что планирование не должно осуществляться – напротив, деятельность по планированию должна быть сконцентрирована на различных вариантах и ​​адаптации к текущей ситуации, а также на прояснении запутанных ситуаций путем установления моделей для быстрых действий. Оценка различных вариантов становится эффективной, как только становится понятно, что они не бесплатны, но обеспечивают необходимую гибкость для позднего принятия решений.

Доставьте как можно быстрее

В эпоху стремительного развития технологий выживает не самый большой, а самый быстрый. Чем быстрее будет доставлен конечный продукт без серьезных дефектов, тем быстрее можно будет получить обратную связь и включить ее в следующую итерацию . Чем короче итерации, тем лучше обучение и общение внутри команды. Из-за скорости решения могут быть отложены. Скорость гарантирует удовлетворение текущих потребностей клиента, а не того, что ему требовалось вчера. Это дает им возможность отложить принятие решения о том, что им действительно нужно, до тех пор, пока они не приобретут более глубокие знания. Клиенты ценят быструю доставку качественного продукта.

Идеологию производства «точно в срок» можно применить к разработке программного обеспечения с учетом ее конкретных требований и среды. Это достигается путем представления необходимого результата и предоставления команде возможности организоваться и разделить задачи для достижения необходимого результата для конкретной итерации . Вначале клиент предоставляет необходимые данные. Это можно просто представить в виде небольших карточек или историй — разработчики оценивают время, необходимое для реализации каждой карточки. Таким образом, организация работы превращается в самодвижущуюся систему : каждое утро во время стендапа каждый член команды анализирует, что было сделано вчера, что предстоит сделать сегодня и завтра, и запрашивает любые необходимые комментарии от коллег или сотрудников. клиент. Это требует прозрачности процесса, что также полезно для командного общения.

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

Расширьте возможности команды

В большинстве предприятий существует традиционное убеждение в том, что решения принимаются в организации: менеджеры говорят работникам, как выполнять свою работу. В методе тренировки роли меняются: менеджеров учат слушать разработчиков , чтобы они могли лучше объяснить, какие действия можно предпринять, а также дать предложения по улучшениям. Бережливый подход следует гибкому принципу «создавайте проекты вокруг мотивированных людей [...] и доверяйте им выполнение работы», поощрение прогресса, выявление ошибок и устранение препятствий, но не микроменеджмент .

Еще одним ошибочным убеждением было представление о людях как о ресурсах . Люди могут быть ресурсами с точки зрения статистических данных, но в разработке программного обеспечения , как и в любом организационном бизнесе, людям действительно нужно нечто большее, чем просто список задач и уверенность в том, что их не потревожат во время выполнения. задач. Людям нужна мотивация и высшая цель для работы – цель в рамках достижимой реальности, с уверенностью, что команда сможет выбирать свои собственные обязательства. Разработчикам должен быть предоставлен доступ к заказчику; руководитель команды должен оказывать поддержку и помощь в трудных ситуациях, а также следить за тем, чтобы скептицизм не испортил дух команды. Уважение к людям и признание их работы — один из способов расширить возможности команды.

Создайте целостность в

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

Концептуальная целостность означает, что отдельные компоненты системы хорошо работают вместе как единое целое, обеспечивая баланс между гибкостью, ремонтопригодностью, эффективностью и оперативностью. Этого можно достичь, понимая проблемную область и решая ее одновременно, а не последовательно. Необходимая информация поступает небольшими порциями, а не одним огромным куском, предпочтительно путем личного общения, а не какой-либо письменной документации. Поток информации должен быть постоянным в обоих направлениях – от заказчика к разработчикам и обратно, что позволит избежать большого стрессового объема информации после длительной изолированной разработки.

Одним из здоровых способов создания целостной архитектуры является рефакторинг . Чем больше функций добавляется в исходную базу кода, тем труднее становится добавлять дальнейшие улучшения. Рефакторинг — это сохранение простоты, ясности и минимального количества функций в коде. Повторения в коде являются признаком плохого проектирования кода, и их следует избегать (т. е. применять правило DRY ). Полный и автоматизированный процесс сборки должен сопровождаться полным и автоматизированным набором тестов для разработчиков и клиентов, имеющих те же версии, синхронизацию и семантику, что и текущее состояние системы. В конце целостность должна быть проверена с помощью тщательного тестирования, гарантируя, таким образом, что Система выполняет то, чего ожидает от нее клиент. Автоматизированные тесты также считаются частью производственного процесса, и поэтому, если они не приносят пользы, их следует считать отходами. Автоматизированное тестирование должно быть не целью, а скорее средством достижения цели, в частности, уменьшения количества дефектов.

Оптимизировать всё

Современные программные системы представляют собой не просто сумму своих частей, но и продукт их взаимодействия. Дефекты в программном обеспечении имеют тенденцию накапливаться в процессе разработки: путем разложения больших задач на более мелкие и стандартизации различных этапов разработки следует находить и устранять коренные причины дефектов. Чем больше система, чем больше организаций участвует в ее разработке и чем больше частей разрабатывается разными командами, тем выше важность наличия четко определенных отношений между различными поставщиками для создания системы с плавно взаимодействующими компонентами. В течение длительного периода разработки более сильная сеть субподрядчиков гораздо более выгодна, чем краткосрочная оптимизация прибыли, которая не обеспечивает взаимовыгодных отношений .

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

бережливого

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

• Видя отходы
• Значение карты потока
• Разработка на основе набора
• Вытяжные системы
• Теория массового обслуживания
• Мотивация
• Измерения
• Разработка через тестирование

Поскольку гибкая разработка программного обеспечения является общим термином для набора методов и практик, основанных на ценностях и принципах, выраженных в Манифесте Agile, бережливая разработка программного обеспечения считается гибким методом разработки программного обеспечения.

См. также

• Экстремальное программирование
• DevOps
• Канбан
• Канбан-доска
• Бережливая интеграция
• Бережливые услуги
• Скрам (разработка)

Дальнейшее чтение

• Ладас, Кори (январь 2008 г.). Scrumban: Очерки систем Канбан для бережливой разработки программного обеспечения . Модус Куперанди Пресс. ISBN  978-0-578-00214-9 .
• Райс, Эрик (сентябрь 2011 г.). Бережливый стартап : как современные предприниматели используют непрерывные инновации для создания радикально успешного бизнеса . Коронный бизнес. ISBN  978-0307887894 .