Метрика, ведущая к гибкости

Могут ли метрики вести к гибкости?

Камилла Белл, в дискуссионном листе по гибкому управлению проектом (Agile Project Management), спрашивала о метриках для формирования гибкости. В последующей дискуссии я предложил следующее:

Как должна выглядеть кривая РПВ?

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

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

1. Работающие подразумевает возможности, выпускаемые в едином интегрированном продукте.
2. Протестированные означает, что функциональные возможности продолжают удовлетворять тестам, предоставленным разработчиками требований (заказчики в рамках XP).
3. Под функциональными возможностями подразумеваются куски данных заказчиком требований. Это не технические возможности, такие как "Установить базу данных" или "Запустить веб сервер".

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

Но наша цель здесь предоставить метрику, отображение которой на графике заставит команду становиться гибкими. Команда, производящая рабочие протестированные возможности прямолинейно с первого дня по день N, должна стать гибкой, чтобы добиться этого. Они не смогут строить громоздкие проекты заранее, а если всё-таки будут, то не выпустят ни одной функциональности. Члены команды не смогут пропустить приёмочное тестирование. Без этого функциональность не будет протестированной. Они не смогут пропустить рефакторинг, т.к. их показатели упадут из-за нелинейно возрастающей сложности структуры проекта. И так далее.

Тем не менее, игра в РПВ возможна, но всё же легче будет стать гибкими. Мысль в том, что только очень недобрая команда будет отвечать на требование явным обманом. И я не думаю, что здесь найдётся много плохих команд. Причина работоспособности XP, Scrum и Crystal Clear в том, что они требуют регулярный выпуск реального продукта. Вот это и есть РПВ.

На что кривая РПВ не должна быть похожа?

Кривая РПВ не является правильной, если она с самого начала на протяжении нескольких месяцев полога. РПВ метрика хороша, только когда функциональные возможности начинают коваться сразу же. Проекты, в которых много дизайна на перёд (BDUF), и проекты, фокусирующиеся на преждевременном развёртывании инфраструктуры, в нашем контексте не применимы.

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

РПВ неверна, если ни началась с первых дней и не увеличивается последовательно всё время.

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

Гибкий проект: своевременная функциональность.

Гибкий проект действительно фокусируется на выпуске завершённых функциональных возможностей с самого начала. Предполагая, что функциональность тестируется по мере продвижения, метрика РПВ для гибкого проекта может выглядеть так:

Это очень простая метрика, часто её называют огненной диаграммой. Реально живая функциональность реализуется, тестируется, выпускается последовательно с самого начала до победного конца. Требуйте этого от любого проекта, и разработчики должны будут стать гибкими в ответ на это требование.

Водопад: функциональность попозже.

Проекты в стиле водопада своевременно тоже что-то "выпускают", но только не РПВ. Они выдают документы анализа, документы требований, документы дизайна, и т.п., на протяжении долгого времени до того как начнут выпускать саму функциональность. По теории, когда они начинают выпускать, это должна быть правильная функциональность, к тому же, правильно сделанная, так как у них есть правильные требования и правильный дизайн. Затем они кодируют, что может быть расценено как выпущенная программа, но не рабочие протестированные возможности, так как функциональность не была протестирована, и часто нерабочая вовсе. В конце концов, они тестируют и выявляют, что прогресс РПВ далеко не тот, которого они ожидали. Это выглядит так:

Посмотрите на всё это пушистое содержимое. Здесь голубым представлены размытые ненужные издержки в виде требований, проектирования и тестирования. Мы можем разбить это на интервалы, часто так и делается, но мы не знаем, какая часть работы была сделана и насколько качественно.

Также, кажущийся рост функциональности сам по себе может быть размытым, если в проекте планируется пост-тестирование. Мы думаем, что набор функциональности готов, но есть некоторое размытое количество постоянно генерируемых дефектов. После круга тестирования, самого по себе не ясно описанного, мы получаем солидный список дефектов, и многое переделываем. Только в конце работы мы узнаем, как выглядит наша кривая РПВ.

Итог таков, что негибкий проект просто не сможет произвести ясную и последовательную РПВ метрику с первого дня и до самого конца. Результат этой кривой негибкого проекта будет выглядеть ужасающе. Каждый должен видеть кривую и постарается быть в русле гибкости в ответ на показатель метрики. У компании не будет выбора, кроме как становиться более гибкими, показывая достойную РПВ.

Рон, вы становитесь несправедливым!

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

Да, как сказал судья Рой Бин, если вы хотите справедливости, вам следует поискать её где-нибудь в другом месте. Моя миссия здесь - отбросить процесс водопада назад. Но если быть полностью честным, это заслуженная судьба негибких процессов. Диаграмма водопада показывает графически, почему вещи, которые мы делаем в негибком стиле, трудно измеримы, и зачем измерять то, что нам реально не потребуется.

Метрика, которую я здесь назвал РПВ, рабочие протестированные возможности, может быть настолько точной, насколько мы этого захотим. Всё, что нам остаётся сделать, это определить наши истории возможностей в терминах конкретных и независимых приёмочных тестов, которые должны выполниться. Метрика РПВ очень сложна для игр с нею. Она показывает, только то, что происходит с проектом. Как пример, давайте посмотрим на кривую РПВ другого проекта:

Что же происходит здесь? В самом начале мы видим внезапное падение РПВ. Что это может означать? Мы не знаем, но это, по всей видимости, совсем не хорошо. Возможно, программисты внезапно внесли изменение, сломавшее несколько тестов. Мы ловим их на этом и поджариваем их пятки на огне. Хотя постойте, возможно, требования изменились, и тесты были изменены в ответ на новые требования, что привело к регрессу в программе. Что мы узнали, так это только то, что нам надо в чём-то разобраться. Первое что мы должны сделать - это спросить команду!

Затем, в ходе проекта, прогресс приостановился. Опять же, явная проблема. Но в чём же причина? Это может быть то, что команда не производит достаточный рефакторинг для поддержки прозрачного дизайна. И в связи с этим, они замедлились. Это может быть и по причине приостановки заказчиком определения требований или написания тестов. Опять же, мы не знаем. Необходимо спросить команду!

Как РПВ приводит к гибкости?

1. РПВ требует увеличения количества функциональных возможностей с первых дней. Поэтому команда должна сосредоточиться на функциональности, а не на проектировании или инфраструктуре.
2. РПВ требует постоянного увеличения количества функциональных возможностей. Поэтому команда должна интегрировать рано и часто.
3. РПВ требует тестирования функциональности независимыми тестами. Так команда получает всесторонний контакт с заказчиком.
4. РПВ требует, чтобы тесты продолжали выполняться. Таким образом, тесты должны быть автоматизированы.
5. РПВ требует, чтобы кривая росла равномерно. Поэтому дизайн должен оставаться прозрачным.
6. Для РПВ, чем больше функциональных возможностей, тем лучше. Так команда изучит, как выпускать функциональность в виде непрерывного, постоянно улучшаемого потока. Им придётся внедрить гибкость, чтобы всё это работало.

Гибкие методы Scrum и Crystal Clear реализуют РПВ. "Всё" чего они просят, это чтобы команда выпускала готовые к работе приложения каждую итерацию. Всё остальное приложится. XP даёт чуть больше: вы получаете бесплатный список вещей в помощь.

РПВ требует гибкости

Если организация решит измерять прогресс проекта с помощью РПВ, требуя постоянного выпуска реальной функциональности, проверенной на работоспособность с использованием независимых приёмочных тестов, то метрика покажет менеджерам почти всё, что необходимо для знания происходящего. Более важным является то, что этой метрикой тяжело играть, метрика приведёт команду к управлению собой, чтобы сделать то, что менеджерам реально нужно.

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

Copyright © 1999-2004, Ronald E Jeffries