Они могут быть четко идентифицированы, но их сложно признать. Проблемы в разработке программного обеспечения являются основной причиной провалов ИТ проектов, что вынуждает руководителей во всем мире внедрять жесткие контролирующие процессы для того чтобы гарантировать успех проекта. Ужесточение процессов на каждой стадии проекта превращает весь процесс разработки в «спасательный жилет».

Использование подходов бережливого производства позволяет не только решить проблемы разработки программного обеспечения (в том числе проблемы качества), но и внедрить принципы постоянного совершенствования в процесс разработки.

Причины провалов проектов по созданию ПО

Следующие факторы были идентифицированы как основные причины провалов проектов по созданию программного обеспечения.

Часто и неожиданно изменяющиеся требования заказчика

Проблема консервативного подхода к разработке программного обеспечения лежит в предположении, что требования заказчика неизменны и могут быть идентифицированы заранее. Но поскольку требования меняются достаточно часто в течение жизни большинства систем, они не всегда могут быть адекватно отражены с помощью жесткого, негибкого дизайна системы. «Делайте правильно» (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. Масааки Имаи

Контроль качества продукта или процесса?

Что спасёт от кризиса?

Об авторе: