Бережливая разработка программного обеспечения
26 Мар 2009 Игорь Лужанский в рубрике Lean в России и мире, Интересно | 8 комментариев
Просмотров: 24 894Они могут быть четко идентифицированы, но их сложно признать. Проблемы в разработке программного обеспечения являются основной причиной провалов ИТ проектов, что вынуждает руководителей во всем мире внедрять жесткие контролирующие процессы для того чтобы гарантировать успех проекта. Ужесточение процессов на каждой стадии проекта превращает весь процесс разработки в «спасательный жилет».
Использование подходов бережливого производства позволяет не только решить проблемы разработки программного обеспечения (в том числе проблемы качества), но и внедрить принципы постоянного совершенствования в процесс разработки.
Причины провалов проектов по созданию ПО
Следующие факторы были идентифицированы как основные причины провалов проектов по созданию программного обеспечения.
Часто и неожиданно изменяющиеся требования заказчика
Проблема консервативного подхода к разработке программного обеспечения лежит в предположении, что требования заказчика неизменны и могут быть идентифицированы заранее. Но поскольку требования меняются достаточно часто в течение жизни большинства систем, они не всегда могут быть адекватно отражены с помощью жесткого, негибкого дизайна системы. «Делайте правильно» (Do it right) было так же ошибочно интерпретировано, как «Не позволяйте изменений», что в свою очередь спровоцирует недовольство клиентов. С другой стороны, если изменения разрешены в течение проекта, у компании будут проблемы с поставкой ПО согласно основной линии проекта.
Централизованное принятие решений
Крупные компании по разработке программного обеспечения до сих пор используют традиционный директивный подход при принятии решений. Каждый раз, когда решение принимается, оно должно пройти весь путь с самой верхушки организационной структуры проекта к конечным исполнителям. Такой подход увеличивает время разработки и делает весь процесс негибким и медленным.
Жесткое управление объёмом работ по проекту
Удержание проекта в рамках, согласованных на начальной стадии, приносит мало пользы заказчикам, требования которых изменяются. В действительности такой подход только сеет тревогу и парализует способность принимать решения, обеспечивая лишь то, что система будет частично устаревшей к моменту её запуска. Таким образом, управление работами, которые не нужны заказчику, являются прямыми потерями времени и ресурсов.
Тем не менее, до тех пор, пока ограничение проекта своим изначальным объёмом работ будет ключевой задачей менеджера, локальная оптимизация будет процветать за счет качества всего проекта.
Традиционный (линейный) подход к разработке
Большинство проблем с качеством при разработке программных компонентов возникает из-за линейности процесса разработки, которая не предусматривает проверку качества до того, как компонент перешел на следующую стадию цикла разработки. То есть разработка продолжается даже тогда, когда существуют проблемы с качеством («баги»)
Принципы бережливого производства
Принципы бережливого производства, которые суммированы ниже, могут использоваться как основа или руководство для решения большинства проблем в мире разработки программного обеспечения:
Создавать ценность и ничего более
1. Устранять потери
2. Сокращать уровень запасов
3. Делать качественно с первого раза
Акцент на тех, кто добавляет ценность
4. Поддерживать (назначать, поощрять) тех, кто добавляет ценность
5. Постоянно совершенствоваться
Вытягивать ценность
6. Соответствовать требованиям потребителей
7. Вытягивать спросом (ориентируясь на спрос)
8. Улучшать поток создания ценности
Помогать окружающим в оптимизации
9. Запрет локальной оптимизации
10. Партнерство с поставщиками
Применение принципов бережливого производства к процессу разработки программного обеспечения
(«Lean Software Development»)
В основном принципы бережливого производства могут быть применены к разработке программного обеспечения для решения существующих проблем, улучшения самого процесса разработки и получения лучших качественных и количественных результатов.
Устранять потери
Первым шагом для освоения бережливого мышления, является понимание того, что такое «ценность» для потребителя, и определение действий и ресурсов, абсолютно необходимых для того, чтобы создавать ценность. Работа по выявлению того, что создает ценность, а что нет, должна быть проведена честно и беспристрастно, так как многим людям трудно признаваться в том, что их труд не добавляет ценности конечному продукту и, следовательно, создаёт потери. Семь типов производственных потерь, сформулированные Тайити Оно, представлены ниже
Семь типов производственных потерь
1. Перепроизводство
2. Излишние запасы
3. Излишняя обработка
4. Ненужные перемещения
5. Выпуск дефектной продукции
6. Ожидание
7. Ненужная транспортировка
Семь типов производственных потерь так же применимы к разработке программного обеспечения, что представлено в таблице ниже
Семь типов потерь при разработке ПО
1. Перепроизводство (Экстра функциональность)
2. Излишние запасы (Требования)
3. Излишняя обработка (Дополнительные шаги разработки)
4. Ненужные перемещения (Поиск информации)
5. Выпуск дефектной продукции (Баги, не выявленные при тестировании)
6. Ожидание (Ожидание решений, ожидание клиентов)
7. Ненужная транспортировка (Передача проекта, требований, знаний, развертывание систем)
Проектная команда должна пытаться исключать потери, которые обычно присутствуют в процессе разработки программного обеспечения.
Делать правильно с первого раза
«Делать правильно с первого раза» не означает «заморозить спецификацию». Наоборот, требования (спецификация) к системе постоянно изменяются. Дисциплина бережливого производства требует мгновенной адаптации к изменяющимся условиям рынка и требованиям заказчика. Это лучше всего реализуется с помощью гибкой архитектуры, которая позволяет системе легко приспосабливаться к изменениям, а также технологии мониторинга, определяющей ошибки перед тем, как они происходят, и тестов разработанных перед началом разработки.
Правило «делать правильно с первого раза» часто используется для того, чтобы оправдать разработку детальной спецификации перед написанием кода.
Проблема такого подхода заключается в предположении, что требования заказчика неизменны и могут быть заранее определены. Но поскольку требования меняются часто в течение жизни большинства систем, они не всегда могут быть адекватно отражены с помощью жесткого дизайна, негибкого дизайна системы.
Если мы принимает за аксиому, что клиенты могут не знать, что они хотят в начале процесса разработки и что их требования могут измениться, мы должны встроить в процесс разработки возможность получения обратной связи от клиента. Вместо этого большинство практик разработки программного обеспечения включают в себя сложный «процесс контроля изменений», который мешает разработчикам отвечать на обратную связь клиентов. Такой подход сопротивлений изменениям далек от того, чтобы привести к качественным результатам разработки.
Бережливая разработка использует две ключевые технологии, которые делают изменения простыми. Точно так, как бережливое производство встраивает проверку качества в производственный процесс для определения того, когда процесс нарушен, бережливая разработка должна «встраивать тесты» на различных стадиях процесса разработки. В случае, если происходят изменения во время разработки, необходимо использовать юнит и регрессионное тестирование (примечание переводчика: юнит тестирование — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже написанных и оттестированных местах программы, а также облегчает локализацию и устранение таких ошибок. Регрессионное тестирование — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода). Если тесты не проходят удачно, программирование должно быть остановлено до тех пор, пока проблема не будет обнаружена и исправлена. Всеобъемлющее тестирование – лучший способ быть готовым к изменениям в течение процесса разработки.
Вторая технология, которая облегчает процесс изменений ,– это рефакторинг (улучшение кода программы без изменения функциональности системы). Рефакторинг помогает сфокусироваться на изначальном дизайне и текущих возможностях системы, нежели на функциональности, которая может гипотетически понадобиться в будущем. Далее, используя технику рефакторинга, можно добавлять дополнительные характеристики, когда они потребуются, позволяя легко приспосабливать к будущему, когда оно становится настоящим.
Поддерживать тех, кто добавляет ценность
Базовый принцип бережливого производства — это делегирование полномочий и права принимать решения на по возможности нижний уровень организационной структуры. А так же передача власти людям «в цеху». Часто, когда проект по разработке ПО не справляется со своими задачами, интуитивной реакцией менеджмента является установление более жестких процессов, которые с большой детальностью указывают людям как, они должны делать свою работу. Принцип бережливого производства предлагает абсолютно противоположный подход. Когда проблемы возникают в производстве, команда внешних экспертов не посылает документ с детальным описанием того, как должен работать процесс. Наоборот, людям на производстве дают инструменты для оценки и улучшения своей работы. Они работают в межфункциональных командах с задачей улучшить свои процессы и связать их с соответствующими процессами поставщиков или заказчиков. Их супервизоры обучены методам формирования и поддержки работы команд с целью решения их проблем.
Бережливое производство ставит на первое место людей и командное взаимодействие, нежели бумажную работу и процессы. Оно фокусируется на методах формирования и поддержки команд в их стремлении находить и решать собственные проблемы, признавая, что люди выполняющие работу, должны сами определить детали выполнения работы.
Разработка программного обеспечения включает в себя передачу информации, как минимум один раз (от пользователя разработчику) но, как правило, более одного раза (от пользователя дизайнеру (аналитику), от дизайнера разработчику). При этом традиционный подход предполагает, что лучше всего передавать всю подобную информацию в письменном виде. В свою очередь бережливый подход предполагает, что наиболее эффективно создавать небольшие межфункциональные команды, которые работают сквозь информационные границы, тем самым уменьшая бумажную работу и улучшая коммуникацию.
Создавать культуру постоянного совершенствования
Сегодня в большинстве проектов по разработке ПО совершенство означает способность адаптироваться к быстрому, резко меняющемуся окружению. При этом подходам, основанным на процессах, таким как Software Engineering Institute’s (SEI) Capability Maturity Model (CMM), может не хватать гибкости для того, чтобы реагировать на быстрые изменения.
В итеративной разработке может эффективно использоваться метод Plan-Do-Check-Act (цикл Деминга). Например, во время первой итерации переход проекта от дизайна к разработке или от разработке к тестированию может быть несколько сырым. Это нормально, так как первая итерация обеспечивает обучение проектной команды, а последующие итерации позволят команде улучшить процесс.
В некотором смысле использование итераций во время разработки ПО делает его похожим на производственный процесс, поскольку процессы разработки повторяются, что позволяет применять цикл Деминга. Появляется возможность следовать простому Plan-Do-Check-Act принципу.
Plan (Планирование): установление целей и процессов, необходимых для достижения целей, планирование работ по достижению целей процесса и удовлетворения потребителя, планирование выделения и распределения необходимых ресурсов.
Do (Выполнение): Выполнение запланированных работ.
Check (Проверка): сбор информации и контроль результата, полученного в ходе выполнения процесса, выявление и анализ отклонений, установление причин отклонений.
Act (Воздействие – управление, корректировка): принятие мер по устранению причин отклонений от запланированного результата, изменение в планировании и распределение ресурсов.
Улучшение продукта/решения так же является итеративным процессом, частично благодаря использованию рефакторинга. В действительности рефакторинг обеспечивает эффективный механизм для улучшения проектов по разработке программного обеспечения. Тем не менее, нам необходима модель совершенствования, которая будет использоваться в более чем одном проекте. Мы должны повышать эффективность будущих проектов, обучаясь на существующих. И опять бережливое производство может указать нам путь.
Соответствовать требованиям заказчика
Philip Crosby определяет качество как «соответствие требованиям». В 1994 году Standish Group в своём исследовании «Charting the Seas of Information Technology—Chaos» отмечает, что наиболее распространенная причина провала проектов — это отсутствующие, неполные или неправильные требования. Разработчики программного обеспечения ответили на этот риск внедрением практики сбора детальных требований заказчика к системе и подписания этих требований у заказчика перед началом разработки. Несмотря ни на что эта практика широко используется. Как говорилось выше, в принципе «Делай правильно с первого раза» процесс разработки должен учитывать факт, того что требования пользователей могут изменяться, при этом приёмочное тестирование заказчиком (пользователем) должно происходить со ссылкой на требования пользователей.
Вытягивать спросом
Бережливое производство подразумевает быстрое, «точно вовремя» создание ценности для потребителя. В производстве ключевым для обеспечения скорости работы является использование маленьких партий, которые вытягиваются заказами потребителей. Аналогично в процессе разработки ПО ключевым для обеспечения быстрой работы является разделение проблемы на небольшие, части которые «вытягиваются» требованиями заказчиков. Единственный эффективный механизм реализации бережливого производства – это применение подхода «точно вовремя» и вытягивание спросом. Аналогично единственный и самый эффективный механизм реализации бережливой разработки — это работа небольшими итерациями, приносящими реальную пользу бизнесу в самые короткие сроки.
Улучшать поток
Главная идея бережливой разработки — это улучшение потока информации и создаваемой ценности. В бережливом производстве улучшение потока не всегда означает автоматизацию. Наоборот, это означает ограничение того, что должно транспортироваться, уменьшение количества транспортировок и сокращение расстояний. Аналогично в бережливой разработке доминирует идея сокращения как можно большего количества документов и передачи информации. Бережливая разработка подчеркивает важность объединения опытной команды разработчиков и клиентов, а так же предоставление этой команде права и ответственности разрабатывать систему с использованием небольших и быстрых итераций, основанных на приоритетах и обратной связи клиентов.
Запрет локальной оптимизации (Жесткое управление масштабом проекта)
Проектные менеджеры специально обучены фокусироваться на управлении объёмом работ в проекте, точно так же производственные менеджеры концентрируют свое внимание на производительности оборудования. Тем не менее, бережливая разработка опирается на время разработки и обратную связь от клиента. Подобно тому, как локальная оптимизация продуктивности ослабляет всю систему в целом, акцент на управлении масштабом проекта подрывает весь процесс разработки.
Лучшие практики закупок (Партнерство с поставщиками)
Высокое качество и креативность партнеров по цепочке поставок значительно перевешивает выгоды от традиционных тендеров и частой смены поставщиков. Партнерские компании помогают друг другу улучшать дизайн продукта и их поток, объединяя системы, которые позволяют материалам двигаться «точно вовремя» с минимальным количеством бумаг или совсем без бумаг. Такое сотрудничество является длительным, приносящим конкретные плоды.
Вывод
Бережливое производство — хорошая метафора для разработки программного обеспечения, если она применена в соответствии с духом бережливого мышления.
Предложенные принципы бережливой разработки следующие:
• Устранение потерь
• Удовлетворение заинтересованных сторон
• Поддержка (Назначения)
• Использование всеобъемлющего тестирования
• Сокращение времени разработки
• Рефакторинг
• Учиться на экспериментах
• Оценка влияния бизнеса
• Оптимизация во всей организации
Бережливое мышление предлагает нам не беспокоиться об объёме работ на проекте, если предметная область хорошо понята и существует хорошо подготовленное, высокоуровневое соглашение о том, как должна функционировать система.
Когда эти концепции применяются в правильном контексте и духе, это открывает новые возможности для улучшения процесса разработки.
Простейшие принципы бережливого производства и бережливого мышления могут привнести значительные изменения в большом количестве индустрий. Примененные к процессу разработки ПО, как «бережливая разработка», данные практики позволяют улучшить качество, сократить затраты и уменьшить время разработки.
Рекомендую:
Интервью с гуру. Часть 1. Масааки Имаи
Контроль качества продукта или процесса?
Что спасёт от кризиса?
Об авторе:
Подписывайтесь на Leaninfo.ru в соцсетях:
Или следите за новостями бережливого производства по email.
Смотрите также:
Трекбеки/Пинги
- Agile.Применение «Бережливой разработки ПО» – Блог Романа Василевича - [...] Agile разрушил мою жизньавтоматизация тестирования причины провалов старых подходов Scrum Scim.wiki Экстремальное программирование Основы Agile: [...]
- WEB development links | Размисли - [...] http://www.leaninfo.ru/2009/03/26/lean-software-development/ [...]
- Lean | Pearltrees - […] Бережливая разработка программного обеспечения. Они могут быть четко идентифицированы, но их сложно признать. […]
Оставить комментарий
Для отправки комментария вам необходимо авторизоваться.
Как бывший программист могу засвидетельствовать актуальность статьи и важность затронутых в ней вопросов. Как обычный пользователь программного обеспечения могу подтвердить необходимость принципиального изменения подхода к разработке ПО. Я думаю, не найдется ни одного человека, который бы не в той или иной мере не «пострадал» от недостаточного качества софта. И не важно о чем идет речь о продуктах компаний гигантов или мелких программных удобствах от небольших студий. Дело в том, что проблема выходит за рамки классических отношений между заказчиком и исполнителем. В массе своей разработка ПО делается под влиянием рыночных условий, когда важно «почувствовать» нишу и быстро ее занять. К сожалению, качество при этом падает просто катастрофически. Однако, время идет. Конкуренция на софт-рынку обостряется. Появляется все больше open-source проектов. Несомненно, что компании, которые не будут уделять достаточного внимания качеству своих продуктов — обречены. А между тем, речь не идет о чем-то сверхъестественном. Есть и техническая база и методология. Остается самая малость — прислушаться к желаниям потребителей!
Дмитрий, спасибо большое за комментарий очень хочется поддержать Вашу точку зрения.
Думаю, что на пути к бережливости в разработке ПО в нашей стране есть ещё 2 препятствия, кроме желания быстро занять нишу, вопреки качеству:
1) Перегретый рынок ПО — ИТшники сейчас на вес золота, заказчики стоят в очереди. Зачем в таких условиях совершенствоваться — ведь всё и так хорошо?
2) Разработчики больше интересуются техническими инструментами и методологиями, нежели философией и подходами, которые сложно в быстро и в чистом виде применить на практике как готовое решение.
Вот о получается, что если есть те кто задумывается об эффективности процесса разработки ПО, те тратят деньги на инструменты, которые не меняют сути и не решают причин возникающий проблем :(
Игорь а вы просто статьи пишите или занимаетесь внедрением? Если внедряете, то возможно у меня есть для вас клиент в СП-б. Свяжитесь со мной.
Игорь, спасибо за освещение темы,
Соглашусь так же, что осуществить на практике у нас это будет тяжело.
Все это похоже на старую идею коммунизма, решения принимаются внизу, разработчики работают на заказчика (рынок) без цепочки посредников (менеджеров).
Может это и парадоксально, но несмотря на понятную эффективность, прежде всего это не нужно хозяевам бизнеса.
Разработчик контактирующий с клиентом напрямую, тем более такой, что понимает клиента и его потребности, да еще и с легкостью и без лишних шагов реализующий то, что клиента полностью удовлетворит, может полностью разрушить и увести бизнес у хозяина. Вобщем это и не только в софтверном бизнесе так.
Зачем ему это нужно?
Законов в нашей стране защищающих хозяев нет, случаи ухода менеджеров с уводом клиентов — это скорее правило чем исключение.
Исходя из этого, создавая запутанную и заведомо неэффективную в плане производства структуру, хозяин бизнеса снижает риски потери бизнеса.
Ну и кроме этого есть еще микроэкономические законы бюрократизации большого бизнеса, и социопсихология, и причина краха коммунизма как идеи — то есть отсуствие идеальных людей готовых к самоотдаче за идею, предполагаемых абстрактными моделями, и присутствие реальных людей с их склонностями к игре, манипуляциям, и потребностям доминирования над другими, тем более в обществе потребления, в котором всячески поощряется такое поведение.
Да, а по поводу ИТшников на вес золота — не соглашусь.
Посмотреть по зарплатам на hh.ru — работа программиста сравнима с зарплатой автослесаря.
При этом возможно что интеллектуально и морально работа автослесаря меньше выматывает, и сил у автослесаря на свободное творчество оcтанется больше, так что и в плане самоактуализации работа автослесаря получше выглядит, чем работа программиста, который клиента не видит, и задача которого делать то, что говорят менеджеры (ну или не говорят, а пытаются заставить делать дешевыми уловками, скрытым управлением, стравливанием и т д).
По поводу сравнения с автослесарем: Кроме 10+ лет софта, в студенчестве (и до студенчества) попробовал много работ, случалось и машинным маслом торговать, говорю не просто так. :)
Поправьте меня если я не прав.
Кем, когда и для какой специфики проектов были предложены принципы бережливой разработки, перечисленные в статье? К сожалению, статья не раскрывает суть этих принципов, а простое перечисление неоднозначно для понимания.
Чем обоснованы различия с принципами, изложенными в книге Мэри и Тома Поппендика «Lean Software Development»?
Мне показалось, что принципы, изложенные в статье, это общие принципы бережливого производства. Автор переложил их на разработку ПО. Чтобы увидеть, как они раскрываются, вам придется порыться в первоисточниках по lean manufacturing — в одной статье, даже очень длинной, их не изложить.
Чем обоснованы? Ну и вопросы вы задаете, Павел… ;) Я слышал о книге М&Т Поппендиков, но вряд ли в России найдется сотня человек, которые прочитали эту книгу, т.е. тут их за классиков пока еще видимо не признали. ;)
Валерий, мой предыдущий комментарий относился исключительно к принципам изложенным в этой статье. Попробую проиллюстрировать неоднозначность:
-Удовлетворение заинтересованных сторон
Всех стэйкхолдеров? Их интересы противоречивы.
— Поддержка (Назначения)
Смысл совершенно не ясен.
(В производстве ПО, под «поддержкой» обычно понимается процесс сопровождения продукта.)
— Использование всеобъемлющего тестирования
Невозможность полного тестирования научно доказана.
Что имеется ввиду под «всеобъемлющим»?
— Сокращение времени разработки
В ущерб качеству?
— Рефакторинг
Ради рефакторинга?
— Учиться на экспериментах
Какие ценности создают эксперименты конечному потребителю?
— Оценка влияния бизнеса
Оценка в каких единицах? Влияния на что? С какой целью?
___
Относительно различий, могу переформулировать иначе: чем принципы в этой статье лучше, чем приведенные в Википедии:
— Исключение затрат.
Затратами считается всё, что не добавляет ценности для потребителя. В частности: излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение.
— Акцент на обучении.
Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.
— Предельно отсроченное принятие решений.
Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.
— Предельно быстрая доставка заказчику.
Короткие итерации.
— Мотивация команды.
Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий.
— Интегрирование.
Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.
— Целостное видение.
Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, действовать мало, промахиваться быстро; учиться стремительно».
Оригинал: http://ru.wikipedia.org/wiki/%D0%91%D0%B5%D1%80%D0%B5%D0%B6%D0%BB%D0%B8%D0%B2%D0%B0%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F