Jak mogę codziennie śledzić wydajność programowania? [Zamknięte]

Jak mogę sprawdzić, czy tworzę oprogramowanie bardziej lub mniej wydajne niż w poprzednich dniach?

Odpowiedź jest prosta: nie możesz. A ponadto nie powinieneś.

Chcesz zmierzyć swoją produktywność, ale możesz uogólnić: jak możesz zmierzyć produktywność programistów? Przede wszystkim musisz zdefiniować, co masz na myśli mówiąc o „produktywności”: ilość wyprodukowanego kodu? Kwota wdrożonego projektu (lub specyfikacji)? Liczba naprawionych problemów? Jakość wytworzonego kodu? (Tak, jakość jest licznikiem produktywności, możesz wyprodukować dużo złego kodu lub kilka dobrych kodów, co było bardziej produktywne?). Wszystkie te wartości nie mogą być zmapowane do codziennej bazy, a każda próba śledzenia dziennej produktywności jest niebezpieczna dla projektu, dla firmy i dla programisty.

Radzę jasno zdefiniować, co masz na myśli jako „produktywność”, a następnie zdefiniować jednostkę miary i zastosować ją co tydzień i co miesiąc.

Powiedziałbym, że najlepszym sposobem zmierzenia produktywności jest wyznaczenie każdego dnia celu, co chcesz zrobić tego dnia, a jeśli go zrealizujesz, uważaj go za produktywny. Jest to dość subiektywna miara, ale najprawdopodobniej okaże się znacznie bardziej satysfakcjonująca niż obiektywna.

Obie poniższe sugestie można z grubsza dostosować do swoich potrzeb, ale w obu przypadkach musisz dokonać szacunków z wyprzedzeniem, a następnie przeanalizować je ad hoc (i szczerze mówiąc, nie jestem pewien, czy istnieje inny skuteczny sposób na zmierzenie tego, zgadzam się z TheLQ, że wiersze kodu w danym okresie nie są w ogóle użyteczne).

Metodologie zwinnego programowania
Chociaż nie jestem pewien, jak skutecznie można go zastosować do pojedynczego scenariusza programisty, niektóre zasady zastosowane w zwinnym mogą okazać się przydatne w tym, co chcesz osiągnąć. Zwinne prace w cyklach, w których deweloperzy dążą do wdrażania opowieści (zadań), które są oceniane (w punktach) na podstawie złożoności implementacji na początku cyklu programowania, a następnie analizowane na końcu każdego cyklu. Pozwala to określić prędkość, tj. Liczbę punktów, które deweloper lub zespół może ukończyć w jednym cyklu rozwojowym.

Jeśli sposób, w jaki pracujesz, pozwala ci przyjąć niektóre zasady i organizować pracę w cyklach, możesz użyć metryki prędkości na cykl rozwojowy do śledzenia swojej wydajności. Pamiętaj, że cykle trwają zwykle 2-3 tygodnie, jednak powinieneś być w stanie je skrócić, używając go tylko dla siebie. Wszystko sprowadza się do tego, czy możesz zastosować taką metodologię w swoim środowisku.

Planowanie oparte na dowodach
Mimo, że ma ono przede wszystkim na celu poprawę szacunków, powinieneś być w stanie skutecznie je wykorzystywać do śledzenia malejących trendów w wydajności.

Zgadzam się z Lorenzo, określ wydajność.

Zrobiłem to również: 1. Rozbij wszystkie zadania (rozbicie wysokiego lub niskiego poziomu). 2. Oszacuj godziny pracy dla każdego zadania (nie zapomnij ustawić bufora opóźnienia dla każdego zadania). 3. Zakończ zadanie. 4. Przejrzyj ponownie każde zadanie i sprawdź, czy jesteś wystarczająco produktywny, czy nie.

Oto sensowna i dokładna miara produktywności, która obejmuje wykonanie wielu migawek planowania opartych na dowodach :

Po zebraniu statystyk z kilku dni uruchom symulację Monte Carlo i obserwuj wykres, który powinien wyglądać następująco:

Następnie wykonaj jeszcze jeden dzień pracy i ponownie uruchom symulację. Jeśli byłeś produktywny tego dnia, wykres powinien zmienić coś takiego:

Co najważniejsze, jeśli byłeś produktem tego dnia, prawdopodobieństwo daty wysyłki w danym dniu powinno wzrosnąć od czasu ostatniego uruchomienia symulacji przed tym dniem pracy. Jeśli spadnie, wtedy byłeś mniej produktywny tego dnia.

Oczywiście dokładność EBS wzrasta z czasem i doświadczeniem, więc może to być kolejny powód zmiany wartości prawdopodobieństwa daty wysyłki. Dlatego chcesz zacząć to robić przynajmniej po kilku dniach próbkowania. Nawet bez tego jednak, jeśli byłeś znacznie bardziej produktywny pewnego dnia, prawdopodobieństwo powinno znacznie wzrosnąć.

Liczenie wierszy kodu jest niedoskonałym pomiarem, ponieważ nie zapewnia wglądu w jakość kodu, ale można go wykorzystać do określenia ogólnej wydajności. W zależności od używanego języka istnieją różne narzędzia, które policzą dla Ciebie wiersze kodu, ale poprosiłem, aby BitBucket, repozytorium Git, dodał statystyki związane z produktywnością.

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

Zmierz czas, jaki zajmuje rano siedzenie przy komputerze, aż wykonasz czynności niezwiązane z pracą, takie jak 9gag, facebook, reddit itp. Twoja wydajność tego dnia jest proporcjonalna do tej liczby.

Załóżmy przez chwilę, że bycie produktywnym to takie zarządzanie czasem, że cały swój czas pracy przeznaczasz na realizację swoich zadań i że wszystko, co przyczynia się do zmarnowanego czasu - tj. Czas spędzony na niezrealizowaniu zadań - nie jest produktywny.

Jedyne, co naprawdę możesz zrobić, to rejestrować swój czas, gdy angażujesz się w różne działania w ciągu dnia. Boks czasowy jest techniką stosowaną do różnych celów, ale odpowiadałby temu wysiłkowi, aby zarejestrować swoją aktywność w ciągu dnia. Poświęć 15 minut na samowyzwalacz po prostu wykonując jakieś zadanie. Jeśli to zadanie, nad którym powinieneś pracować, Twój czas był produktywny. Jeśli zdarzyło Ci się, że edytujesz swojego bloga, czytasz gazetę lub śnisz o tej miłej dziewczynie z księgowości, wtedy twój czas był prawdopodobnie nieproduktywny. Dodaj swoje minuty na koniec dnia, a poczujesz, jak produktywny jesteś ...

Ale jest haczyk! Co robisz z pozostałymi minutami ... wiesz, robiąc 5-minutową przerwę, idąc na lunch, każąc szefowi przeszkadzać ci, aby powiedział ci o tej dużej rybie, której nie złowił podczas ostatniej wyprawy na ryby? Zaloguj to wszystko. Czas spędzony na przerwie nie jest marnowany, jeśli przyczynia się do zdrowia psychicznego i dobrego samopoczucia ... tak długo, jak nie robisz 5-minutowej przerwy co 10-15 minut !! Jeśli chodzi o resztę, przerwy w pracy, zajmowanie się innymi sprawami związanymi z pracą .. wszystko to można śledzić.

Oczywiście możesz mieć obsesję na punkcie tego rodzaju rzeczy i niech Bóg ci pomoże, jeśli szef jest jedną z tych osób, które widzą cię w boksie czasowym i wykorzystuje to do uzasadnienia powodów, dla których warto poświęcić więcej pracy lub krytykować twoje wysiłki. Widzisz, problem z obsesją na punkcie produktywnych godzin polega na tym, że możesz pracować cały dzień, a mimo to nic nie robić. W niektóre dni możesz pisać kod jakby masło topiło się z mózgu i na kanapkę, którą nazywasz ekranem ... podczas gdy w inne dni możesz mieć poważny blok umysłowy, próbując 357 różnych sposobów, aby zrobić to samo rzecz, tylko po to, żeby zobaczyć, jak zawodzi Wielu powiedziałoby, że ciągłe „awarie” mogą być nieproduktywne, i że samo w sobie nie pomoże, bez względu na to, ile czasu skasujesz i rejestrujesz swoje godziny w ciągu dnia.

Innym sposobem, aby na to spojrzeć, jest po prostu postawienie sobie kilku celów, które należy wykonać w ciągu dnia i tygodnia, a następnie pracować nad ich osiągnięciem. Jeśli faktycznie osiągasz swoje cele, możesz argumentować, że byłeś produktywny, a jeśli nie osiągasz swoich celów, być może będziesz musiał zrozumieć, dlaczego ich nie osiągnąłeś i zdecydować, czy byłeś, czy nie byłeś produktywny na podstawie faktycznych przyczyn utraty celów. Ostatecznie, jeśli dostarczysz działający kod, gdy jest potrzebny, i jeśli zdołasz zaliczyć testy i wykonać zadanie, oznacza to, że jesteś produktywny. Pomiary będą miały wartość tylko wtedy, gdy istnieje uzasadniony powód do ich statystycznej analizy później.