Как эффективно измерить часы работы разработчика? [закрытый]
Я обычно пишу код OO. Я подозреваю, что большинство из Вас, вероятно, делает, также. В том контексте для меня кажется очевидным, что вся бизнес-логика - включая SQL-запросы - принадлежит определений классов. Разделение логики, таким образом, что часть его находится в объектной модели и части, находится в базе данных, не лучше, чем помещение бизнес-логики в пользовательский интерфейс.
Много было сказано в более ранних ответах о преимуществах безопасности сохраненного procs. Они попадают в две широких категории:
1) Ограничивающий прямой доступ к данным. Это определенно важно в некоторых случаях и, когда Вы встречаетесь один, затем сохранил procs, в значительной степени Ваша единственная опция. По моему опыту, такие случаи являются исключением, а не правилом, как бы то ни было.
2) Внедрение SQL / параметризованные запросы. Это возражение является отвлекающим маневром. Встроенный SQL - даже динамично сгенерированный встроенный SQL - может быть так полностью параметризован, как любой сохранил proc, и это может быть сделано столь же легко на любом достойном современном языке. Нет никакого преимущества так или иначе здесь. ("Ленивые разработчики не могли бы обеспокоиться использованием параметров", не допустимое возражение. Если у Вас есть разработчики в Ваших командах, которые предпочитают просто связывать пользовательские данные в их SQL вместо того, чтобы использовать параметры, Вы сначала пытаетесь обучить их, то Вы увольняете их, если это не работает, точно так же, как Вы были бы с разработчиками, у которых есть любая другая плохая, очевидно вредная привычка.)
9 ответов
Хороший вопрос, и лучший способ измерить часы, потраченные на проект разработки, - это вообще не измерять затраченные часы.
Вы говорите, что есть желание регистрировать часы, но у меня есть сомнения. На самом деле, с точки зрения разработчиков, чрезмерное управление временем отвлекает большинство (возможно, ВСЕХ разработчиков на планете).
Я могу понять, почему время в ODesk так сильно измеряется. Для этого есть веская причина, потому что время проекта оплачивается клиентом ODesk авансом, а разработчик должен доказать ODesk отработанные часы. Оплата также гарантирована, и маловероятно, что поставщики oDesk и разработчики когда-либо встретятся в реальной жизни, так что доверия нет.
Поскольку маловероятно, что вы платите своим разработчикам авансом, и, скорее всего, у вас больше доверия, вам, возможно, нужно переключить свое внимание с неуклюжей и раздражающей стратегии управления на что-то более полезное.
Да, дамы и господа, я говорю о Scrum. Отбросьте любую идею о том, что ваши разработчики будут держать час в час вкладок (они будут любить вас за это). И вместо этого введите в сценарий Scrum Management.
Создайте несколько спринтов (этапов) для разработки продукта и, имея список итераций (пакетные результаты), постарайтесь сократить количество итераций до одного недельного периода. И вместо этого введите в сценарий Scrum Management.
Создайте несколько спринтов (этапов) для разработки продукта и, имея список итераций (пакетные результаты), постарайтесь сократить количество итераций до одного недельного периода. И вместо этого введите в сценарий Scrum Management.
Создайте несколько спринтов (этапов) для разработки продукта и, имея список итераций (пакетные результаты), постарайтесь сократить количество итераций до одного недельного периода. Create a product backlog, and make sure you're aware who exactly is working on what. Find someone on the team to act as a scrum master on your behalf, or to take on this responsibility yourself. Make sure you have daily feedback meetings, keep them short and focused, to identify any risks that might get in the way of deliverable s. Let the developers more or less drive the timing process, and get realistic estimates for tasks.
Read a book or 2 on scrum, and get others and team members involved in the learning curve. Tweak the base scrum methodology to best suit your particular style of management, and I assure you, you will have a very happy team.
Measure your time in man days, and try avoid getting on the back of a developer for hour by hour progress...
Если вы пытаетесь измерить время, потраченное на отвлекающие факторы, беспокойство и другие задачи, разве ваши разработчики не будут заинтересованы в добровольном предоставлении вам этой информации? ?
Вы где-то сказали, что внедряете scrum.
Если вам действительно нужно либо заняться этим в ежедневной схватке, сделав это частью ритуала, либо добавить очень короткую ежедневную встречу в конце дня. Пусть разработчики угадают, сколько дня было потрачено на отвлекающие факторы, беспокойство и другие задачи. Мне кажется, что это будет так же близко к «правильному», как и любой другой способ измерения, учитывая сопутствующие трудности.
Итак, вместо того, чтобы заставлять разработчиков записывать время, сделайте работу скраммастера, чтобы подвести итог. , и сделать это максимально безболезненным для разработчиков. Убедитесь, что разработчики тоже получат от этого что-то осязаемое, иначе это очень быстро попадет в список препятствий.
Как намекал Дин Дж., Вы в любом случае должны доверять разработчикам.
вам понадобится что-то вроде этой приборной панели для измерения времени выполнения задачи. Единственный способ узнать реальное время разработчика программного обеспечения - это потом его отслеживать. Таким образом, когда они переключают задачи, они, так сказать, останавливают часы. Я думаю, что сложнее всего было бы заставить разработчиков использовать его как меру того, как долго они работают над определенным проектом или даже над модулем кода и т. Д. Если вы затем сможете использовать эти показатели, чтобы уменьшить отвлекающие факторы и другое время отстой, вы могли бы как минимум иметь возможность получить приличную информацию о том, сколько времени они тратят на кодирование по сравнению с электронной почтой, в сравнении с разговорами с другими разработчиками и т.д.
Если вы пытаетесь измерить то, что разработчик имеет в качестве активного окна, вы должны исходить из доброй воли, потому что любой порядочный разработчик может прокрасться вокруг этого, если вы попытаетесь завинтить винты. их. Я провожу около трети своего «времени разработки» в Firefox, например, просматривая ссылки.
Может быть, попросить разработчиков просто вести журнал, чтобы вы знали, на что уходит их время? Хотя это не идеально, вы никогда не добьетесь большего.
There're various time tracking software tools as you have probably already seen from doing google searches. But in all honestly you are asking for the Holy Grail of time tracking. For example do you consider a developer staring at her code and thinking as development time? She might stare at the screen for 1 hour and only type for 10 minutes. In this case it looks like they don't work much when really they worked for 1 hour and 10 minutes. I don't mean to say what you asking for isn't a valid thing to want it just seems to be one of those problems that doesn't have a perfect solution.
Good luck.
An active window analyzer won't give you reliable results, because your developers will swap between programs (Outlook, File Explorer, version control, internet browser, etc.). Your proposed analyzer won't log that time, although it will very likely be part of the development time that the developer puts into the project (software development is not just coding in VS all the time).
Я думаю, вы задаете неправильный вопрос и катитесь по скользкой дорожке. В разработку уходит так много всего, что не имеет ничего общего с кодированием.
Я думаю, что лучшим решением, если вы зациклились на отслеживании чего-либо, является отслеживание времени, потраченного на действия, НЕ связанные с разработкой. Конечно, там тоже есть серая зона. Например, собрание для обсуждения требований пользователей, вероятно, следует засчитать в счет разработки, даже если кодирование не будет выполнено.
Пытаться измерить часы работы разработчика - неправильное понятие. Правильный вопрос - какова эффективность программиста? Это не может быть измерено временем написания кода, временем, проведенным за компьютером, и т. Д.
Как хорошо выразился Джоэл Спольски в блоге о создании программного обеспечения , разработка программного обеспечения «... не является производственным процессом».
Связанное, но несколько иное обсуждение появляется в этой статье SO. инвазивный инструмент измерения производительности программистов .