Войти
Бережливая разработка программного обеспечения - это перевод принципов и практик бережливого производства в разработка программного обеспечения домен. Адаптированный из производственной системы Toyota, он возникает при поддержке субкультуры сторонников бережливого производства в рамках сообщества Agile. Lean предлагает прочную концептуальную основу, ценности и принципы, а также передовые практики, основанные на опыте, которые поддерживают гибкие организации.
Термин бережливая разработка программного обеспечения возник в одноименной книге, написанной Мэри Поппендик и Томом Поппендиком в 2003 году. В книге повторяются традиционные принципы бережливого производства, а также набор из 22 принципов. инструменты и сравнивает инструменты с соответствующими гибкими практиками. Участие Поппендиков в сообществе agile-разработки, включая выступления на нескольких конференциях по Agile, привело к тому, что такие концепции получили более широкое признание в сообществе Agile.
Бережливое развитие можно резюмировать с помощью семи принципов, очень близких по концепции к принципам бережливого производства:
Философия бережливого производства рассматривает все, что не добавляет ценности потребителю, как отходы ( муда ). К таким отходам могут относиться:
отраслевые исследования выявил следующие отходы разработки программного обеспечения:
Чтобы избежать потерь, нужно уметь распознавать их. Если какое-то действие можно обойти или результат может быть достигнут без него, это пустая трата. Частично выполненное кодирование, от которого в конечном итоге отказались в процессе разработки, является пустой тратой. Дополнительные функции, такие как оформление документов и функции, которые не часто используются клиентами, являются ненужными. Переключение людей между задачами - пустая трата времени. Ожидание других действий, команд, процессов - пустая трата времени. Повторное обучение, необходимое для завершения работы, - пустая трата времени. Дефекты и низкое качество - это отходы. Управленческие накладные расходы, не приносящие реальной ценности, - это расточительство.
A отображение потока создания ценности используется для выявления потерь. Второй шаг - указать источники отходов и устранить их. Удаление отходов должно происходить итеративно до тех пор, пока не будут ликвидированы даже кажущиеся важными процессы и процедуры.
Разработка программного обеспечения - это непрерывный процесс обучения, основанный на итерациях при написании кода. Разработка программного обеспечения - это процесс решения проблем, в котором разработчики пишут код и то, чему они научились. Ценность программного обеспечения измеряется в соответствии с его пригодностью к использованию, а не в соответствии с требованиями.
Вместо добавления дополнительной документации или подробного планирования можно попробовать различные идеи, написав код и построив. Процесс сбора требований пользователей можно упростить, предоставив конечным пользователям экраны и получив их ввод. Следует предотвращать накопление дефектов путем запуска тестов сразу после написания кода.
Процесс обучения ускоряется за счет использования коротких итерационных циклов - каждый в сочетании с рефакторингом и интеграционным тестированием. Увеличение количества отзывов посредством коротких сеансов обратной связи с клиентами помогает при определении текущего этапа разработки и корректировке усилий для будущих улучшений. Во время этих коротких сессий и представители клиентов, и команда разработчиков узнают больше о проблеме домена и выясняют возможные решения для дальнейшего развития. Таким образом, клиенты лучше понимают свои потребности на основе существующих результатов усилий по разработке, а разработчики узнают, как лучше удовлетворить эти потребности. Еще одна идея в процессе общения и обучения с клиентом - разработка на основе наборов - она концентрируется на сообщении ограничений будущего решения, а не на возможных решениях, тем самым способствуя рождению решения через диалог с клиентом.
Поскольку разработка программного обеспечения всегда связана с некоторой неопределенностью, лучшие результаты должны быть достигнуты с помощью подхода, основанного на наборах или опциях, что откладывает принятие решений настолько, насколько возможно, пока они не будут основаны на фактах, а не на неопределенных предположениях и прогнозах. Чем сложнее система, тем больше в нее возможностей для изменений, что позволяет отсрочить выполнение важных и важных обязательств. Итерационный подход продвигает этот принцип - способность адаптироваться к изменениям и исправлять ошибки, которые могут оказаться очень дорогостоящими, если будут обнаружены после выпуска системы.
Подход гибкой разработки программного обеспечения может ускорить создание вариантов для клиентов, таким образом откладывая некоторые важные решения до тех пор, пока клиенты не осознают свои потребности лучше. Это также позволяет позднее адаптироваться к изменениям и предотвратить дорогостоящие ранее принятые технологически обусловленные решения. Это не означает, что не следует участвовать в планировании - напротив, деятельность по планированию должна быть сконцентрирована на различных вариантах и адаптации к текущей ситуации, а также на прояснении запутанных ситуаций путем установления шаблонов для быстрых действий. Оценка различных вариантов эффективна, как только становится понятно, что они не бесплатны, но обеспечивают необходимую гибкость для позднего принятия решений.
В эпоху стремительного развития технологий выживает не самое большое, а самое быстрое. Чем раньше будет доставлен конечный продукт без серьезных дефектов, тем скорее будет получена обратная связь, которая будет включена в следующую итерацию. Чем короче итерации, тем лучше обучение и общение в команде. Со скоростью решения можно отложить. Скорость гарантирует выполнение текущих потребностей клиента, а не то, что они требовали вчера. Это дает им возможность отложить принятие решения о том, что им действительно нужно, до тех пор, пока они не получат более глубокие знания. Клиенты ценят быструю доставку качественного продукта.
Идеология производства точно в срок может быть применена к разработке программного обеспечения с учетом ее конкретных требований и среды. Это достигается путем представления необходимого результата и предоставления команде возможности организовать себя и разделить задачи для достижения необходимого результата для конкретной итерации. Вначале заказчик предоставляет необходимые данные. Это можно просто представить в виде небольших карточек или историй - разработчики оценивают время, необходимое для реализации каждой карты. Таким образом, организация работы превращается в самодостаточную систему - каждое утро во время совещаний каждый член команды анализирует, что было сделано вчера, что нужно сделать сегодня. и завтра, и запрашивает любые данные, необходимые от коллег или клиента. Это требует прозрачности процесса, что также полезно для командного взаимодействия.
В основе этого принципа лежит миф о том, что поспешность тратит впустую. Тем не менее, бережливое внедрение предполагает, что хорошей практикой является быстрое выполнение, чтобы увидеть и проанализировать результат как можно раньше.
В большинстве компаний существовало традиционное мнение о принятии решений в организации - менеджеры рассказывают рабочим, как выполнять свою работу.. В технике тренировки роли меняются - менеджеров учат слушать разработчиков, чтобы они могли лучше объяснить, какие действия можно предпринять, а также предоставить предложения по улучшениям. Бережливый подход следует гибкому принципу «создавайте проекты вокруг мотивированных [...] людей и доверяйте им выполнение работы», поощряя прогресс, выявляя ошибки и устраняя препятствия, но не микроменеджмент.
Еще одно ошибочное мнение заключалось в том, что люди рассматривались как ресурсы. Люди могут быть ресурсами с точки зрения статистических данных, но в разработке программного обеспечения, как и в любом бизнесе организации, людям нужно нечто большее, чем просто список задач. и уверенность в том, что их не побеспокоят во время выполнения задач. Людям нужна мотивация и более высокая цель для работы - цель в достижимой реальности с уверенностью в том, что команда может выбрать свои собственные обязательства. Разработчикам должен быть предоставлен доступ к заказчику; руководитель группы должен оказывать поддержку и помощь в сложных ситуациях, а также следить за тем, чтобы скептицизм не подорвал дух команды. Уважение к людям и признание их работы - один из способов расширить возможности команды.
Заказчик должен иметь общее представление о системе. Это так называемая воспринимаемая целостность: как она рекламируется, доставляется, развертывается, осуществляется доступ, насколько интуитивно понятно ее использование, ее цена и насколько хорошо она решает проблемы.
Концептуальная целостность означает, что отдельные компоненты системы хорошо работают вместе как единое целое с балансом между гибкостью, ремонтопригодностью, эффективностью и быстродействием. Этого можно достичь, понимая проблемную область и решая ее одновременно, а не последовательно. Необходимая информация поступает небольшими партиями, а не одним огромным фрагментом, предпочтительно путем личного общения, а не какой-либо письменной документации. Информационный поток должен быть постоянным в обоих направлениях - от клиента к разработчикам и обратно, чтобы избежать большого стрессового объема информации после длительной изолированной разработки.
Один из здоровых способов создания интегральной архитектуры - это рефакторинг. Чем больше функций добавляется к исходной базе кода, тем сложнее становится добавлять дополнительные улучшения. Рефакторинг заключается в сохранении простоты, ясности и минимального количества функций в коде. Повторения в коде - это признаки плохого дизайна кода, и их следует избегать. Полный и автоматизированный процесс сборки должен сопровождаться полным и автоматическим набором тестов для разработчиков и заказчиков, имеющих те же версии, синхронизацию и семантику, что и текущее состояние системы. В конце целостность должна быть проверена путем тщательного тестирования, чтобы гарантировать, что Система выполняет то, что ожидает от нее заказчик. Автоматические тесты также считаются частью производственного процесса, и поэтому, если они не добавляют ценности, их следует рассматривать как отходы. Автоматизированное тестирование должно быть не целью, а скорее средством достижения цели, в частности уменьшения количества дефектов.
Современные программные системы - это не просто сумма их частей, но и продукт их взаимодействия. Дефекты в программном обеспечении имеют тенденцию накапливаться в процессе разработки - путем декомпозиции больших задач на более мелкие и стандартизации различных этапов разработки необходимо найти и устранить основные причины дефектов. Чем крупнее система, чем больше организаций участвует в ее разработке и чем больше частей разрабатывается разными командами, тем важнее иметь четко определенные отношения между разными поставщиками для создания системы с плавно взаимодействующими компонентами. В течение более длительного периода развития более сильная сеть субподрядчиков намного выгоднее, чем краткосрочная оптимизация прибыли, которая не способствует взаимовыгодным отношениям.
Бережливое мышление должно быть хорошо понято всеми участниками проекта, прежде чем реализовывать его в конкретной реальной ситуации. «Думайте масштабно, действуйте мелко, быстро терпите неудачу; быстро учитесь» - эти слоганы суммируют важность понимания области и целесообразность внедрения принципов бережливого производства на протяжении всего процесса разработки программного обеспечения. Только тогда, когда все принципы бережливого производства реализованы вместе, в сочетании с твердым «здравым смыслом» в отношении рабочей среды, есть основа для успеха в разработке программного обеспечения.
бережливое производство Практика разработки программного обеспечения, или то, что Poppendiecks называют «инструментами», несколько переработана по сравнению с исходными эквивалентами в гибкой разработке программного обеспечения. Примеры таких практик:
Поскольку гибкая разработка программного обеспечения - это общий термин для набора методов и практик, основанных на ценностях и принципах, изложенных в Agile Manifesto, бережливая разработка программного обеспечения считается гибким методом разработки программного обеспечения.
