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

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.

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 .

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 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.

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.