Бережливая разработка программного обеспечения - это перевод принципов и практик бережливого производства в область разработки программного обеспечения . Адаптировано из производственной системы Toyota , [1] он появляется при поддержке про-постной субкультуру в рамках Agile сообщества. Lean предлагает прочную концептуальную основу, ценности и принципы, а также передовые практики, основанные на опыте, которые поддерживают гибкие организации.
Источник
Термин « бережливая разработка программного обеспечения» возник в одноименной книге, написанной Мэри Поппендик и Томом Поппендиком в 2003 году. [2] В книге повторяются традиционные принципы бережливого производства , а также набор из 22 инструментов и сравниваются инструменты с соответствующими гибкими практиками . Участие Поппендиков в сообществе гибкой разработки программного обеспечения , включая выступления на нескольких конференциях по гибкой методике [3] , привело к тому, что такие концепции получили более широкое признание в гибком сообществе.
Принципы бережливого производства
Бережливое развитие можно резюмировать семью принципами, очень близкими по концепции к принципам бережливого производства: [4]
- Устранение отходов
- Улучшение обучения
- Решить как можно позже
- Доставим как можно быстрее
- Расширьте возможности команды
- Построить целостность в
- Оптимизировать все
Устранение отходов
Философия бережливого производства рассматривает все, что не добавляет ценности потребителю, как отходы ( муда ). Такие отходы могут включать: [5]
- Частично сделанная работа
- Дополнительные особенности
- Повторное обучение
- Переключение задач
- Ожидающий
- Передачи
- Дефекты
- Управленческая деятельность
Чтобы исключить отходы, нужно уметь их распознавать. Если какое-то действие можно обойти или результат может быть достигнут без него, это пустая трата времени. Частично выполненное кодирование, от которого в конечном итоге отказываются в процессе разработки, является пустой тратой. Дополнительные функции, такие как оформление документов и функции, которые не часто используются клиентами, являются ненужными. Переключение людей между задачами - пустая трата времени. Ожидание других действий, команд, процессов - пустая трата времени. Повторное обучение, необходимое для завершения работы, - пустая трата времени. Дефекты и низкое качество - это отходы. Управленческие накладные расходы, не приносящие реальной ценности, - это расточительство.
Для выявления потерь используется метод картирования потока создания ценности . Второй шаг - указать источники отходов и устранить их. Удаление отходов должно происходить итеративно до тех пор, пока не будут ликвидированы даже кажущиеся важными процессы и процедуры.
Улучшение обучения
Разработка программного обеспечения - это непрерывный процесс обучения, основанный на итерациях при написании кода. Дизайн программного обеспечения - это процесс решения проблем, в котором разработчики пишут код и то, чему они научились. Ценность программного обеспечения измеряется в соответствии с его пригодностью к использованию, а не в соответствии с требованиями.
Вместо добавления дополнительной документации или подробного планирования можно попробовать разные идеи, написав код и построив. Процесс сбора требований пользователей можно упростить, если предоставить конечным пользователям изображения экранов и получить от них информацию. Следует предотвратить накопление дефектов, запустив тесты сразу после написания кода.
Процесс обучения ускоряется за счет использования коротких итерационных циклов, каждый из которых сочетается с рефакторингом и интеграционным тестированием . Увеличение количества отзывов посредством коротких сеансов обратной связи с клиентами помогает при определении текущего этапа разработки и корректировке усилий для будущих улучшений. Во время этих коротких сессий как представители клиентов , так и команда разработчиков узнают больше о проблеме домена и выясняют возможные решения для дальнейшего развития. Таким образом, клиенты лучше понимают свои потребности, основываясь на существующем результате усилий по разработке, а разработчики узнают, как лучше удовлетворить эти потребности. Еще одна идея в процессе общения и обучения с клиентом - разработка на основе наборов - она концентрируется на сообщении ограничений будущего решения, а не на возможных решениях, тем самым способствуя рождению решения через диалог с клиентом. [ жаргон ]
Решить как можно позже
Поскольку разработка программного обеспечения всегда связана с некоторой неопределенностью, лучших результатов следует достигать с помощью подхода, основанного на наборах или опциях , с максимально возможной задержкой решений до тех пор, пока они не будут приняты на основе фактов, а не на основе неопределенных предположений и прогнозов. Чем сложнее система, тем больше в нее возможностей для изменений, что позволяет отсрочить выполнение важных и важных обязательств. Итерационный подход продвигает этот принцип - способность адаптироваться к изменениям и исправлять ошибки, которые могут оказаться очень дорогостоящими, если будут обнаружены после выпуска системы.
- При разработке на основе набора: если, например, для автомобиля необходима новая тормозная система, три команды могут разработать решения одной и той же проблемы. Каждая команда изучает проблемное пространство и разрабатывает потенциальное решение. Как решение считается неразумным, его сокращают. В конце периода уцелевшие проекты сравниваются и выбирается один, возможно, с некоторыми изменениями, основанными на опыте других - отличный пример откладывания обязательств до последнего возможного момента. Программные решения также могут выиграть от этой практики, чтобы минимизировать риск, связанный с большим предварительным проектированием. Кроме того, тогда будет несколько реализаций, которые будут работать правильно, но при этом будут разными (с точки зрения реализации, внутри). Их можно использовать для реализации отказоустойчивых систем, которые одновременно проверяют все входы и выходы на правильность в нескольких реализациях.
Быстрая разработка программного обеспечения подход может переместить здание опциями ранее для клиентов, задерживая тем самым определенные важные решения , пока клиенты не лучше реализовали свои потребности. Это также позволяет позднее адаптироваться к изменениям и предотвратить дорогостоящие ранее принятые решения, связанные с технологией. Это не означает, что не должно быть никакого планирования - напротив, деятельность по планированию должна быть сконцентрирована на различных вариантах и адаптации к текущей ситуации, а также на прояснении запутанных ситуаций путем установления шаблонов для быстрых действий. Оценка различных вариантов эффективна, как только становится понятно, что они не бесплатны, но обеспечивают необходимую гибкость для принятия решений на поздних этапах.
Доставим как можно быстрее
В эпоху стремительного развития технологий выживают не самые крупные, а самые быстрые. Чем раньше будет доставлен конечный продукт без серьезных дефектов, тем скорее будет получена обратная связь, которая будет учтена в следующей итерации . Чем короче итерации, тем лучше обучение и общение внутри команды. Со скоростью решения можно отложить. Скорость гарантирует удовлетворение текущих потребностей клиента, а не то, что им требовалось вчера. Это дает им возможность отложить принятие решения о том, что им действительно нужно, до тех пор, пока они не получат более глубокие знания. Клиенты ценят быструю доставку качественного продукта.
Идеология производства « точно в срок» может быть применена к разработке программного обеспечения с учетом его специфических требований и среды. Это достигается путем представления необходимого результата и предоставления команде возможности организовать себя и разделить задачи для достижения необходимого результата для конкретной итерации . Вначале заказчик вносит необходимые данные. Это можно было бы просто представить в виде небольших карточек или историй - разработчики оценивают время, необходимое для реализации каждой карточки. Таким образом, организация работы превращается в самодостаточную систему - каждое утро во время встречи каждый член команды рассматривает, что было сделано вчера, что должно быть сделано сегодня и завтра, и запрашивает любые необходимые данные от коллег или клиент. Это требует прозрачности процесса, что также полезно для командного взаимодействия.
Миф, лежащий в основе этого принципа, гласит, что поспешность тратит впустую . Тем не менее, бережливое внедрение предполагает, что хорошей практикой является быстрое выполнение, чтобы увидеть и проанализировать результат как можно раньше.
Расширьте возможности команды
В большинстве предприятий существовало традиционное мнение о том, что решения принимаются в организации: менеджеры говорят рабочим, как выполнять свою работу. В технике тренировки роли меняются - менеджеров учат слушать разработчиков , чтобы они могли лучше объяснить, какие действия могут быть предприняты, а также предоставить предложения по улучшениям. Бережливый подход следует гибкому принципу [6] «создавайте проекты вокруг мотивированных [...] людей и доверяйте им выполнение работы» [7], поощряя прогресс, выявляя ошибки и устраняя препятствия, но не микроменеджмент.
Еще одно ошибочное мнение - это рассмотрение людей как ресурсов . Люди могут быть ресурсами с точки зрения таблицы статистических данных, но при разработке программного обеспечения , как и в любом организационном бизнесе, людям действительно нужно нечто большее, чем просто список задач и уверенность в том, что их не побеспокоят во время выполнения. задач. Людям нужна мотивация и более высокая цель для работы - цель в достижимой реальности, с уверенностью, что команда может выбрать свои собственные обязательства. Разработчикам должен быть предоставлен доступ к заказчику; руководитель группы должен оказывать поддержку и помощь в сложных ситуациях, а также гарантировать , что скептицизм не разрушает дух команды. Уважение к людям и признание их работы - один из способов расширить возможности команды.
Построить целостность в
Заказчик должен иметь общее представление о системе. Это так называемая воспринимаемая целостность: как она рекламируется, доставляется, развертывается, осуществляется доступ, насколько интуитивно понятно ее использование, ее цена и насколько хорошо она решает проблемы.
Концептуальная целостность означает, что отдельные компоненты системы хорошо работают вместе как единое целое с балансом между гибкостью, ремонтопригодностью, эффективностью и быстродействием. Этого можно достичь, понимая проблемную область и решая ее одновременно, а не последовательно. Необходимая информация поступает небольшими партиями, а не одним большим фрагментом, предпочтительно путем личного общения, а не какой-либо письменной документации. Информационный поток должен быть постоянным в обоих направлениях - от клиента к разработчикам и обратно, чтобы избежать большого стрессового объема информации после длительной изолированной разработки.
Один из здоровых способов создания целостной архитектуры - это рефакторинг . Чем больше функций добавляется к исходной кодовой базе, тем сложнее становится добавлять дальнейшие улучшения. Рефакторинг заключается в сохранении простоты, ясности и минимального количества функций в коде. Повторения в коде - это признаки плохого дизайна кода, и их следует избегать. Полный и автоматизированный процесс сборки должен сопровождаться полным и автоматизированным набором тестов для разработчиков и заказчиков, имеющих те же версии, синхронизацию и семантику, что и текущее состояние системы. В конце целостность должна быть проверена путем тщательного тестирования, чтобы гарантировать, что Система выполняет то, что ожидает от нее заказчик. Автоматические тесты также считаются частью производственного процесса, и поэтому, если они не добавляют ценности, их следует рассматривать как отходы. Автоматизированное тестирование должно быть не целью, а скорее средством достижения цели, в частности уменьшения количества дефектов.
Оптимизировать в целом
Современные программные системы - это не просто сумма их частей, но и продукт их взаимодействия. Дефекты в программном обеспечении имеют тенденцию накапливаться в процессе разработки - путем декомпозиции больших задач на более мелкие и стандартизации различных этапов разработки необходимо найти и устранить первопричины дефектов. Чем крупнее система, чем больше организаций участвует в ее разработке и чем больше частей разрабатывается разными командами, тем важнее иметь четко определенные отношения между различными поставщиками для создания системы с плавно взаимодействующими компонентами. В течение более длительного периода развития более сильная сеть субподрядчиков намного выгоднее, чем краткосрочная оптимизация прибыли, которая не способствует взаимовыгодным отношениям.
Бережливое мышление должно быть хорошо понято всеми участниками проекта, прежде чем реализовывать его в конкретной реальной ситуации. «Думайте масштабно, действуйте мелко, быстро терпите неудачу; быстро учитесь» [8] - эти лозунги суммируют важность понимания области и целесообразность внедрения принципов бережливого производства на протяжении всего процесса разработки программного обеспечения. Только когда все принципы бережливого производства реализованы вместе, в сочетании с сильным «здравым смыслом» в отношении рабочей среды, есть основа для успеха в разработке программного обеспечения .
Бережливое программное обеспечение
Практика бережливой разработки программного обеспечения, или то, что Поппендикс называет «инструментами», немного отличается от исходных эквивалентов гибкой разработки программного обеспечения . Примеры такой практики включают:
- Видя отходы
- Значение карты потока
- Установленная разработка
- Системы вытягивания
- Теория массового обслуживания
- Мотивация
- Измерения
- Разработка через тестирование
Поскольку гибкая разработка программного обеспечения - это общий термин для набора методов и практик, основанных на ценностях и принципах, изложенных в Agile Manifesto, бережливая разработка программного обеспечения считается гибким методом разработки программного обеспечения. [9]
Смотрите также
- Экстремальное программирование
- DevOps
- Канбан
- Канбан-доска
- Бережливая интеграция
- Бережливые услуги
- Scrum (разработка)
Рекомендации
- ^ Ясухиро Монден (1998), Производственная система Toyota, Комплексный подход к своевременности , третье издание, Norcross, Джорджия: Engineering & Management Press, ISBN 0-412-83930-X .
- ^ Мэри Поппендик; Том Поппендик (2003). Бережливая разработка программного обеспечения: Agile Toolkit . Эддисон-Уэсли Профессионал. ISBN 978-0-321-15078-3.
- ^ Мэри Поппендик: «Роль руководства в разработке программного обеспечения» https://www.youtube.com/watch?v=ypEMdjslEOI
- ^ Мэри Поппендик; Том Поппендик (2003). Бережливая разработка программного обеспечения: Agile Toolkit . Эддисон-Уэсли Профессионал. С. 13–15. ISBN 978-0-321-15078-3.
- ^ Мэри Поппендик; Том Поппендик (2003). Бережливая разработка программного обеспечения: Agile Toolkit . Эддисон-Уэсли Профессионал. С. 19–22. ISBN 978-0-321-15078-3.
- ^ «12 принципов Agile Manifesto - Agile Alliance» . agilealliance.org . 4 ноября 2015.
- ^ Отметить линии; Скотт В. Эмблер (2012). Дисциплинированная гибкая доставка: практическое руководство по гибкой доставке программного обеспечения на предприятии . IBM Press. С. 54–. ISBN 978-0-13-281013-5.
- ^ Мэри Поппендик; Том Поппендик (2003). Бережливая разработка программного обеспечения: Agile Toolkit . Эддисон-Уэсли Профессионал. С. 182–. ISBN 978-0-321-15078-3.
- ^ «Что такое гибкая разработка программного обеспечения?» . agilealliance.org . 29 июня 2015.
дальнейшее чтение
- Ладас, Кори (январь 2008 г.). Scrumban: Очерки канбан-систем для экономичной разработки программного обеспечения . Modus Cooperandi Press. ISBN 978-0-578-00214-9.
- Райс, Эрик (сентябрь 2011 г.). Экономичный стартап : как современные предприниматели используют непрерывные инновации для создания радикально успешного бизнеса . Корона Бизнес. ISBN 978-0307887894.