średnie branżowe dla czasu poświęconego na konserwację


17

Menedżer niedawno ogłosił, że spędza zbyt dużo czasu na naprawianiu błędów. Wydaje mi się, że uważa, że ​​powinniśmy cały czas pisać idealny kod (oczywiście wciąż dotrzymując tych niemożliwych terminów!) I zastanawiałem się, jaka była średnia w branży czas naprawy błędów i pisania nowego kodu.

Czy ktoś ma jakieś dane dotyczące czasu poświęconego na naprawę błędów w stosunku do tworzenia nowego kodu? Czy może jest jakaś analiza empiryczna czasu naprawy błędów dla całej branży? Czy 50% wydanych poprawek jest za dużo, czy w porządku? A może około 20% lub 33%?

Z przyjemnością przyjmuję niepotwierdzone dowody z własnego doświadczenia, ponieważ stanowiłoby to część statystyk tutaj, z którymi mógłbym porównać nasze wyniki.


9
twój manager brzmi bardzo ignorancko. Sugerowana lektura takich przypadków: Fakty i wady inżynierii oprogramowania autorstwa Roberta L. Glassa, szczególnie „Fakt 43. Konserwacja to rozwiązanie, a nie problem”. Artykuł w Wikipedii wspomina o 80% wysiłku poświęconego na konserwację oprogramowania
komnata

3
Jaki jest prawdziwy problem? Czy masz problem z jakością? Czy twój proces jest naprawdę nieefektywny? A może Twój menedżer żałuje, że oprogramowanie nie kosztuje tak dużo?
kevin cline

@gnat: Twój komentarz jest najlepszą odpowiedzią
Kevin Cline


Konserwacja nie polega tylko na naprawianiu błędów (defektów), a jej ilość jest bardzo różna dla poszczególnych projektów (= brak jednoznacznej odpowiedzi). Wydaje mi się, że masz raczej problemy z jakością.
MAR

Odpowiedzi:


13

Menedżer niedawno ogłosił, że spędza zbyt dużo czasu na naprawianiu błędów.

Powyżej brzmi bardzo ignorancko. Sugerowana lektura takich przypadków: Fakty i wady inżynierii oprogramowania autorstwa Roberta L. Glassa, szczególnie „Fakt 43. Konserwacja to rozwiązanie, a nie problem”.

Artykuł w Wikipedii wspomina o 80% wysiłku poświęconego na utrzymanie oprogramowania.

mój manager sprawia, że ​​PHB Dilberta wygląda jak geniusz :)

Hm podane powyżej Chciałbym również podjąć pewne wysiłki w zakresie analizy, czy wszystkie wnioski zrobić są błędy rzeczywiście.

Z mojego doświadczenia wynika, że ​​zbyt często prośby o ulepszenia lub nowe funkcje były zgłaszane jako błędy. Dobrzy menedżerowie angażują swoich programistów w odkrycie tego - źli menadżerowie, no cóż, po prostu narzekają na zbyt wiele czasu na naprawianie błędów .


2
Naprawianie błędów! = Konserwacja! Naprawa błędów oznacza zakodowane usterki w systemie i muszą zostać naprawione w celu przywrócenia prawidłowej funkcjonalności . Przez konserwację rozumiem wszystkie zadania, takie jak poprawki błędów, ulepszenia skalowalności, migracja sprzętu i ulepszenia wydajności itp. Powiedziałbym, że ponad 25-30% czasu poświęcanego na naprawę błędów wymaga natychmiastowego wezwania do zarządzania. Do 40-50% wysiłku poświęconego na utrzymanie ogólnie wydaje się rozsądne w przypadku średniej wielkości systemu korporacyjnego.
Apoorv Khurasia

Czy masz jakieś dane liczbowe dla różnych klas błędów? Oczywiście, jeśli otrzymujesz dużą liczbę błędów o wysokim priorytecie, „pokaż stopper”, może być tak, że proces rozwoju wymaga trochę pracy w celu ustalenia źródła, ale jeśli wszystko jest małe, nie jest to taka wielka sprawa. Jak mówi gnat, wiele z nich może być prośbami o ulepszenie.
Stevetech,

Twój cytat z artykułu na Wikipedii jest błędny! Mówi, że „80% nakładów na konserwację jest zużywanych na działania nie korygujące” , ale nie mówi nic o czasie konserwacji w porównaniu do projektowania, kodowania lub innych prac.
Tobias Knauss

9

Pierwszym pytaniem, które należy zadać, jest to, czy twoje „naprawianie błędów” faktycznie naprawia błędy w kodowaniu, czy coś innego. Naprawianie błędów w kodzie powinno być w większości przypadków stosunkowo małe, o ile masz dobrą bazę kodu. Jeśli pracujesz ze słabą bazą kodu, nieodzowne jest obszerne usuwanie błędów.

Jednak w trakcie wprowadzania programu do produkcji znajdziesz wymagania, które nie zostały udokumentowane, nieoczekiwaną aktywność użytkownika, anomalie danych, niezgodności sprzętowe, problemy z instalacją i inne problemy, które nie są ściśle błędami w kodzie. Często menedżerowie i użytkownicy myślą o tych problemach związanych z obsługą / konserwacją produkcji jako błędami, ponieważ zwykle wymagają one zmiany kodu.

Zetknąłem się również z menedżerami, którzy pogrupowaliby błędy, które powinny być nazywane drobnymi prośbami o ulepszenie. Często są one wprowadzane do systemu śledzenia błędów lub zgłaszania problemów, co może sprawić, że statystyki błędów będą wyższe niż w rzeczywistości.


To, co
opisujesz,

8

To zależy od tego, ile masz kodu, jak długo tam był itp.

Czas spędzony na naprawianiu błędów w oprogramowaniu powinien zostać załadowany do pierwszych 6-12 miesięcy od wydania, jednak w miarę upływu czasu nieskończoność czas poświęcony na konserwację w porównaniu do czasu poświęconego na początkowe prace rozwojowe przekroczy 100% - tak po prostu praca.

Chociaż nie mam żadnych twardych statystyk (Code Complete, ale nie mogę powiedzieć dokładnie, która strona / sekcja), z mojego doświadczenia wynika, że ​​około 40% rozwoju (czasami nawet 60%) przeznacza się na utrzymanie. Oczywiste jest, że im więcej kodu zwolnisz, tym więcej czasu będziesz miał na utrzymanie. Błędy nie zawsze są funkcjonalne i są wynikiem zarówno niepewności, jak i wad programistycznych.


0

jeśli korzystasz z dobrego narzędzia do śledzenia biletów (takiego jak Jira z Atlasian) i spędziłeś czas na poprawnym wpisywaniu różnych kategorii, historii użytkowników, poziomów pilności i za zgodą kolegów z zespołu, wówczas obliczasz te wskaźniki (i więcej) są niezwykle łatwe.

W poprzednim projekcie korzystaliśmy z Jiry do zarządzania listami błędów / zadań / czynności do wykonania, a ostatecznie pokazało nam, że największą przyczyną opóźnień i problemów okazały się nieefektywne praktyki zarządzania.

O dziwo, kiedy ta informacja się pojawiła, nagle powiedziano nam, że nie będziemy już używać Jiry i że zostanie wprowadzony nowy produkt, aby ją zastąpić.

W międzyczasie wszystkie prośby o przekazanie danych przez Jira musiały zostać wysłane do zespołu zarządzającego, a nasz bezpośredni dostęp został usunięty.

Nie zauważono, że w ramach obliczania statystyk zespół deweloperów zmusił Jirę do umieszczania danych w haku internetowym, a ten hak internetowy był używany do przekazywania danych do punktu końcowego na niektórych serwerach wewnętrznych, na których mieliśmy utworzony kod raporty te automatycznie.

Zaczęliśmy monitorować hak sieciowy i stwierdziliśmy, że chociaż powiedziano nam, że Jira nie jest już używana, pozostała przy życiu przez dłuższy czas (dokładnie 6 miesięcy), a nadużycie hurtowe ze strony kierownictwa było po prostu szalejący z niewłaściwym użyciem.

Oczywiście nie musi to być coś tak złożonego jak Jira.

Jeśli potrzebujesz rozwiązania o niskiej wydajności, możesz użyć arkusza kalkulacyjnego google-docs i interfejsu API powiadomień GDocs, aby śledzić zadania / bilety / błędy / żądania funkcji itp.

Sam GDocs może teraz wydawać haczyki internetowe i wiele innych rzeczy.

Połącz to z Git i / lub Github i niektórymi hakami, które uruchamiają się, gdy kod jest zapisywany w twoim repozytorium, a masz dość wydajny system domowego zaparzania, który może rejestrować zaskakującą ilość danych.

Zasadniczo jednak na 100% naturalnego okresu użytkowania produktu, podział na projekt greenfield i utrzymanie wynosi na ogół 20/80, większość kosztów w cyklu ALM (Application Lifetime Management) jest pokrywana z kosztów utrzymania i wsparcia.

Nie ma czegoś takiego jak spędzanie zbyt dużo czasu na naprawianiu błędów, ponieważ po prostu nie jest możliwe napisanie kodu wolnego od błędów.

Dobre zasady testowania i ciągłej integracji zmniejszą niedobór, ale nigdy go całkowicie nie wyeliminujesz.

Każdy, kto wierzy inaczej (IMHO), nie ma wystarczającej wiedzy, aby dokonać dokładnego osądu, lub jest ślepy (bardziej powszechny przypadek) na to, jak trudne jest pisanie oprogramowania.

Jeśli twój menedżer jest na to gotowy, a niektóre z nich, możesz zasugerować, że cieni cię na jeden dzień, aby mógł zobaczyć dokładnie, co robisz i jak to robisz.

Iv'e pracowała w kilku firmach, w których aktywnie zachęcano do tego rodzaju pracy, z personelem wyższego szczebla zasłaniającym personel niższego szczebla, i odwrotnie, może to być naprawdę dobre doświadczenie edukacyjne dla obu zaangażowanych stron.


2
„Nie ma czegoś takiego jak spędzanie zbyt dużo czasu na naprawianiu błędów” - co za bzdury. Jeśli spędzasz wystarczająco dużo czasu na naprawianiu błędów, które popełniają twoja firma, ponieważ nie może pozostać konkurencyjny na rynku (ponieważ naprawiasz błędy zamiast robić różne rzeczy),
spędzasz

A alternatywa? - Nie spędzasz wystarczająco dużo czasu na naprawianiu błędów, a aplikacja ulega awarii, przypala się, a Twój konkurent bierze wszystko na siebie, skutecznie wypychając cię z rynku. Sztuką (i najtrudniejszą częścią tego wszystkiego) jest znalezienie odpowiedniej równowagi.
shawty

1
Nie, zgadzam się, ale takie są moje własne opinie, ponieważ naprawdę wierzę w ten dzień i epokę, sztuka prawidłowego debugowania staje się sztuką zagubioną. Zbyt wielu z nas polega zbytnio na testach jednostkowych, które IMHO zapewniają zbyt wiele fałszywych zabezpieczeń. Nie twierdzę, że test jednostkowy powinien zostać zniesiony, ale mówię, że z tego powodu nie wykonano już wystarczającej liczby prawidłowych procedur debugowania i naprawy błędów. Ta kolej prowadzi do przekonania menedżerów (jak opisano powyżej), że poprawianie błędów nie jest wymagane, w wyniku czego naprawdę (ponownie IMHO) nie robimy wystarczająco dużo.
shawty

2
testy jednostkowe i debugowanie to różne techniki stosowane w przypadku różnych problemów. Chociaż rozwiązanie problemu „czy nasz kod jest poprawny” lepiej zapobiega problemowi „dlaczego mój kod się zepsuł”. Mimo wszystko, wolę, aby ludzie byli dobrzy w tworzeniu poprawnego kodu niż w identyfikowaniu pierwotnych przyczyn.
Telastyn

1
Teraz mam pełną zgodę. To smutny fakt, że w dzisiejszej branży wielu programistów traktuje to jako kolejną pracę od 9 do 5, gdzie wpisują się, wybijają kod do czasu domowego i wyrejestrowują się. Dawno temu twórcy oprogramowania byli bardzo dumni z pisania dobrego, solidnego, dobrze przetestowanego kodu i spędzili czas, zastanawiając się nad nim, zanim zbliżyli się do klawiatury, w dzisiejszych czasach jest go bardzo mało.
shawty
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.