Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

Witam,

pytanie jak w temacie, jestem ciekaw jak jest w innych firmach a także jak teoretycznie powinno być.

Jak uważacie, jeśli programista wypuści wersję do działu testów, testując wybiórczo wcześniej czyli sam nie mając pewności czy jest dobrze, dział testów to akceptuje a później klient zgłasza np 4 błędy do funkcjonalności która według działu testów działa.

Kto powinien być odpowiedzialny w tym wypadku ?

Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

Jeśli jest to przypadek jednostkowy, to w pierwszej kolejności odpowiada osoba nadzorująca projekt - to jej wina, że nie dopilnowała, żeby
(1) programista wykonał swoją pracę,
(2) dział QA wykonał swoją pracę.
Jednak osoba nadzorująca projekt po przyjęciu odpowiedzialności ma pełne prawo wyciągnąć konsekwencje od programisty i QA, ponieważ, bądźmy szczerzy, oddanie funkcjonalności bez dokładnego przetestowania to handel życzeniami i naganna praktyka.

Zamiast wskazywać winnych byłoby dużo lepiej jeszcze raz określić kto za co jest odpowiedzialny i zwyczajnie to egzekwować. Niby to takie proste, a tak wielu ludzi o tym zapomina.

Jakbyście byli zainteresowani, to sam siebie polecam http://www.quality4.it/.

EDIT: literówka, link do mojej strony. Krzysztof Daniel edytował(a) ten post dnia 01.10.12 o godzinie 17:32

Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

siemanko Maciek,

Moim zdaniem za blad puszczony do klienta odpowiada firma, to w jej marka cierpi najbardziej.
Bardziej sie nalezy nastawic na wspolprace tester- deweloper, bo przeciez mamy ten sam cel, wypuscic oprogramowanie z najmniejsza iloscia bledow... Usiasc razem , wyciagnac wnioski i robic tak, zeby puszczac dobra wersje. To nic nie daje przezucanie odpowiedzialnosci, wtedy jest takie odbijanie pileczki, ja swoje zrobilem bla bla...

Najwazniejsza jest wspolna praca i puszczenie dobrej wersji, nie wazne kto znajdzie blad, oby zostal znaleziony.. ;)

pozdrawiam

Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

Maciej Bąk:
Witam,

pytanie jak w temacie, jestem ciekaw jak jest w innych firmach a także jak teoretycznie powinno być.

Jak uważacie, jeśli programista wypuści wersję do działu testów, testując wybiórczo wcześniej czyli sam nie mając pewności czy jest dobrze, dział testów to akceptuje a później klient zgłasza np 4 błędy do funkcjonalności która według działu testów działa.

Kto powinien być odpowiedzialny w tym wypadku ?

1. Programista - za brak pewności
programista nie powinien oddawać oprogramowania które jest w stanie "mam nadzieję że działa"
mimo to testowanie akceptacyjne nie jest jego broszką więc "testowanie wybiórcze" jest tylko stratą czasu , nie dość że duplikuje pracę kolegów z QA to jeszcze niedokładnie
2. QA - za przepuszczenie , pewnie też nie wiedzieli jak to ma działać ;)
http://www.joelonsoftware.com/articles/fog0000000043.html

Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

Maciej Bąk:
Kto powinien być odpowiedzialny w tym wypadku ?

Po pierwsze: To zależy.
Po drugie: To jest złe pytanie i wskazuje na patologię firmy. Lepsze jest: "Co powinniśmy zrobić, aby to się nie powtórzyło?"
Po trzecie: Współczuje.

Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

No to prawda, lepiej myśleć co robić żeby tak się nie powtarzało.
Ja ostatnimi czasy wyszedłem z założenia, że wolę już mniej zrobić danego dnia i spokojnie sprawdzić zanim dam do testów, niż zrobić dużo, testy takie w pół na oko i dać do testera.

Tu jest fajny taki art. http://97rzeczy.devblogi.pl/artykuly/67/profesjonalny-...
jakby ktoś był zainteresowany ;)

Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

Hej!

Nie wyobrażam sobie by po jakiejś "wtopie" nie wyciągnąć konsekwencji i od zespołu QA i Developerów. Jeżeli tego nie zrobimy, szybko może dojść do patologii. w której IT nie czuje się w ogóle odpowiedzialne za błędy.
Nie mówię tu o karach cielesnych, ale konstruktywnej analizie przyczyny danego błędu i przejście przez cały proces od przyczyny do (de)efektu- jest to czas by pomyśleć co można było zrobić lepiej/co przeoczyliśmy. Wtedy cały zespół uczy się jak robić pewne rzeczy lepiej, a przede wszystkim czuje się odpowiedzialny za produkt, który przekazuje klientowi.
Oczywiście w pierwszej kolejności naprawiamy problem, następnie dopiero analizujemy co jest przyczyną po czym wyciągamy konsekwencje i odpowiednie wnioski. Czasem ciężko jest ustalić odpowiedzialność jednej osoby, jednak pamiętajmy, że gramy w grę zespołową. Nie ma też co przesadzać z ew. "karami", nie chcemy by QA czy Developerzy byli zastraszeni i wstrzymywali wdrożenia "bo nie chcą przepuścić błędu" lub byli sfrustrowani ciągłymi karami. Jak zwykle w teorii wszystko brzmi prosto i łatwo, zachowanie jednak balansu jest nie lada wyzwaniem. Przydają się też metryki zliczające ilość błędów wyłapanych na produkcji itd. Mamy wtedy konkretne dane na których możemy się opierać. Wiadomo, że inne kroki podejmiemy gdy sytuacja jest incydentalna, a inne gdy problem i ilość błędów po wdrożeniu narasta.

Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

Marcin Złotowicz:
Hej!

Nie wyobrażam sobie by po jakiejś "wtopie" nie wyciągnąć konsekwencji i od zespołu QA i Developerów. Jeżeli tego nie zrobimy, szybko może dojść do patologii. w której IT nie czuje się w ogóle odpowiedzialne za błędy.
Nie mówię tu o karach cielesnych, ale konstruktywnej analizie przyczyny danego błędu i przejście przez cały proces od przyczyny do (de)efektu- jest to czas by pomyśleć co można było zrobić lepiej/co przeoczyliśmy. Wtedy cały zespół uczy się jak robić pewne rzeczy lepiej, a przede wszystkim czuje się odpowiedzialny za produkt, który przekazuje klientowi.
Oczywiście w pierwszej kolejności naprawiamy problem, następnie dopiero analizujemy co jest przyczyną po czym wyciągamy konsekwencje i odpowiednie wnioski. Czasem ciężko jest ustalić odpowiedzialność jednej osoby, jednak pamiętajmy, że gramy w grę zespołową. Nie ma też co przesadzać z ew. "karami", nie chcemy by QA czy Developerzy byli zastraszeni i wstrzymywali wdrożenia "bo nie chcą przepuścić błędu" lub byli sfrustrowani ciągłymi karami. Jak zwykle w teorii wszystko brzmi prosto i łatwo, zachowanie jednak balansu jest nie lada wyzwaniem. Przydają się też metryki zliczające ilość błędów wyłapanych na produkcji itd. Mamy wtedy konkretne dane na których możemy się opierać. Wiadomo, że inne kroki podejmiemy gdy sytuacja jest incydentalna, a inne gdy problem i ilość błędów po wdrożeniu narasta.

Jak to w praktyce wygląda?
Po naprawieniu błędu, robicie spotkanie. W trakcie jego trwania cały zespół dochodzi do wniosku, że Witek programista wprowadził bug'a, Karol tester przetestował co innego bo Marysia z analiz źle ujęła wymaganie? Po takim spotkaniu karacie te trzy osoby, i w ten magiczny sposób budujecie dobrze zmotywowany zespół i dobrą atmosfere?

Pzdr.

Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

Grzegorz Świeć:

Marcin Złotowicz:
Hej!

Nie wyobrażam sobie by po jakiejś "wtopie" nie wyciągnąć konsekwencji i od zespołu QA i Developerów. Jeżeli tego nie zrobimy, szybko może dojść do patologii. w której IT nie czuje się w ogóle odpowiedzialne za błędy.
Nie mówię tu o karach cielesnych, ale konstruktywnej analizie przyczyny danego błędu i przejście przez cały proces od przyczyny do (de)efektu- jest to czas by pomyśleć co można było zrobić lepiej/co przeoczyliśmy. Wtedy cały zespół uczy się jak robić pewne rzeczy lepiej, a przede wszystkim czuje się odpowiedzialny za produkt, który przekazuje klientowi.
Oczywiście w pierwszej kolejności naprawiamy problem, następnie dopiero analizujemy co jest przyczyną po czym wyciągamy konsekwencje i odpowiednie wnioski. Czasem ciężko jest ustalić odpowiedzialność jednej osoby, jednak pamiętajmy, że gramy w grę zespołową. Nie ma też co przesadzać z ew. "karami", nie chcemy by QA czy Developerzy byli zastraszeni i wstrzymywali wdrożenia "bo nie chcą przepuścić błędu" lub byli sfrustrowani ciągłymi karami. Jak zwykle w teorii wszystko brzmi prosto i łatwo, zachowanie jednak balansu jest nie lada wyzwaniem. Przydają się też metryki zliczające ilość błędów wyłapanych na produkcji itd. Mamy wtedy konkretne dane na których możemy się opierać. Wiadomo, że inne kroki podejmiemy gdy sytuacja jest incydentalna, a inne gdy problem i ilość błędów po wdrożeniu narasta.

Jak to w praktyce wygląda?
Po naprawieniu błędu, robicie spotkanie. W trakcie jego trwania cały zespół dochodzi do wniosku, że Witek programista wprowadził bug'a, Karol tester przetestował co innego bo Marysia z analiz źle ujęła wymaganie? Po takim spotkaniu karacie te trzy osoby, i w ten magiczny sposób budujecie dobrze zmotywowany zespół i dobrą atmosfere?

Pzdr.

Już wyjaśniam o co dokładnie mi chodziło.
Przy pewnym etapie naprawiania błędu (i to zwykle dla wyższych wartości krytyczności błędu) jest etap gdzie "namierzamy" w jakiej zmianie błąd został wprowadzony. Jeżeli wiem już kto, kiedy i gdzie, to przeprowadzam rozmowę gdzie omawiam problem i wspólnie z "winowajcą" wyciągamy wnioski gdzie popełniono błąd i jak uniknąć go w przyszłości. Taka konstruktywna rozmowa zwana jest udzielaniem informacji zwrotnej i jest elementem nauki - ulepszaniem swego warsztatu. Nie neguje konieczności przemyślenia sposobu poprawy, ale pragnę zwrócić uwagę na to, że odpowiedzialność w jakiejś formie powinna być egzekwowana. Możemy to przenieść na grunt innych zawodów. Osobiście nie chciałbym, by mechanik, który serwisuje układ hamulcowy w moim samochodzie, w razie wypadku, zastanawiał się tylko nad tym jak nie dopuścić do kolejnego incydentu. Oczekiwałbym jakiejś odpowiedzialności. Przykład lekarza jest jeszcze bardziej dobitny.

Podsumowując, wyciąganie odpowiedzialności nie musi wyglądać tak demonicznie jak to opisałeś w swoim przykładzie, a kary powinny pojawiać się tylko w sytuacjach patologicznych, o których wspomniałem (notoryczne błędy, rażące zaniedbania etc.). Nie dajmy się zwariować. W obecnych czasach każda firma organizująca podobne "polowania na czarownice" miała by wielki problem ze skompletowaniem zespołu (i słusznie!) , bo nikt by tam nie wytrzymał:) A już na pewno żaden tester, który jak wiemy pomimo szerokiej wiedzy, super narzędzi i usilnych starań nie zawsze wszystko "wyłapie".Marcin Złotowicz edytował(a) ten post dnia 05.10.12 o godzinie 01:19

Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

Analogie mają to do siebie, że dość łatwo o nadmierne uproszczenia. Za błędy w produkcie przed klientem odpowiada, finansowo i merytorycznie, firma (a za błędy lekarza bądź mechanika ich zakłady pracy). Niemniej chyba nie to było pytaniem autora wątku, raczej to, co powinno się stać za zamkniętymi drzwiami wewnątrz firmy, a do tego klient już nic nie ma.

Ograniczenie odpowiedzialności do QA i programisty jest zaniedbaniem ze strony kierownictwa. Za projekt odpowiada PM, za PMa dyrektor i tak dalej. Jeśli kultura pracy nie wspiera pisania bezbłędnego kodu (a jedyną metryką sukcesu jest ilość naprawionych błędów na dzień) to karanie deweloperów/QA za błędy prowadzi co najwyżej do spadku morale i rotacji pracowników.

W pierwszej kolejności należy szukać błędów po stronie organizacyjnej, a dopiero potem jednostkowym. W przypadku autora wątku pewnych informacji dostarczają opinie o jego firmie (znalazłem na GL), wśród których powtarza się "duży poziom stresu". Nie wróży to nic dobrego (dla firmy).

Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

Krzysztof Daniel:
Analogie mają to do siebie, że dość łatwo o nadmierne uproszczenia. Za błędy w produkcie przed klientem odpowiada, finansowo i merytorycznie, firma (a za błędy lekarza bądź mechanika ich zakłady pracy).

Prawda o ile klient jest z zewnątrz, a nie wewnątrz organizacji. W takim wypadku sytuacja zwykle nie jest tak prosta.

Ograniczenie odpowiedzialności do QA i programisty jest zaniedbaniem ze strony kierownictwa. Za projekt odpowiada PM, za PMa dyrektor i tak dalej. Jeśli kultura pracy nie wspiera pisania bezbłędnego kodu (a jedyną metryką sukcesu jest ilość naprawionych błędów na dzień) to karanie deweloperów/QA za błędy prowadzi co najwyżej do spadku morale i rotacji pracowników.

Ok, skupiłem się na QA i developerach bo ich dotyczyło pytanie.

W pierwszej kolejności należy szukać błędów po stronie organizacyjnej, a dopiero potem jednostkowym.

Tu zgoda.

Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

Marcin Złotowicz:

Nie mówię tu o karach cielesnych, ale konstruktywnej analizie przyczyny danego błędu i przejście przez cały proces od przyczyny do (de)efektu- jest to czas by pomyśleć co można było zrobić lepiej/co przeoczyliśmy. Wtedy cały zespół uczy się jak robić pewne rzeczy lepiej, a przede wszystkim czuje się odpowiedzialny za produkt, który przekazuje klientowi.

BTW. Gratuluję organizacji :-). Z moich doświadczeń wynika, że to rzadkość·

Temat: Kto powinien odpowiadać za wersję z błędami która poszła...

Taka wrzutka troche z innej strony (nie dotyczaca bezposrednio sledzenia - gdzie popelniono blad/jak go uniknac w przyszlosci).
Kiedys przygotowalem krotka prezentacje dla Designu na temat "Co my tu robimy w tescie".
Na ostatnim, troche prowokacyjnym slajdzie bylo cos takiego:
- Who is responsible for Quality?
- Management

Z perspektywy projektów, ktore rozpisane sa na kilkadziesiat tysiecy roboczo-godzin blad u klienta to cos co mozna (Trzeba) ograniczac, ale tego sie nie uniknie.

W srodowisku, w ktorym wielu dostawcow probuje jak najszybciej, z jak najlepsza jakoscia dostarczyc produkt o podobnej funkcjonalnosci (np. w telefonii komorkowej, wszyscy chca byc zgodni ze specyfikacjami 3GPP), kluczowym aspektem jest to ile roboczo godzin mozna przeznaczyc na test i na design, tak zeby nadal sie to oplacalo :-).
Strategie sa rozne, np.:
firma A oferuje stabilniejsze rozwiazania, chodz troche drozej
Firma B oferuje taniej chodz bledy (naprawiane juz pozniej, gdy system dziala) zdazaja sie czesciej -ale klienci godza sie na to, majac na uwadze cene produktu
Firma C oferujaca produkt za podobna cene co A (chodz z gorsza jakoscia) systemy z funkcjonalnosciami, kore firma A ma dopiero w roadmapie na nastepny rok :-)

To ukladanie strategii, to takie troche samookreslanie sie gdzies na rynku, a troche dorazne dostosowywanie sie do bierzacej sytuacji.
W kazdym razie high level management decydujac "wyprzedzmy konkurencje, za pomoca tej samej ilosciu designerow/testerow" ustawia pewien poziom quality (i oczywiscie zdaje sobie sprawe z konsekwencji, ale uznaje ze bedzie sie to firmie oplacac).