dev.net.ua

Українська Спільнота Розробникiв
 
Ласкаво просимо до dev.net.ua Увійти | Приєднатися | Допомога | Увійти Live ID
в Пошук

Дмитрий Лапшин

О метриках и "пилотировании" проекта

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

Можем ли мы представить себе в такой ситуации, скажем, летчика? Вряд ли - наоборот, в условиях нулевой видимости летчик только на приборы и полагается. Впрочем, и при отличной видимости на современном самолете без приборов особо не полетаешь. В практике же управления проектами, принцип "на глазок" зачастую считается более чем приемлимым. Конечно, данные Chaos Report в большинстве случаев нельзя напрямую сравнивать с количеством аварий и катастроф - цена ошибки в том и другом случае очень разная, ну разве что мы разрабатываем ПО для марсохода или атомной станции. Но, тем не менее, теперь есть все возможности заметно увеличить вероятность успешного завершения проекта за разумную цену.

Вы уже наверняка догадались, что речь идет о TFS, но что же собственно мы покупаем? Как именно TFS поможет нам "пилотировать" проект более уверенно? Ответ прост - именно благодаря предоставляемому инструментарию для сбора и анализа большого числа объективных показателей. Причем достаточно много измерений производится (при должной настройке) без участия человека. О том, как это работает, рассказывают:

Sam Guckenheimer: Team Foundation: Using Metrics to Manage and Troubleshoot Your Projects

Tom Patton: MSDN Webcast: Using Metrics from Visual Studio 2005 Team Foundation Server to Manage and Troubleshoot Your Projects (Level 200)

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

Опубліковані Wednesday, June 27, 2007 1:57 PM від DmytroL

Коментарі

 

denis pasechnik сказав:

Хочется отметить, что

В практике управления проектами, принцип "на глазок" никогда не считался  приемлимым.

Управление проектами включает в себя четко опредленную систему - базовые процессы, наборы успешных практик от которых проектный менеджер должен отталкиваться для оценки длительности выполнения работ после того как оценка снизу вверх получена, рекомендуемые к использованию инструменты (MS Excell, MS Project, MS Project Server), принципы ролевого деление и т.д.

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

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

Специалисты компании Microsoft всегда и всюду повторяют, что все наиболее успешные практики нашли свое отображение в методологиях предлагаемых компанием Microsoft - MSF (Agile и CMMI) - о чем собственно говоря и пишет Sam Guckenheimer в своей книге Software Engineering with Visual Studio Team System.

Мы согласно MSF или выбранной методологии делаем все то, что предписано в рамках наших ролевых инструкций , согласно им же мы пользуемся всей полнотой и мощью функциональных возможностей TFS и VSTS, которые при правильном использовании дают возможность нам отслеживать текущее состояние проекта,  чтобы вовремя осуществить перепланирование и оценить риски. Причем согласно методологии "команда равных" активно принимает участие в во всех фазах и итеррациях при планирование (отдельные роли имеют в активностях свои планы), думаю что это никак нельзя называть "субъективными оценками подчиненных", кстати сказать оценка bottom-up является наиболее успешной.

Повторюсь - Успешность определяется качественным планированием и применяемой методологией.

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

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

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

Возможно что это, как раз то, что хотел сказать автор а я извините предрался к словам :)

June 30, 2007 4:56 AM
 

DmytroL сказав:

Метрики, разумеется, должны подкрепляться правильной методологией и планированием (в том числе, допустимых порогов этих самых метрик). Этого автор ни в коем случае не отрицает :)

Дело в другом. Пользуясь твоей же метафорой, для успешного лечения больного градусник все же должен показывать правильную температуру. А вот без объективных метрик на это не всегда можно расчитывать - сам видел случай, когда члены команды намеренно дезинформировали менеджера проекта касательно прогресса выполнения своих задач. Ну это экстрим, но и в более умеренных примерах если метрики не собираются легко и с максимальной помощью машины - они, как правило, не собираются вообще никак. А раз нет метрик - то и решения принимаются "на глазок". План-то есть, но как узнать, насколько мы его придерживаемся и каковы тенденции?

P.S. А еще хотелось бы посмотреть в действии на "команду равных" - у нас в компании MSF Team Model пока что поддержки не нашла (в отличие от MSF Process Model, которую я адаптировал под нашу специфику).

July 2, 2007 1:01 PM
Анонімні коментарі деактивовані. Увійдіть або Зареєструйтесь щоб мати доступ до ресурсів Спільноти.

Синдикація

Новини

View Dmytro Lapshyn's profile on LinkedIn

www.developers.org.ua