Читать онлайн «Гибкое управление проектами и продуктами». Страница 14

Традиционно выделяют также еще два вида потерь:

• му́ри (перегрузка);

• му́ра (неравномерность).

Принципы бережливого производства можно применить и в разработке программного обеспечения.

Уменьшение потерь. Видов потерь в разработке программного обеспечения достаточно много: от переключения между задачами до реализации лишнего функционала. Помните правило 20/80: 20 % функционала продукта приносят 80 % ценности заказчику, и именно гибкие методологии позволяют эти 20 % функционала выявить и назначить им максимальную важность.

Фокусировка на обучении. Весь процесс создания программного обеспечения фактически состоит из обучения: с каждой новой функцией мы узнаем что-то новое, поэтому, как и для любой другой инженерной деятельности, следует сосредотачиваться на обучении.

Встроенное качество. Необходимость высокого качества продуктов никто не оспаривает, но редко кто действительно вкладывает в это хотя бы чуточку усилий. В нашей индустрии есть устоявшиеся практики по контролю и обеспечению качества – это автоматические тесты и разработка в стиле TDD.

 Позднее принятие решений. Очень важно принимать решения как можно позже. Самым ярким примером здесь является создание архитектуры приложения. В противоположность подходу Big Up Front Design мы создаем архитектуру только для текущего функционала, следуя принципам KISS и YAGNI.

 Быстрая поставка. Бережливое производство ПО предполагает максимально быстрые и частые поставки для получения обратной связи.

 Уважение к людям. Люди – это основа любой мыслительной деятельности, к которой, несомненно, относится разработка ПО. Мы должны уважительно относиться к командам, предоставляя им максимум полномочий и ответственности.

 Оптимизация системы целиком. Мы должны оптимизировать всю систему целиком, не занимаюсь субоптимизацией отдельных сегментов.

Ниже приведены 14 принципов TPS.

1. Философия долгосрочной перспективы: можно пойти на убытки для достижения отдаленной цели.

2. Производственный поток должен быть непрерывным.

3. Канбан: производство по системе «точно вовремя» без промежуточных запасов.

4. Хейдзунка: равномерное распределение нагрузки на всех этапах технологического процесса.

5. Андон и дзидока: автоматическая остановка производства с целью решения проблем.

6. Формализация накопленных знаний: достигнутое нужно делать новым стандартом.

7. Визуальный контроль: иногда простая лампочка эффективнее компьютерного монитора.

8. Внедрять только проверенные технологии.

9. Воспитывать собственных лидеров, искренне исповедующих философию компании.

10. Формировать и воспитывать рабочие команды, в которых каждый искренне исповедует философию компании.

11. Уважать и развивать партнеров-поставщиков.

12. Генти гаубицу: перед тем как начать разбираться в ситуации, увидеть все своими глазами.

13. Немаваси: принимать коллективные решения только после согласия большинства, но внедрять немедленно.

14. Хансей и кайзен: любой процесс можно постоянно анализировать и совершенствовать.

Японское слово «кайзен» состоит из двух иероглифов, которые можно перевести как «изменения, направленные на улучшения».

Кайзен

На практике кайзен – это стратегия постоянного улучшения путем небольших изменений. Для реализации такого подхода необходимо следовать принципам кайзена, которые отлично согласуются с гибкими методологиями.

 Фокус на клиентах – мы должны быть сфокусированы на клиентах, причем не только на словах, но и на деле.

 Непрерывные изменения – все аспекты нашей производственной системы должны постоянно улучшаться небольшими шагами, для чего мы будем активно обсуждать процессы на ретроспективах.

 Открытое признание проблем – мы должны честно и открыто признавать и обсуждать все проблемы не для поиска виноватых, а для оптимизации процессов.

 Создание сообществ – организация сообществ (необязательно формальных) является важной частью оптимизации производства, потому что позволяет организовать обсуждения для инициативы снизу.

 Управление проектами с помощью межфункциональных команд – команды в Scrum максимально многофункциональны и включают в себя всех необходимых специалистов для реализации проекта.

 Формирование поддерживающих взаимоотношений – для организации таких взаимоотношений необходимо уделять внимание социальной атмосфере в коллективе.

 Развитие самодисциплины – команды в Scrum самоуправляемы и могут определять, как они будут достигать целей, поставленных владельцем продукта.

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

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

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

Карта потока создания ценности (Value Stream Mapping) – инструмент, который отображает стадии производственного процесса и время между ними. Затем производится подсчет эффективности процесса, как частное от полезного времени, когда добавлялась ценность продукту, и общего времени работы процесса.

Пример карты потока создания стоимости

После этого процесс перестраивается с целью увеличить его эффективность. В рамках Scrum такой анализ имеет смысл проводить не по отдельным историям пользователя, а по эпикам или темам.

Самый простой инструмент, который может применяться даже в устной форме. Его суть состоит в поиске коренных причин проблем (например, дефектов) и принятии многоуровневых контрмер. Для этого по отношению к проблеме задается пять раз вопрос «Почему?», чтобы проникнуть в ее суть (табл. 11.1).

Таблица 11.1.

Пять «почему»

Такие диаграммы являются уже более тяжеловесным инструментом по сравнению с пятью «почему». На них отображается множество проблем и их связи, но целью та же – выявление коренных причин. В качестве нотации можно посоветовать упрощенную, предложенную Хенриком Книбергом («Scrum и XP: заметки с передовой», Книберг Хенрик).

Еще одним инструментом для анализа проблем, но уже на уровне организации в целом, является диаграмма Исикавы. На ней также отображаются проблемы, но они заранее сгруппированы по нескольким областям, например:

• методология;

• требования;

• разработка;

• контроль качества.

Пример нотации для анализа причинно-следственной связи

Пример диаграммы Исикавы

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

Классическим применением является сравнение некоторых элементов системы по выбранному показателю. Например, мы хотим определить, насколько наши проекты хорошо тестируются. Для этого можно собрать простую статистику – количество дефектов в финальной версии продуктов в равных временных промежутках на одного разработчика – и построить по ним контрольную карту.

По ней видно, что проект № 9 имеет несистемные отклонения. Если количество дефектов больше, чем при стандартных отклонениях, то необходимо выработать меры, прежде всего процессные, для улучшения качества.

Контрольные карты бывают разных видов, например классические контрольные карты Шухарта ((Госстандарт России, 1999) и (Уилер и др., 2009)). Различия касаются формул и значений для выбора среднего значения и контрольных пределов. В контрольных картах Шухарта для определения предела используется не стандартное отклонение, а размах. Существует также набор правил для трактовки контрольных карт, например правила Western Electric и правила Нельсона.