Введение
Использование принципов бережливого производства в разработке программного обеспечения
Бережливая разработка программного обеспечения – это применение принципов и практик бережливого производства в сфере разработки программного обеспечения. Зародившись на основе производственной системы Toyota, она развивается при поддержке сторонников бережливого подхода в сообществе гибкой разработки. Lean предоставляет надежную концептуальную основу, ценности и принципы, а также проверенные практики, основанные на опыте, которые поддерживают гибкие организации.
Происхождение
Выражение "бережливая разработка программного обеспечения" возникло в книге с тем же названием, написанной Мэри Поппендик и Томом Поппендиком в 2003 году. В книге переформулируются традиционные принципы бережливого производства, а также представлен набор из 22 инструментов, которые сравниваются с соответствующими практиками гибкой разработки. Участие Поппендиков в сообществе гибкой разработки программного обеспечения, включая выступления на нескольких конференциях Agile, способствовало более широкому принятию этих концепций в сообществе Agile.
Усилить обучение
Разработка программного обеспечения – это непрерывный процесс обучения, основанный на итерациях в процессе написания кода. Проектирование программного обеспечения – это процесс решения проблем, включающий разработчиков, пишущих код, и полученные ими знания. Ценность программного обеспечения измеряется его полезностью и пригодностью к использованию, а не соответствием требованиям. Вместо добавления дополнительной документации или детального планирования, можно попробовать различные идеи, написав код и создавая работающий продукт. Процесс сбора требований пользователей можно упростить, демонстрируя им макеты экранов и получая обратную связь. Накопление дефектов следует предотвращать, запуская тесты сразу после написания кода. Процесс обучения ускоряется за счет использования коротких итерационных циклов, каждый из которых сочетается с рефакторингом и интеграционным тестированием. Увеличение частоты обратной связи посредством коротких сессий с клиентами помогает определить текущую фазу разработки и скорректировать усилия для будущих улучшений. В ходе этих коротких сессий представители заказчика и команда разработчиков лучше понимают предметную область и находят возможные решения для дальнейшей разработки. Таким образом, заказчики лучше осознают свои потребности, основываясь на текущих результатах разработки, а разработчики учатся лучше удовлетворять эти потребности. Еще одна идея в процессе коммуникации и обучения с заказчиком – это разработка на основе множества вариантов (set-based development) – она фокусируется на донесении ограничений будущего решения, а не возможных вариантов, тем самым стимулируя поиск решения через диалог с заказчиком.
Решите как можно позже
Поскольку разработка программного обеспечения всегда сопряжена с определенной неопределенностью, лучших результатов следует достигать, используя подход, основанный на множестве вариантов, максимально откладывая принятие решений до тех пор, пока они не будут основаны на фактах, а не на неопределенных предположениях и прогнозах. Чем сложнее система, тем больше в ней должно быть заложено возможностей для изменений, что позволит отложить важные и критические обязательства. Итеративный подход способствует реализации этого принципа – способности адаптироваться к изменениям и исправлять ошибки, которые могут оказаться очень дорогостоящими, если их обнаружат после выпуска системы. При разработке на основе множества вариантов: если, например, для автомобиля требуется новая тормозная система, три команды могут разрабатывать решения одной и той же задачи. Каждая команда изучает предметную область и разрабатывает потенциальное решение. Как только решение признается нецелесообразным, оно отбрасывается. По истечении определенного периода оставшиеся варианты сравниваются, и один из них выбирается, возможно, с некоторыми модификациями, основанными на опыте, полученном при изучении других вариантов – прекрасный пример отсрочки принятия обязательств до последнего возможного момента. Принятие решений в области программного обеспечения также может выиграть от этой практики, позволяя минимизировать риски, связанные с масштабным предварительным проектированием. Кроме того, в результате будет существовать несколько корректных, но различных (с точки зрения реализации) вариантов. Их можно использовать для создания отказоустойчивых систем, которые одновременно проверяют корректность всех входных и выходных данных во всех реализациях. Гибкая методология разработки программного обеспечения позволяет предложить клиентам варианты на более раннем этапе, тем самым откладывая принятие некоторых критических решений до тех пор, пока клиенты не сформулируют свои потребности более четко. Это также обеспечивает возможность последующей адаптации к изменениям и предотвращает принятие дорогостоящих решений, основанных на устаревших технологиях. Это не означает, что планирование не требуется – наоборот, планирование должно быть сосредоточено на различных вариантах и адаптации к текущей ситуации, а также на прояснении неясных моментов путем разработки шаблонов для оперативного реагирования. Оценка различных вариантов эффективна, как только становится понятно, что они не бесплатны, но обеспечивают необходимую гибкость для принятия решений на поздних этапах.
Доставьте как можно быстрее .
В эпоху стремительного развития технологий выживает не сильнейший, а самый быстрый. Чем раньше конечный продукт будет поставлен без существенных дефектов, тем быстрее можно получить обратную связь и учесть её в следующей итерации. Чем короче итерации, тем эффективнее обучение и коммуникация внутри команды. Скорость позволяет откладывать принятие решений. Скорость гарантирует удовлетворение актуальных потребностей клиента, а не тех, что были у него вчера. Это даёт клиенту возможность не торопиться с определением своих истинных требований, пока он не получит больше информации. Клиенты ценят быструю поставку качественного продукта. Идеология производства "точно в срок" может быть применена к разработке программного обеспечения с учётом его специфических требований и условий. Это достигается путём формулирования необходимого результата и предоставления команде возможности самостоятельно организоваться и распределить задачи для его достижения в рамках конкретной итерации. На начальном этапе клиент предоставляет необходимую информацию, которую можно представить в виде небольших карточек или пользовательских историй. Разработчики оценивают время, необходимое для реализации каждой карточки. Таким образом, организация работы превращается в систему самообслуживания – каждое утро на ежедневном стендапе каждый член команды рассказывает о том, что было сделано вчера, что планируется сделать сегодня и завтра, и запрашивает необходимую помощь у коллег или клиента. Это требует прозрачности процесса, что также положительно влияет на командную коммуникацию. Распространённое мнение гласит, что спешка приводит к ошибкам. Однако опыт бережливого производства показывает, что быстрая поставка позволяет как можно раньше увидеть и проанализировать результат.
Поощряйте команду
В большинстве компаний сложилось традиционное представление о принятии решений в организации: менеджеры указывают сотрудникам, как выполнять свою работу. В технике "выработки решений" роли меняются – менеджеров учат слушать разработчиков, чтобы те могли лучше объяснить возможные действия и предложить улучшения. Lean-подход следует Agile-принципу "создавайте проекты вокруг мотивированных людей и доверяйте им выполнение работы", поощряя прогресс, выявляя ошибки и устраняя препятствия, но избегая микроменеджмента. Распространенной ошибкой является рассмотрение людей как ресурсов. С точки зрения статистических данных, люди могут быть ресурсами, но в разработке программного обеспечения, как и в любом бизнесе, людям нужно нечто большее, чем просто список задач и гарантия, что их не будут отвлекать во время работы. Людям нужна мотивация и более высокая цель, ради которой стоит работать – цель, укладывающаяся в рамки реальности, и уверенность в том, что команда может самостоятельно выбирать свои задачи. Разработчикам следует предоставить доступ к заказчику; руководитель команды должен оказывать поддержку и помощь в сложных ситуациях, а также следить за тем, чтобы скептицизм не подрывал командный дух. Уважение к людям и признание их вклада – один из способов расширить возможности команды.
Созидайте честность в
Клиент должен получить целостное представление о системе. Это так называемая воспринимаемая целостность: то, как система рекламируется, поставляется, развертывается, к ней осуществляется доступ, насколько интуитивно понятна ее работа, ее цена и насколько эффективно она решает проблемы. Концептуальная целостность означает, что отдельные компоненты системы хорошо взаимодействуют друг с другом, образуя единое целое, с соблюдением баланса между гибкостью, поддерживаемостью, эффективностью и отзывчивостью. Этого можно достичь, понимая предметную область и решая задачу одновременно, а не последовательно. Необходимая информация должна поступать небольшими порциями, а не одним большим объемом, предпочтительно в ходе личного общения, а не в виде письменной документации. Информационный поток должен быть постоянным в обоих направлениях – от клиента к разработчикам и обратно, что позволит избежать перегрузки информацией после длительной изолированной разработки. Рефакторинг – один из эффективных способов достижения целостной архитектуры. Чем больше функций добавляется в исходный код, тем сложнее вносить дальнейшие улучшения. Рефакторинг направлен на поддержание простоты, ясности и минимального количества функций в коде. Повторения в коде свидетельствуют о плохом дизайне и должны быть исключены (например, путем применения принципа DRY). Полный и автоматизированный процесс сборки должен сопровождаться полным и автоматизированным набором тестов для разработчиков и пользователей, имеющим ту же версию, синхронизацию и семантику, что и текущее состояние системы. В конечном итоге целостность должна быть подтверждена тщательным тестированием, гарантирующим, что система соответствует ожиданиям клиента. Автоматизированные тесты также рассматриваются как часть производственного процесса, поэтому, если они не приносят пользы, их следует считать отходами. Автоматизированное тестирование не должно быть самоцелью, а скорее средством достижения цели – сокращения количества дефектов.
Оптимизировать все
Современные программные системы – это не просто сумма составляющих их частей, но и результат их взаимодействия. Дефекты в программном обеспечении, как правило, накапливаются в процессе разработки. Разложение больших задач на более мелкие и стандартизация различных этапов разработки должны способствовать выявлению и устранению первопричин этих дефектов. Чем больше система, чем больше организаций участвует в её разработке и чем больше компонентов создается разными командами, тем важнее четко определенные взаимоотношения между поставщиками для создания системы с плавно взаимодействующими компонентами. В долгосрочной перспективе развитие прочной сети субподрядчиков гораздо выгоднее, чем краткосрочная оптимизация прибыли, которая не позволяет выстраивать взаимовыгодные отношения. Все участники проекта должны хорошо понимать принципы бережливого производства (Lean) перед их внедрением в реальную практику. "Думай масштабно, действуй поэтапно, быстро проваливайся, быстро учись" – эти лозунги отражают важность понимания предметной области и целесообразность применения принципов бережливого производства на протяжении всего процесса разработки программного обеспечения. Только комплексное внедрение всех принципов бережливого производства в сочетании с разумным подходом к рабочей среде создает основу для успеха в разработке программного обеспечения.