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

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

Источник

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

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

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

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

Устранение отходов

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

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

Отраслевые исследования выявили следующие отходы разработки программного обеспечения:[6]

  1. Создание неправильной функции или продукта
  2. Неправильное управление отставанием
  3. Переделка
  4. Излишне сложные решения
  5. Посторонняя когнитивная нагрузка
  6. Психологический стресс
  7. Ожидание / многозадачность
  8. Потеря знаний
  9. Неэффективное общение.

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

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

Улучшение обучения

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

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

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

Решить как можно позже

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

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

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

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

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

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

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

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

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

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

Построить целостность в

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

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

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

Оптимизировать в целом

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

Все участники проекта должны хорошо понимать бережливое мышление, прежде чем реализовывать его в конкретной реальной ситуации. «Думай масштабно, действуй мелко, быстро терпи неудачу; быстро учись»[9] - эти слоганы суммируют важность понимания области и пригодности внедрения принципов бережливого производства на протяжении всего процесса разработки программного обеспечения. Только когда все принципы бережливого производства реализованы вместе, в сочетании с сильным «здравым смыслом» в отношении рабочей среды, есть основа для успеха в разработка программного обеспечения.

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

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

Поскольку гибкая разработка программного обеспечения - это общий термин для набора методов и практик, основанных на ценностях и принципах, выраженных в Agile Manifesto, бережливая разработка программного обеспечения считается гибким методом разработки программного обеспечения.[10]

Смотрите также

Рекомендации

  1. ^ Ясухиро Монден (1998), Производственная система Toyota, комплексный подход к своевременности, Третье издание, Norcross, GA: Engineering & Management Press, ISBN  0-412-83930-X.
  2. ^ Мэри Поппендик; Том Поппендик (2003). Бережливая разработка программного обеспечения: набор гибких инструментов. Эддисон-Уэсли Профессионал. ISBN  978-0-321-15078-3.
  3. ^ Мэри Поппендик: «Роль лидерства в разработке программного обеспечения» https://www.youtube.com/watch?v=ypEMdjslEOI
  4. ^ Мэри Поппендик; Том Поппендик (2003). Бережливая разработка программного обеспечения: набор гибких инструментов. Эддисон-Уэсли Профессионал. С. 13–15. ISBN  978-0-321-15078-3.
  5. ^ Мэри Поппендик; Том Поппендик (2003). Бережливая разработка программного обеспечения: набор гибких инструментов. Эддисон-Уэсли Профессионал. С. 19–22. ISBN  978-0-321-15078-3.
  6. ^ Седано, Тодд; Ральф, Пол; Перэр, Сесиль. «Отходы разработки программного обеспечения». IEEE.
  7. ^ «12 принципов Agile Manifesto - Agile Alliance». agilealliance.org. 4 ноября 2015.
  8. ^ Отметить линии; Скотт У. Амблер (2012). Дисциплинированная гибкая доставка: руководство для практиков по гибкой доставке программного обеспечения на предприятии. IBM Press. С. 54–. ISBN  978-0-13-281013-5.
  9. ^ Мэри Поппендик; Том Поппендик (2003). Бережливая разработка программного обеспечения: набор гибких инструментов. Эддисон-Уэсли Профессионал. С. 182–. ISBN  978-0-321-15078-3.
  10. ^ «Что такое гибкая разработка программного обеспечения?». agilealliance.org. 29 июня 2015.

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