Як я можу щодня відстежувати продуктивність програмування? [зачинено]

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

Є проста відповідь: не можна. І більше того, ви не повинні.

Ви хочете виміряти власну продуктивність, але можете узагальнити: як можна виміряти продуктивність програмістів? Перш за все, ви повинні визначити, що ви маєте на увазі під "продуктивністю": кількість виробленого коду? Обсяг реалізованої конструкції (або специфікації)? Кількість виправлених питань? Якість виробленого коду? (Так, якість - це лічильник продуктивності. Ви можете створити багато поганого коду або кілька хороших кодів. Що було більш продуктивним?). Усі ці значення навряд чи можна відобразити на щоденній основі, і будь-яка спроба відстежувати щоденну продуктивність небезпечна для проекту, для компанії та для програміста.

Моя порада - чітко визначити, що ви маєте на увазі як "продуктивність праці", а потім визначити одиницю вимірювання та застосовувати її щотижня та щомісяця.

Я б сказав, що найкращий спосіб вимірювати свою продуктивність - це щодня встановлювати мету для того, що ви хочете зробити в цей день, і якщо ви виконаєте це, вважайте це продуктивним. Це досить суб'єктивний захід, але, швидше за все, вам здасться набагато кориснішим, ніж об'єктивним.

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

Методики гнучкої розробки
Хоча я не впевнений, наскільки ефективно його можна застосувати до одного сценарію розробника, деякі принципи, застосовані в Agile, можуть виявитись корисними в тому, що ви прагнете досягти. Agile працює в циклах, в яких розробник (и) мають на меті реалізувати розповіді (завдання), які оцінюються (у балах) на основі складності реалізації на початку циклу розробки, а потім аналізуються в кінці кожного циклу. Це дозволяє визначити швидкість, тобто кількість балів, яку розробник або команда може виконати протягом одного циклу розробки.

Якщо спосіб роботи дозволяє прийняти деякі принципи та організувати свою роботу за циклами, ви можете використовувати показник швидкості на цикл розвитку для відстеження ефективності. Зауважте, що цикли зазвичай тривають 2-3 тижні, однак ви повинні мати можливість скоротити їх, використовуючи лише це для себе. Все зводиться до того, якщо ви можете прийняти таку методологію у своєму оточенні.

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

Погодьтеся з Лоренцо, визначте продуктивність.

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

Ось вагомий і точний показник продуктивності, який передбачає отримання декількох знімків, заснованих на доказах :

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

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

Найголовніше, якщо ви були продуктом у цей день, вірогідність дати доставки у будь-яку дату повинна збільшитися з моменту останнього запуску моделювання до цього дня роботи. Якщо вона зменшується, то ви були менш продуктивними в той день.

Звичайно, точність EBS збільшується з часом і досвідом, тому це може бути ще однією причиною зміни значення ймовірності дати судна. Ось чому ви хочете почати це робити принаймні після кількох днів роботи з вибіркою. Навіть навіть без цього, якщо ви в той чи інший день були значно продуктивнішими, ймовірність повинна помітно зрости.

Підрахунок рядків коду є недосконалим вимірюванням, оскільки він не дає розуміння якості коду, але може бути використаний для визначення загальної продуктивності. Залежно від того, якою мовою ви користуєтесь, існують різні інструменти, які будуть рахувати рядки коду для вас, але я просив, щоб BitBucket, Git Repository, додав статистику щодо продуктивності.

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

Виміряйте час, який знадобиться, коли ви сідаєте за комп'ютер вранці, поки ви не займетесь будь-якою неробочою діяльністю, наприклад, 9гаг, facebook, reddit тощо. Ваша продуктивність цього дня пропорційна цій кількості.

Припустимо на мить, що продуктивність керує вашим часом таким чином, що ви використовуєте весь свій робочий час для роботи над виконанням своїх завдань, і що все, що сприяє витраченому часу - тобто: час, витрачений на невиконання ваших завдань, - це не- продуктивні.

Про єдине, що ви дійсно можете зробити - це записувати час, займаючись різними видами діяльності протягом дня. Бокс у часі - це техніка, яка використовується для різних цілей, але вона буде доречна для того, щоб зареєструвати свою діяльність протягом дня. Проведіть 15 хвилин на таймері, просто виконуючи якесь завдання. Якщо завдання - це те, над чим ви повинні працювати, ваш час був продуктивним. Якщо ви виявили, що ви редагуєте свій блог, читаєте газету чи мріяли про цю приємну дівчину в бухгалтерії, то ваш час, мабуть, був малопродуктивним. В кінці дня складіть свої хвилини, і ви відчуєте, наскільки ви продуктивні ...

Але є улов! Що ви робите в ті інші хвилини ... ви знаєте, роблячи 5-хвилинну перерву, йдучи на обід, змусивши вашого начальника перешкодити вам розповісти про ту велику рибу, яку він не спіймав у своїй останній риболовлі? Увійдіть і до всього цього. Час, витрачений на перерву, не даремно, якщо це сприяє вашому психічному здоров’ю та самопочуттю ... до тих пір, поки ви не робите 5-хвилинної перерви кожні 10-15 хвилин !! Щодо решти, перебоїв, вирішення інших питань, пов’язаних з роботою .. все це можна відстежити.

Звичайно, ти можеш опинитися нав’язливим щодо подібних речей, і бог допоможе тобі, якщо бос є одним із тих людей, хто бачить тебе боксерством і використовує це для обгрунтування причин, щоб накопичити більше роботи або критикувати свої зусилля. Розумієте, проблема з нав'язливістю в продуктивні години полягає в тому, що ви можете працювати цілий день, і все одно в результаті нічого не робите з фактичної актуальності. Деякі дні ви можете писати код, як би тоне масло прямо з вашого мозку, і на той сендвіч, який ви називаєте на екрані ... а в інші дні ви можете мати серйозний ментальний блок, намагаючись 357 різних способів зробити те саме річ, тільки спостерігати за тим, як це не виходить. Багато хто може сказати, що постійні «збої» можуть бути малопродуктивними, і це саме по собі не допоможе, незалежно від того, скільки часу ви обробляєте і записуєте свої години протягом дня.

Інший спосіб поглянути на це - просто поставити собі ряд цілей, виконати протягом дня і тижня, а потім працювати над їх виконанням. Якщо ви насправді досягаєте своїх цілей, ви можете стверджувати, що ви були продуктивними, і якщо ви не досягаєте своїх цілей, вам може знадобитися зрозуміти, чому ви їх не відповідали, і вирішити, чи були ви чи не були продуктивними виходячи з фактичних причин відсутності ваших цілей. Зрештою, якщо ви доставляєте робочий код, коли це потрібно, і якщо ви зможете пройти тести і виконати завдання, то ви зробили продуктивність. Вимірювання будуть корисними лише за наявності законних причин для їх подальшого статистичного аналізу.