Как эффективно измерять рабочее время разработчика? [закрытый]

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

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

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

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

какой-то active-window-title-anaylzer может помочь (вы можете получить имя решения оттуда в случае Visual Studio), но у меня нет опыта с такой идеей.

Если у вас есть опыт работы с программистами/дизайнерами, пожалуйста, поделитесь со мной. Спасибо

9
measurement

11 ответов

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

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

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

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

да дамы и господа я говорю о Scrum. Выбросьте любое понятие о часовых вкладках ваших разработчиков из окна (они будут любить вас за это). И вместо этого ввести управление Scrum в сценарий.

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

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

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

9

существуют различные программные средства отслеживания времени, как вы, вероятно, уже видели из поиска google. Но, честно говоря, вы просите Святой Грааль отслеживания времени. Например, считаете ли вы, что разработчик смотрит на свой код и думает как время разработки? Она может глядеть на экран в течение 1 часа и только на 10 минут. В данном случае, похоже, они не работают, когда на самом деле они работали в течение 1 часа и 10 минут. Я не хочу сказать, о чем ты просишь. это не то, что нужно, просто кажется одной из тех проблем, у которой нет идеального решения.

удачи.

3

Я думаю, что вы задаете неправильный вопрос и направляетесь к скользкому склону. В разработке так много всего, что не имеет ничего общего с фактическим кодированием.

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

1

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

1

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

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

1

Если вы пытаетесь измерить время, потраченное на отвлечения и помехи и другую задачу, не было бы в ваших интересах разработчиков, чтобы дать вам эту информацию охотно?
Вы где-то сказали, что реализуете scrum.

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

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

Как Дин J подразумевается, что вы все равно должны доверять разработчикам.

1

Это зависит от вашей IDE - если вы используете Eclipse, то я рекомендую использовать Mylyn плагин. Вы можете измерить время, затраченное на каждую задачу. Задачи могут быть извлечены из всех известных репозиториев задач, т. е. Tuleap. подробности здесь

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

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

1

попробовать DotProject или XPlanner

0

активный анализатор окон не даст вам надежных результатов, потому что ваши разработчики будут переключаться между программами (Outlook, File Explorer, version control, internet browser и т. д.). Предлагаемый анализатор не будет регистрировать это время, хотя, скорее всего, это будет часть времени разработки, которое разработчик вкладывает в проект (Разработка программного обеспечения-это не просто кодирование в VS все время).

0

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

Как хорошо выразился Джоэл Спольски в блог о мастерстве программного обеспечения, разработка программного обеспечения " ...не является производственным процессом."

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

0

Я определенно не рекомендовал бы вам использовать любое программное обеспечение для измерения времени, где разработчик вынужден. Это массовое отвлечение внимания разработчиков.

вместо этого можно использовать следующие простые методы:

таблица: для небольших проектов или команды разработчиков

вероятно, нет ничего проще, чем создать и поделиться электронной таблицей онлайн, добавить в нее задачи проекта, назначить задачи разработчику, пусть разработчики оценивают часы для их задач, пусть они обновляют свой статус задачи (очень грубое значение между 0% и 100%), как они хотят, пусть они указывают время (часы), которое действительно потребовалось для выполнения задачи.

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

Google Drive таблица может быть ответом. Это очень простой и быстрый метод, который отвлекает разработчика(ов) минимально.

Scrum: для средних и больших проекты или команда разработчиков

задачи и информация Scrum записываются и хранятся на доске в офисе и/или может использоваться специальное приложение Scrum. Хорошее веб-приложение Scrum-это Ведущие Tracker что я рекомендовал бы для любого размера проекта или команды.

больше: http://en.wikipedia.org/wiki/Scrum_ (развитие)

в обоих случаях, владельцы продукта (клиенты или те, кто имеет дело с клиенты), руководители проектов и все разработчики могут лучше и быстрее:

  • общаться
  • оценка
  • видеть прогресс команды и всех лиц, вовлеченных
0