Борис Вольфсон - Гибкое управление проектами и продуктами

Таблица 11.1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контрольная карта по дефектам

Контрольная карта по дефектам в разрезе проектов

Этот инструмент позволяет выявить модули, которые содержат определенный процент дефектов. Обычно получается соотношение, близкое к 20/80: 20 % модулей содержат 80 % дефектов.

Именно на эти модули стоит обратить внимание:

• покрыть их дополнительно тестами;

• провести дополнительные инспекции кода.

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

Диаграмма Парето

Модули, в которые часто вносятся изменения, экономически выгодно сделать более гибкими:

• сделать более гибкую и настраиваемую архитектуру;

• активно использовать шаблоны проектирования для дополнительной гибкости.

Итоги

Начнем с основ и для этого возьмем машину времени и переместимся в 1970 год: доктор Уинстон Ройс пишет свою статью «Управление разработкой больших программных систем» (Managing the development of large software systems), которая и положила начало водопадной модели разработки ПО. Самое интересное, что он в своей статье описывает эту модель как антипаттерн.

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

1. Подробная проработка архитектуры программы до начала разработки (включая предварительную архитектуру).

2. Максимально подробная документация на каждом этапе.

3. Симуляция всего проекта в уменьшенном виде (фактически прототипирование).

4. Планирование, контроль и мониторинг тестирования.

5. Вовлечение заказчика.

Водопадная модель разработки ПО

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

В феврале 2001 года в местечке под названием Сноуберд в штате Юта собрались 17 специалистов (консультантов и практиков), чтобы обсудить легковесные методики разработки. В результате родился документ «Манифест гибких методологий разработки» (Agile Manifesto). Позволю себе привести список авторов манифеста и краткую информацию о них.

Кент Бек– создатель разработки через тестирование и экстремального программирования. Автор нескольких книг на эти темы и соавтор JUnit.

Майк Бидл– основатель и генеральный директор e-Architects Inc., консалтинговой компании, которая специализируется на разработке распределенного ПО. Он также является соавтором книги Scrum, Agile Software Developmen t, написанной совместно с Кеном Швабером.

Усовершенствованная водопадная модель разработки ПО

Эйри ван Беннекум– участвовал в разработке методологии DSDM с 1997 года. До этого активно работал над быстрой разработкой (Rapid Application Development).

Алистер Кокберн– известен исследованиями проектных команд и участием в разработке семейства методологий Crystal.

Уорд Каннингем– основатель Cunningham & Cunningham, Inc. Он также широко известен своим огромным вкладом в развитие объектно-ориентированного программирования, экстремального программирования и в концепцию вики.