Как я могу отслеживать производительность программирования на ежедневной основе? [закрыто]

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

Есть простой ответ: вы не можете. И более того, вы не должны.

Вы хотите измерить собственную производительность, но вы можете обобщить: как вы можете измерить производительность программистов? Прежде всего, вы должны определить, что вы подразумеваете под «производительностью»: количество произведенного кода? Количество выполненного проекта (или спецификации)? Количество проблем исправлено? Качество производимого кода? (Да, качество - это счетчик производительности, вы можете создать много плохого кода или мало хорошего кода, что было более продуктивным?). Все эти значения вряд ли можно сопоставить с ежедневной базой, и любая попытка отследить ежедневную производительность опасна для проекта, для компании и для программиста.

Мой совет - четко определить, что вы подразумеваете под «производительностью», затем определить единицу измерения и применять ее на еженедельной и ежемесячной основе.

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

Оба предложения, приведенные ниже, могут быть примерно приняты для ваших нужд, но в обоих случаях вам нужно заранее сделать оценки, а затем проанализировать их ad hoc (и, честно говоря, я не уверен, что существует другой эффективный способ измерения, я согласен с TheLQ эти строки кода за период времени вообще не могут использоваться).

Методологии гибкой разработки
Хотя я не уверен, насколько эффективно его можно применить к одному сценарию разработчика, некоторые принципы, используемые в Agile, могут оказаться полезными для достижения ваших целей. Agile работает в циклах, в которых разработчики стремятся реализовать истории (задачи), которые оцениваются (в баллах) на основе сложности реализации в начале цикла разработки, а затем анализируются в конце каждого цикла. Это позволяет определить скорость, т. Е. Количество баллов, которые разработчик или команда могут выполнить за один цикл разработки.

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

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

Согласитесь с Лоренцо, определите производительность.

Я также сделал это: 1. Разбейте все задачи (разбивка на высоком или низком уровне). 2. Оцените рабочее время для каждой задачи (не забудьте установить буфер задержки для каждой задачи). 3. Завершите задачу. 4. Просмотрите каждое задание и посмотрите, достаточно ли вы продуктивны или нет.

Вот значимый и точный показатель производительности, который включает в себя создание нескольких моментальных снимков планирования на основе фактических данных :

Как только вы соберете статистику за несколько дней, запустите симуляцию Монте-Карло и посмотрите на график, который должен выглядеть следующим образом:

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

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

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

Подсчет строк кода является несовершенным измерением, поскольку он не дает представления о качестве кода, но может использоваться для определения общей производительности. В зависимости от того, какой язык вы используете, существуют разные инструменты, которые будут подсчитывать строки кода для вас, но я попросил, чтобы BitBucket, Git Repository, добавил статистику, связанную с производительностью.

https://bitbucket.org/site/master/issue/4307/feature-request-contributor-statistics

Измерьте время, которое требуется от того, что вы садитесь за компьютер утром, пока не будете выполнять какие-либо не связанные с работой действия, такие как 9gag, facebook, reddit и т. Д. Ваша производительность в этот день пропорциональна этому числу.

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

Единственное, что вы действительно можете сделать, это записать свое время, когда вы занимаетесь различными видами деятельности в течение дня. Time Boxing - это техника, используемая для различных целей, но она подойдет для этого, чтобы регистрировать вашу активность в течение дня. Потратьте 15 минут на таймере, просто выполняя какое-то задание. Если задача - это то, над чем вы должны работать, ваше время было продуктивным. Если вы обнаружили, что редактировали свой блог, читали газету или мечтали об этой милой девушке в бухгалтерии, то ваше время, вероятно, было непродуктивным. Сложите свои минуты в конце дня, и вы почувствуете, насколько вы продуктивны ...

Но есть подвох! Что вы делаете с этими другими минутами ... знаете, вы делаете 5-минутный перерыв, идете на ланч, заставляете вашего босса перебивать вас, чтобы рассказать вам о той большой рыбе, которую он не поймал во время своей последней поездки на рыбалку? Зарегистрируйте все это тоже. Время, потраченное на перерыв, не теряется, если оно способствует вашему психическому здоровью и самочувствию ... только если вы не делаете 5-минутный перерыв каждые 10-15 минут !! Что касается остального, перерывы в работе, связанные с другими вопросами, связанными с работой ... все это можно отследить.

Конечно, вы можете оказаться одержимыми подобными вещами, и Бог поможет вам, если босс - один из тех людей, которые видят в вас время и используют его, чтобы оправдать причины нагружать больше работы или критиковать ваши усилия. Видите ли, проблема одержимости в течение продуктивного рабочего дня заключается в том, что вы можете работать целый день, и все равно в конечном итоге вы не получите ничего актуального. В некоторые дни вы можете писать код, как будто масло растекается прямо из вашего мозга, и на тот бутерброд, который вы называете своим экраном ... в то время как в другие дни у вас может возникнуть серьезный психический блок, когда вы пытаетесь 357 разных способов сделать то же самое вещь, только чтобы посмотреть, как это не получится Многие скажут, что постоянные «сбои» могут быть непродуктивными, и это само по себе не поможет, независимо от того, сколько времени вы тратите и регистрируете свои часы в течение дня.

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