Бережливое производство – это концепция управления производством, основанная на сокращении различного рода потерь. Впервые принципы бережливого производства были разработаны японской компанией Toyota в начале 1990х годов.
В этой книге авторы рассказывают, как компании занятые разработкой программного обеспечения могут оптимизировать свои технологические процессы.
Семь принципов бережливого подхода в разработке ПО
Принцип 1. Ликвидировать потериВсе, что мы делаем, если это не работает на то чтобы наиболее полным образом удовлетворить требования заказчика, является источником непроизводительных затрат. Сюда же можно отнести любую задержку выполнения заказа
В первую очередь авторы рекомендуют сократить потери на исправление уже выполненной работы. Самый яркий пример – тот случай, когда Клиент просит внести изменения в уже утвержденное Техническое Задание или Макеты Дизайна. Если подобные вещи происходят, значит вы выбрали слишком большой цикл разработки. Возможные пути решения:
- Разбивать разработку всего продукта на короткие итерации (1-3 месяца).
- Писать документацию не на весь продукт, а только на ближайшую итерацию, чтобы бизнес Клиента не успел измениться.
- Создавать меньше программного кода. Следует жестко ограничивать функциональные возможности релиза и в первую очередь делать лишь те, которые абсолютно необходимы для бизнеса Клиента.
- Сократить число случаев, когда работа передается другому лицу (или коллективу).
- Использовать многофункциональные коллективы, в которых люди могли бы учиться друг у друга.
- Где возможно – заменить передачу знания через документацию очными обсуждениями, непосредственным наблюдением, а также работой с макетами, прототипами и имитаторами.
- Выпускать созданные продукты заблаговременно (и частично готовыми) заказчикам для ознакомления и организации с ними обратной связи – так быстро, как это возможно, и так часто, как это практично
Целесообразно сначала полностью разработать 20% программного кода, которые обеспечивали бы 80% потребностей заказчика, и только после этого переходить к разработке следующих наиболее необходимых функциональных возможностей. Не следует заранее составлять список всех возможностей, которые могут когда-либо понадобиться, особенно если этот список исходит от заказчиков, которые не очень хорошо знают, что им нужно.
Принцип 2. Встраивать качество
Процесс разработки следует выстраивать так, чтобы дефекты просто не попадали в код. Если на этапе тестирования выявляется много ошибок (багов), то это означает, что тестирование производится слишком редко. Дефекты во время финального тестирования должны стать редкостью, а не нормой.
С точки зрения бережливого производства не должно быть очереди дефектов на исправление. Ошибки должны исправляться в тот же момент, когда они обнаруживаются.
Сегодня существуют средства, позволяющие устранять дефекты из программного кода в ходе его создания. Группа разработчиков, используя разработку через тестирование (test driven development), создает блочные тесты и приемочные тесты до создания соответствующего кода.
Разработчики интегрируют код и тесты в систему так часто, как это возможно (каждый час или около того) и инициируют запуск тестовой нагрузки (test harness), чтобы убедиться, что со времени предыдущей проверки дефекты в коде не появились. Если тест не выполняется, они не создают новый код, пока проблема не будет устранена. В конце дня запускается более сложная и полная тестовая нагрузка. В конце недели система проверяется с помощью еще более сложной тестовой нагрузки.
В организациях, где используется такой подход, дефекты возникают редко и их причины устраняются очень быстро.
Принцип 3. Создавать знание
Недостаток "водопадной" модели разработки заключается в том, что архитектура будущего продукта создается заранее и часто совсем не теми людьми, которые будут заниматься непосредственно разработкой. Однако достоинства и недостатки этой архитектуры будут обнаружены после реализации.
При таком подходе невозможно учесть всей сложности, с которой придется столкнуться в ходе разработки. Также проблематично будет вносить пожелания от Клиента или Пользователей продукта, во время обратной связи.
Некоторые полагают, что если мы ‘‘документируем’’ то, что узнали в процессе итеративной разработки (т.е. записываем принятые решения; объясняем, почему они приняты, и перечисляем, что мы узнали нового), то создаем материал, который может быть использован в данной организации для обучения коллег. Однако, скорее всего, эти кипы документации будут просто собирать пыль
Процесс разработки, направленный на создание знания, предполагает, что архитектура программного обеспечения возникнет во время создания программного кода, и исключает затраты на его предварительное определение.
В книге предлагается четыре подхода:
- Ранний релиз с минимумом функциональных возможностей с тем, чтобы потребители могли его оценить и выразить свое мнение, пожелания и претензии.
- Ежедневный выпуск сборок, их тестирование и учет (в дальнейшей разработке) результатов тестирования.
- Наличие коллектива и (или) лидера с достаточным опытом и развитой интуицией, позволяющих принимать правильные решения.
- Использование модульной архитектуры, поддерживающей возможность добавления новых функций.
Принцип 4. Откладывать необратимые решения
Идея заключается в том, что принятие необратимого решения должно откладывать до последнего момента, но прежде, чем будет слишком поздно. Это позволит набрать максимум доступной информации и сделать обдуманное действие.
Не следует поддаваться мифу, что планирование – это то же, что и принятие обязательств. Планировать следует тщательно, а брать обязательства осторожно. Реальность всегда расходится с первоначальным планом и решения в условиях изменившихся обстоятельств должны приниматься быстро.
Если все время придерживаться однажды принятой идеи и не вносить изменений в планы, в такой обстановке бизнес не сможет существовать долго.
Принцип 5. Доставлять быстро
Если вы смогли ликвидировать большую часть непроизводственных затрат, это влечет к сокращению сроков и стоимости на поставку готового продукта. Быстрая доставка невозможна без высокого качества.
Мне удавалось избегать ‘‘водопадной’’ методологии разработки вплоть до 1999 года, когда я приступила к работе над государственным проектом. Я была просто озадачена подобным подходом, потому что не могла понять, как это работает; и в действительности это не работало.
Принцип 6. Уважать людей
Быстрые поставки и высокое качество возможно только в коллективе, который работает как одна слаженная команда. Однако, по большей части создаются рабочие группы, а не команды. Отличие в том, что в группе работа каждого участника оценивается индивидуально.
Если участники разработки знают, что в конце проекта будет оцениваться лишь личная эффективность каждого, то логика подсказывает, что каждый сотрудник должны каким-то образом показать руководству, что он лучше остальных коллег. Например, поискать виновного в ошибке или показать чьи ошибки ему приходилось постоянно исправлять.
Вероятно, наиболее игнорируемым советом Деминга является следующий: ликвидировать ежегодные оценки индивидуальной эффективности для работников, которые на окладе; не следует подрывать сотрудничество в коллективе, награждая за индивидуальную эффективность.
Авторы считают, что участники команды должны вознаграждаться на основе достижений команды в целом, а не от вклада личных достижений. Например, тестировщики не должны награждаться за число найденных дефектов, а разработчики за количество написанных строк кода. Разработчики и тестировщики должны награждаться вместе, за способность создавать свободные от дефектов код. Весь коллектив должен быть вознагражден за экономический успех результатов их работы.
Принцип 7. Оптимизировать целое
Бесполезно оптимизировать какую-то одну часть производства. Необходимо расписать процесс создания продукта с момента заказа, до момента получения оплаты и оптимизировать поток создания ценности целиком.
Если в потоке создания ценности обнаружатся большие задержки между подразделениями организации. Любая идея, позволяющая ускорить поток создания ценности через эти барьеры, приведет к сокращению непроизводственных затрат.
Предпочтение индивидуальным поощрениям перед коллективными, плохие условия труда, неприемлемые сроки, отсутствие времени для должных тестирования и рефакторинга, навязанные процессы, рутинная (больше подходящая для роботов) работа и т.п.
Старайтесь искоренить все перечисленное: не создавайте конфликтных стимулов между членами коллектива, автоматизируйте рутинные задачи, предоставьте работникам самим определить оптимальные методы выполнения работы, никогда не требуйте соблюдения невозможных сроков.
Это окажет куда больший положительный эффект, чем индивидуальные стимулы и премии.
Итоги
Семь принципов – лишь верхушка айсберга. В книге огромное количество интересных подходов и примеров. Правда, некоторые советы предполагают, что у вас неограниченный бюджет.
Кстати, в книге нет информации о подсчете стоимости производства. Прекрасно расписано, что нужно делать, но вот убеждать Клиента работать по такому подходу (когда большая часть рынка обещает фиксированные сроки на разработку) будет непросто.
Думаю, что в первую очередь книга пригодится руководителям IT-отделов, которые разрабатывают и поддерживают собственный продукт. Обычно в этом случае имеется стационарная команда или фиксированный пул подрядчиков. Также она будет полезна и веб-студиям.
Жалею, что не прочитал эту книгу раньше, она из разряда Must-have. К сожалению, последнее издание было выпущено в 2010 году и теперь её сложно найти в продаже.
Посмотреть книгу на Озоне
Чернов Дмитрий© chernov.pro
