Телефон:
8 (929) 574-86-83

Lean-разработка программного обеспечения (23.10.2009)

Если применить принципы и технологии бережливого производства, т.е. lean-производства, к области разработки программного обеспечения, то получится бережливая разработка ПО или lean-разработка. Культура, выступающая в поддержку lean-разработки ПО, т.е. pro-lean культура, в основе которой лежат принципы Производственной системы Тойоты (TPS – Toyota Production System), произрастает из сообщества сторонников Agile, т.е. гибкой методологии разработки.

Происхождение
Термин «lean-разработка программного обеспечения» (Lean Software Development) впервые встречается в одноименной книге Mary и Tom Poppendieck. В книге изложены несколько видоизмененные принципы бережливого производства и его же 22 инструмента, приведен сравнительный анализ этих инструментов и технологий Agile. Благодаря активному участию авторов книги в жизни Agile-сообщества, в том числе их выступлениях на нескольких тематических конференциях, теория lean-разработки находила всё больше сторонников среди Agile-сообщества.

Lean-принципы
Бережливая разработка ПО складывается из семи принципов, довольно схожих с принципами бережливого производства.

Исключение затрат
Принцип исключения затрат (или muda, как в Toyota называют определенный тип затрат) был позаимствован у Тайити Оно (Taiichi Ohno), отца-основателя Производственной системы Тойоты. Он выделял как причины затрат следующие компоненты:

складирование автомобильных деталей в ожидании их использования
производство чего-либо, что не нужно прямо сейчас
передвижение компонентов, не приносящее пользы
время, потраченное на ожидание производства других частей
излишние этапы производства
дефекты (низкое качество)

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

Лишний код и функциональность
Ожидание в процессе разработки ПО
Неясные/нечеткие требования
Сложный бюрократический аппарат
Медленное внутреннее сообщение

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

Акцент на обучении
Разработка программного обеспечения – непрерывный процесс обучения, осложненный дополнительными задачами групп разработки и размерами конечного продукта. Наилучшим подходом к улучшению окружения разработки программного обеспечения является обучение. Чтобы не накапливать дефекты, необходимо, как только написан код, прогонять тесты. Вместо дополнительного написания документации или более детального планирования многие идеи можно испробовать, написав код и building. Чтобы облегчить изучение требований пользователя, можно конечному потребителю показать скрины и узнать его мнение.
Процесс обучения ускоряется сокращением циклов итерации, каждый из которых сопровождается реструктуризацией и интеграционным тестированием. Налаживание обратной связи (для чего достаточно коротких встреч с заказчиком) помогает в определении текущей фазы разработки и оценке трудозатрат на улучшения, необходимые в дальнейшем. Во время таких встреч как представители заказчика, так и группа разработки обсуждают возникающие проблемы и находят подходящие решения, используемые для разработки. Таким образом, заказчик лучше представляет себе, что ему нужно, исходя из имеющихся результатов работы разработчиков, а разработчик понимает, как угодить заказчику. Другой метод процесса обучения и взаимодействия с заказчиком - set-based разработка– сосредоточен на обсуждении исключении будущих решений (т.е. сужении множества возможных/приемлемых решений, что ли? – прим. переводчика), а не на поиске подходящих решений, таким образом, продвигаясь в появлении решения посредством диалога с заказчиком.

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

Предельно быстрая доставка заказчику
В эру развития скоростных технологий, выживают не самые большие, а самые быстрые. Чем быстрее будет доставлен конечный продукт без существенных дефектов, тем быстрее на этот результат будет получен отклик, который учитывается в следующей итерации. Чем короче итерации, тем лучше понимание и взаимодействие в команде. Если всё происходит медленно, не получится отсрочивать решения. Скорость позволяет удовлетворить именно сегодняшние нужды заказчика. Таким образом, у заказчика появляется возможность отсрочить составление представлений о том, чего же он на самом деле хочет, до тех пор, пока он получит больше знаний. Заказчик ценит быструю доставку качественного продукта.
Принципы оперативной системы производства с нулевым уровнем запасов можно применить и к разработке ПО, достаточно учитывать требования и условия этой сферы. Чтобы этого достичь, необходимо ознакомить команду с требуемыми результатами, позволить ей организоваться и разделить задания для достижения целевого на данную итерацию результата. Сначала необходимая задача ставится заказчиком. Она может быть представлена в форме маленьких карточек или рассказов – разработчики высчитывают время, необходимое для внедрения каждой карточки. Таким образом, организация работы сама напоминает о себе: по утрам во время короткого совещания каждый сотрудник сообщает о проделанной вчера работе, о том, что нужно сделать сегодня и завтра, задает вопросы и говорит, какие уточнения ему нужны от заказчика. Для этого необходима прозрачность процесса, что также улучшает атмосферу в коллективе. Еще одна ключевая идея разработки, вытекающая из принципов производства Тойоты, - это set-based дизайн. К примеру, если необходимо разработать новую тормозную систему для машины, то ее разработку можно поручить не одной команде, а трем, и в результате получить три варианта. Если одной из команд предполагает нецелесообразное решение, то она отсеивается. Когда сроки, установленные на выполнение работы, подходят к концу, из финишировавших вариантов выбирают оптимальный, возможно несколько усовершенствовав его идеями из других вариантов. Это великолепный пример того, как отсрочить решение до самого последнего момента. Решения в сфере разработки ПО также могут выигрывать на этой практике минимизацией риска за счет заблаговременной разработкой дизайна.

Мотивация команды
Так сложилось, что за принятие решений в организациях отвечают менеджеры: они говорят, как рабочим выполнять их работу. Эти роли меняются в технике принятия эффективных управленческих решений: менеджеров учат слушать разработчиков, чтобы они могли лучше объяснить, какие действия следует предпринять, и предлагали некоторые усовершенствования. Лаконичную формулировку ключика к успешному проекту предлагают наиболее опытные менеджеры проектов: «Найдите хороших людей и позвольте им сделать их собственную работу».
Расценивать людей как ресурсы – еще один предрассудок менеджмента. С точки зрения статистики, когда только данные людей занесены в таблицу, возможно, люди представляются лишь ресурсами, но при разработке ПО, как и при любой другой организационной задаче, людям нужно нечто большее, чем список заданий и уверенность в том, что им никто не помешает эти задания выполнить. Людям нужна мотивация и высшая цель, ради которой они работают, - цель в пределах достижимой реальности, наполненной уверенностью, что команда самостоятельно сможет брать на себя обязательства. Разработчикам необходимо обладать возможностью связи с заказчиком; руководитель команды должен обеспечивать поддержку и помощь в сложных ситуациях, а также следить, чтобы скептицизм не разрушал командный дух.

Внедрение целостности
Заказчику необходимо дать представление о системе полностью, обеспечить так называемую воспринимаемую целостность: как ее рекламируют, доставляют, разворачивают, насколько она доступна и насколько хорошо она справляется со своими задачами, насколько легко научится ей пользоваться, сколько она стоит. Концептуальная целостность означает, что отдельные компоненты системы отлично вместе работают при сбалансированных гибкости, удобстве эксплуатации, эффективности и реактивности. Этого можно добиться с помощью понимания области проблемы и одновременного ее разрешения, а не последовательного. Необходимая информация получается малыми частями, а не одной большой порцией при одной очной встрече, и не безо всякой письменной документации. Поток информации должен быть постоянным для обеих сторон – от заказчика к разработчикам и обратно, таким образом, предотвращая выдачу не воспринимаемых объемов информации после долгого периода бесконтактной разработки.
К целостной архитектуре может привести применение рефакторинга. Чем больше опций добавляется в систему, тем более гибкими для дальнейших улучшений следует создавать code base. Как описано выше (где????), в методе XP agile рефакторинг сохраняет простоту, ясность, минимизирует опции в коде. Следует избегать повторов в коде, поскольку они свидетельствуют о плохом дизайне кода. Полный и автоматизированный процесс построения должен сопровождаться полным и автоматизированным набором проверок со стороны разработчика и потребителя, при наличии у них поддержки тех же версий, синхронизации и семантики, что и у системы в настоящий момент. В конце целостность должна быть выверена посредством тестирования, чтобы удостовериться, что система соответствует ожиданиям заказчика. Автоматизированные тесты также составляют весомую часть производственного процесса, а значит, если они не добавляют ценности для заказчика, их следует считать затратами. Автоматизированное тестирование должно быть не целью, а средством достижения цели – снизить число дефектов.

В общем,
сегодня софтверные системы представляют собой не только сумму составляющих их частей, но и результат взаимодействия этих частей. Дефекты в софте накапливаются по мере разработки, поэтому следует выявлять первопричины дефектов и устранять их, разбивая большие задачи на более мелкие и стандартизируя различные стадии разработки. Чем больше система, чем большее число организаций, занятых в ее разработке, и чем больше частей разрабатывается различными командами, тем важнее установить четко определенные отношения между разработчиками. Только так получится произвести систему со слаженно работающими компонентами. При долгосрочной разработке выгоднее опираться на сеть надежных субподрядчиков, чем на краткосрочную оптимизацию прибыли, которая не приводит к взаимовыгодным отношениям.
Все участники проекта должны глубоко проникнуться lean-философией, прежде чем вышеперечисленные принципы будут внедрены в конкретный проект. «Мыслить широко, действовать мало, промахиваться быстро; учиться стремительно,» - эти фразы отражают существенность соответствия области для внедрения принципов бережливой разработки ПО. Только если все lean-принципы работают вместе, в значительной мере подкрепленные здравым смыслом, с учетом рабочей атмосферы – только тогда заложен фундамент для успешной разработки ПО.