Управление проектами - это философия управления, а не инструмент или техника
Управление проектамиГлоссарийФорумКонтакты

Конструктивный подход к вычислению показателей в проектах с гибкой методологией разработки

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

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

Из-за чрезвычайной распространенности гибкого управления проектами имеется возрастающая потребность в хорошо структурированном, релевантном и всеобъемлющем наборе показателей, которые помогали бы руководителям проектов, высшему руководству и спонсорам проекта не просто следить за состоянием гибких проектов, но и постепенно совершенствовать гибкий процесс.

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

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

Решение лежит в изучении Agile Manifesto и выработке показателей, основанных на принципах гибкого управления проектами.

Показатель

Описание показателя

Тип показателя

Принцип Agile

Фактор объема работ спринта

Фактор объема работ спринта = (Элементы в текущем спринте/общий список функций) +[ ∑ (запросы на изменения из предыдущих спринтов)].

Фактор объема работ спринта должен быть одинаково распределен между всеми спринтами.

Показатель проекта

Рабочее ПО вместо сложной документации.

Фактор сложности спринта

Фактор сложности спринта = ƒ (модули, с которыми он взаимодействует с помощью # точек подключения с другими модулями).

Показатель проекта

Рабочее ПО вместо сложной документации.

Объем работ по запросу на изменение

Объем работ по запросу на изменение = ƒ (добавление новых функций + изменение ранее определенных функций – обдуманное исключение функций).

Показатель проекта

Сотрудничество с клиентом вместо обсуждения условий контракта.

Исходная точка ожиданий клиента

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

Показатель проекта

Сотрудничество с клиентом вместо обсуждения условий контракта.

Влияние на бюджет

Влияние на бюджет = ƒ (Объем работ по запросу на изменение, Исходная точка ожиданий клиента).

Показатель проекта

Сотрудничество с клиентом вместо обсуждения условий контракта.

Фактор повторного использования X

Определение повторно используемых компонентов в системе = # компонентов, добавленных в библиотеку.

Рекомендация общего порядка такова, что больше -- значит, лучше. Этот показатель должен выявлять более пригодные для повторного использования компоненты в системе.

Показатель продукта

Реакция на изменение вместо следования плану.

Фактор повторного использования Y

Повторное использование повторно используемых компонентов в системе = # число повторно использованных компонентов из библиотеки.

Рекомендация общего порядка такова, что больше -- значит, лучше. Хорошая системная архитектура старается больше использовать повторно используемые компоненты, что дает продукт более высокого качества.

Показатель продукта

Реакция на изменение вместо следования плану.

Время личного контакта

Время личного контакта = ƒ (время, которое каждый разработчик тратит на общение с бизнесменом и с другими разработчиками, от которых зависит его работа).

Показатель процесса

Люди и взаимодействия вместо процессов и инструментов.

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

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

Данные показатели agile были использованы в более чем двух дюжинах проектов в различных организациях с высокой степенью успеха, измеренного по показателям удовлетворения запросов заказчиков, улучшения качества продукта и совершенствования процессов в организации. Проекты, чьи проектные группы включали в себя от 5-7 членов до 10-15 членов, использовали методику Agile Scrum. Полные временные графики проектов менялись от 3-4 месячного графика получения предоставляемых результатов до проектов, длившихся более 12-14 месяцев.

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


Newer news items:
Older news items:

 

Предложения

Copyright ©2014, PMToday.ru. При копировании материалов наличие прямой индексируемой ссылки на сайт обязательно.