[ главная ]   [ рейтинг статей ]   [ справочник радиолюбителя ]   [ новости мира ИТ ]



Ответов: 0
25-02-12 07:01







   Web - программирование
PHP


ASP






XML



CSS

SSI





   Программирование под ОС











   Web - технологии








   Базы Данных









   Графика






Данные




IT - Обзор / Разное /

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

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

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

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

В чём смысл любого проекта?

Я всего лишь догадываюсь, но думаю, что смысл большинства программных проектов - это рабочий продукт, а также максимум функциональных возможностей за каждый доллар инвестиций. Я называю это утверждение Рабочие протестированные возможности (РПВ), и фактически, это может быть количественно измерено.

Обратите внимание на следующие определения РПВ:

  1. Желаемая программа разбита на именованные возможности (требования, истории), необходимые как части для выпуска конечного продукта.
  2. Для каждой именованной функциональности есть один или более автоматизированных приёмочных тестов, и их работоспособность укажет на то, что функциональность реализована.
  3. Метрика РПВ, в любой момент времени, показывает, сколько функциональных возможностей прошли приёмочные тесты.

Сколько определённых заказчиком возможностей известно посредством независимо описанных тестов, которые работают?
Вот метрика, с которой можно иметь дело.

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

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

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

  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




Комментарии

 Ваш комментарий к данному материалу будет интересен нам и нашим читателям!



Последние статьи: IT - Обзор / Разное /

Microsoft открывает язык программирования F#
29-12-2010   

Корпорация Microsoft накануне опубликовала полные исходные коды функционального языка программирования F#. Компания сделала вторую версию языка F# полностью открытой, включая исходники компиляторов и ключевых библиотек по условиям лицензии Apache 2.0.... подробнее

Кол. просмотров: общее - 3930 сегодня - 1

Автомобильный портативный компьютер NaviSurfer II
21-12-2010   

VIC Ltd представила портативны компьютер для автомобиля NaviSurfer II. Отличительная особенность новинки заключается в том, что она устанавливается на место однодиновой автомагнитолы.... подробнее

Кол. просмотров: общее - 2975 сегодня - 2

Структура COM и EXE файлов
12-05-2010   

Наверное всем известны файлы с расширением COM. Главным COM файлом на ПК является вездесущий command.com (командный файл DOS) . Что же такое COM файл, как он работает и запускается... подробнее

Кол. просмотров: общее - 3830 сегодня - 1

шифрование вируса
12-05-2010   

Здравствуйте, дорогие мои VX-еры и AV-еры (если прочитаете...) В этой маленькой, но очень познавательной статье хочу рассказать вам как можно скрыть свое вирусное детище от супер-мощных-современных антивирусных программ... подробнее

Кол. просмотров: общее - 3285 сегодня - 2

Защита от трассировки и антивирусов
12-05-2010   

На практике обман антивируса не такое уж и сложное дело. Я написал простой вирус-пробник и на нем испытывал различные уловки для разных антивирусов. И вот что у меня получилось... подробнее

Кол. просмотров: общее - 3036 сегодня - 2



  WWW.COMPROG.RU - 2009-2012 | Designed and Powered by Zaipov Renat | Projects