Jak oszacować czas potrzebny na naprawę błędu

W jaki sposób oszacować czas jaki zajmie usunięcie błędu? Przełożony chce, żebym mu podał czas potrzebny na usunięcie awarii. Czy to w ogóle możliwe, żeby określić czas, jeśli nie mam pojęcia ile mi zajmie chocby znalezienie przyczyny awarii?

To może powiedz mu dokładnie to, co tutaj napisałeś.

To zależy od problemu. Zazwyczaj jesteś w stanie oszacować czy coś zajmie bardziej 4 godziny czy 3 dni na podstawie samego błędu. Czasem zdarzy się, że coś co wydawało się, że zajmie 30 minut zajmie tydzień ale to wyjdzie w trakcie i wystarczy poinformować przełożonego jak spyta i tyle

Powiedz mu, że najpierw potrzbujesz jeden MD na analizę, tzn znalezienie sedna awarii (czy to przejrzenie logów, czy debug i reprodukcja), a dopiero potem powiesz ile zajmie fixing :)

U mnie w pracy nigdy nie byłem w stanie oszacować długości trwania naprawy buga, parę zdarzyło mi się nawet przepisać całą funkcjonalność, ponieważ dłużej mi szło diagnozować problem niż naprawiać. (Nie mówię tutaj o prostych rzeczach jak wyrównanie CSSem szablonu)

Często te bugi wynikały że ludzie np. używali jakiejś technologii pierwszy raz bo była modna.

Ogólnie wydaje mi się że po analizie problemu można stwierdzić czy będzie to zajmowało tydzień czy dwa dni.

Jeśli siedzisz już w projekcie jakiś czas to są takie bugi, które potrafisz naprawić od ręki bo od razu wiesz gdzie się spieprzyło. Z drugiej strony są takie, gdzie zrobienie try - cach na całą metodę i dodanie jakiegoś mega logowania i czekanie aż bug się powtórzy i liczenie na to, że ten log powie coś więcej to jedyne rozwiązanie.

Oszacuj, ile myślisz, ile to zajmie i pomnóż przez n (gdzie n jest tym większe, im więcej niewiadomych)
np.
myślisz, że zajmie to godzinę, więc mówisz 10h.

W nieczęstych sytuacjach, że z 90% pewnością wiem co jest istotą błędu (wiem, co było ruszane, albo treściwy wyjątek, albo jedno i drugie) to niekiedy daję jakieś deklaracje. Godzina, do jutra, albo "w sobotę zaktualizujemy"

Ale generalną zasadą jest jak piszecie: "może coś da się powiedzieć po analizie przyczyny"

Napisałeś że jesteś początkujący, a jednocześnie rozmawiasz z PMem o terminach naprawienia błędów? Czy oprócz ciebie jest w zespole bardziej doświadczony programista(mający wiedzę o projekcie i doświadczenie w technologi)?

Jak ustalisz, co jest do zrobienia, to podasz estymate. Do tego czasu możesz dawać updaty na zasadzie „pracujemy nad tym, następny update za 2h”. Na wczesnym etapie ważne, żeby był owner tematu ;)

Za tym pytaniem kryje sie jakaś potrzeba PMa. Zapytaj po co mu ta estymata.

PM lubi mieć zarys czynności, które będą wykonywane w ramach usuwania błędu. Daj mu jakiś plan, np. 5 punktów, które pozwolą mu sie poczuć lepiej i umożliwią komunikację z klientem i sprawdzanie czy nastąpiło przesunięcie z pkt. 1. do 2. (PM może zakomunikowac klientowi mały sukces). Taki plan jest też korzystny dla Ciebie (mówisz co będziesz robił i to robisz - to buduje zaufanie do Twojej pracy). Dodatkwo uzyskasz strukturę pracy dotyczącą naprawy problemu.

Możesz tez wykorzystać sytuację, "do oszacowania potrzebuję... " i lecisz z listą życzeń do PMa ;) np. Instalacja u klienta softu z dodatkowymi punktami logowania + obecność użytkowników, którzy problem zreprodukują.

2x tyle ile Ci sie wydaje ze to zajmie + zmiana jednostki czasu na wieksza.

"Będzie zrobione jak będzie zrobione".

Poza tym najczęściej działam w sposób opisany przez @yarel . Na początek konkretne okno czasowe na wstępną analizę i rozpisanie kroków inwestygacji/naprawy. Póżniej to tylko notyfikowanie zainteresowanych o postępach i zakończeniu. Czy to bugi w aplikacji, czy problem na produkcji działam tak samo. Z problemami na produkcji jest nawet prościej - proces rozwiązywania awarii jest udokumentowany, więc każdy wie jak działać. Przy większych problemach, lub takich gdzie widzimy pole do poprawy ruszają procesy związane z analizą przyczyn problemu. Sam proces rozwiązywania problemu też jest analizowany i ulepszany.

Sporo przykładów na procesy analizy awarii można wyszukać na necie, ale to czy działają i istnieją zależy od jakości firmy, pracowników itp. w januszexie trzeba proces hakować ;) albo się wypyszczyć.

Jeżeli chodzi o profesjonalne podejście to należy to podzielić na dwa etapy: 1. znalezienie błędu 2. naprawa błędu.
Na etapie poszukiwania ustala się czas cyklicznych komunikatów na temat statusu, np. co godzinę w zależności od tego jak istotny jest to błąd. Tutaj często jest tak, że kilka razy będziemy musieli podać komunikat, że nadal szukamy jak trafimy na coś bardziej złożonego.
Etap naprawy i jego pracochłonność estymujemy standardowo jak każdy inny task, mając jednak na uwadze czy na pewno znamy przyczynę błędu czy nam się tylko tak wydaje :) co przy pracy pod presją jest wielce prawdopodobne. Tutaj oczywiście też powinna być komunikacja statusu, przede wszystkim wtedy, gdy w trakcie naprawy okaże się, że podana estymata nie była prawidłowa.

Krótka rada - mówić prawdę.

• Jak nie możesz zreprodukować błędu, to to mówisz, dodając, że aktualnie nie masz pojęcia ile to zajmie, możliwe, ze za godzinę będziesz wiedział więcej. Na tym etapie może się okazać, ze za 15 minut, bo trzeba zmienić > na >=, albo poświęcić miesiąc na namierzanie gnojka i pół roku na refaktoryzację połowy systemu
• Jak zreprodukowałeś i wiesz, że mogło walnąć w 1 z 15 miejsc, to mówisz, że aktualnie od 2 godzin, do 2 miesięcy
• Zlokalizowałeś problem, popatrzyłeś w kod, masz jakąś wizję złożoności, pracochłonności, to mówisz "3 dni", czy co ci tam wychodzi.

Trochę mi się nie mieści w głowie, że w sytuacji typu "klient ma problem z naszym oprogramowaniem, stanęła linia produkcyjna i traci właśnie 3 bańki dziennie oraz dzwoni co 15 minut po update'y", odpowiadać "idź pan w uj, będzie jak będzie". Trzeba udzielać najlepszej dostępnej w danym momencie informacji i pamiętać przy tym, że szacunek to nie tylko czas, ale też niepewność. Dobrze, jeżeli ta niepewność w czasie incydentu maleje.

@piotrpo: w przypadku jak sie juz ma klientow o takiej skali, warto zainwestowac w status page'a, to ogranicza ilosc komunikacji (ale trzeba aktualizowac)