Управление проектами оценка качества и производительности [закрыто]

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

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

7 2
project-management scrum

7 ответов:

Вы можете измерить много вещей

  • Строки полученного кода.

  • Нажатия клавиш.

  • Выпитый кофе.

  • Мусор производится.

Однако, это просто численность-числа ради того, чтобы иметь числа.

Прежде чем измерять свою команду, выясните, как измеряют вас.

Узнайте, как измеряется ваша общая организация разработки.

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

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

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

4

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

Например,

  • измерьте строки кода, воздействие будет многословным кодом

Любая метрика, которую вы выберете, скорее всего, будет "разыграна" людьми, которых вы пытаетесь измерить.

2

Значение. Работайте с вашими клиентами (владельцами продуктов), чтобы найти способ измерить ценность в вашей организации и измерить эту ценность. Доставляйте его часто (ежедневно, еженедельно, ежемесячно), и вы будете в полном порядке.

1

Не могли бы вы привести мне какой-нибудь пример метрик, которые я мог бы использовать для измерения качества и производительности членов моей команды?

Несколько примеров метрик для гибкой команды для измерения производительности:

Точки истории / точки скорости: это относительно значительная единица, которая может быть использована для измерения сложности предстоящей работы.

Sprint Burndown : Это можно использовать для измерения прогресса в часах во время итерации или Спринт

Release Burndown : Это можно использовать для измерения прогресса в точках истории во время выпуска.

Несколько примеров метрик для гибкой команды для измерения качества:

Hudson CI : вы можете использовать инструмент непрерывной интеграции, который постоянно следит за базой кода для вас автоматически. Некоторые плагины для проверки качества, которые могут быть использованы могут быть:: Корбертура PMD CheckStyle

1

Выясните, почему ваша компания была заинтересована в принятии Scrum в первую очередь.

Если бы это было для получения более качественного кода, то вы могли бы сосредоточиться на таких вещах, как тестовое покрытие, количество ошибок и т. д. Мне нравится индекс дерьма .

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

Я стараюсь избегать измерения таких вещей, как производительность. Это очень легко, чтобы быть продуктивным без эффективной. Сосредоточьтесь на Цель . Большинство метрик в Kanban могут быть использованы наряду со Scrum и помогут здесь. Мне очень нравятся кумулятивные диаграммы потоков, потому что они показывают все виды обратных связей и ограничений в системе.

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

1

Производительность - это единственный важный показатель успеха: удалось ли моей команде выполнить то, что мы обещали, в указанные сроки и на высоком уровне качества (пройдя UAT)? Если нет, то почему?

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

Вот несколько хороших статей о скорость и как ее рассчитать:

Http://www.versionone.com/Agile101/velocity.asp

Http://michaellant.com/2010/07/23/calculating-the-velocity-of-your-agile-projects/

1

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

0