Czy powinniśmy przestać próbować robić zwinnie, jeśli kontrola jakości zajmuje 12 tygodni?

24

Ktoś w mojej firmie niedawno zaproponował zmiany w naszym podstawowym produkcie, które zdaniem naszych menedżerów powinny uruchomić to, co, jak sądzę, moja firma uważa za pełny cykl kontroli jakości (tj. Testowanie całego pakietu produktów od podstaw). Najwyraźniej nasza kontrola jakości zajmuje 12 tygodni, aby wykonać pełny cykl kontroli jakości naszego produktu. Mój problem polega na tym, że staramy się rozwijać Agile (choć moim zdaniem w większości na wpół oceniany). Zrobimy cały zestaw sprintów, a następnie wydamy wydanie, które, jak sądzę, zajmie wieczność. Pytanie naprawdę brzmi: czy nasza kontrola jakości zajmie 12 tygodni, czyż nie powinniśmy po prostu rezygnować z prób zwinności? Po co, u diabła, warto próbować robić Agile w takiej sytuacji?

David Hosier
źródło
36
Zaryzykowałbym stwierdzenie, że jeśli kontrola jakości zajmuje 12 tygodni, to nie „zwinnie”.
SingleNegationElimination
9
Jeśli zespół nie jest odpowiedzialny za jakość produkowanego przez siebie kodu, nie nazwałbym go zwinnym.
merryprankster
1
@merryprankster Czy mógłbyś rozwinąć swoją odpowiedź? Czy chcesz powiedzieć, że nie ma sensu nie brać udziału w kontroli jakości do zespołu i weryfikować jakości w ramach sprintu? Czy może masz na myśli, że zespół powinien samodzielnie sprawdzać jakość do punktu, w którym kontrola jakości powinna być prawie bezużyteczna? A może inne znaczenie? Nie znam tutaj poprawnych odpowiedzi. Po prostu szukam porady, jak mogę rozwiązać problem, który moim zdaniem jest strasznie zepsuty. Dzięki.
David Hosier
2
Mam na myśli, że zespół powinien posiadać proces jakości. Zrobią wszystko, co trzeba, aby upewnić się, że jakość jest wystarczająco dobra. Dzięki temu pętla zwrotna jest tak krótka, jak to możliwe, i sprawia, że ​​jest bardziej osobista. Jakość nie jest własnością zewnętrzną, jest nieodłączną częścią rozwoju.
merryprankster
2
To staje się czatem, więc to będzie mój ostatni komentarz. Tak, zgadzam się, że w realnym świecie twoje otoczenie jest ograniczone. Ponadto powinieneś być w stanie wybrać i wybrać sposób pracy. Myślę jednak, że to nie prawda, że ​​zwinność na czacie jest elastyczna pod każdym względem, wręcz przeciwnie: wymaga zwinności dyscypliny . Jednym z ważnych aspektów zwinnego rozwoju jest utrzymywanie krótkich pętli sprzężenia zwrotnego. Jeśli masz fazę kontroli jakości poza iteracją, informacje zwrotne są spóźnione. Jeśli zespół nie zajmie się kontrolą jakości w ramach iteracji, nie jest zwinny. Zespół może zdecydować, w jaki sposób przeprowadzać kontrolę jakości - to elastyczne - ale zespół powinien to zrobić.
merryprankster

Odpowiedzi:

21

Cóż, bezpośrednia odpowiedź na twoje pytanie brzmi Mu. Obawiam się - po prostu nie ma wystarczających szczegółów, aby dobrze poinformować, czy powinieneś przestać próbować.

Jedyną rzeczą, którą jestem całkiem pozytywnie nastawiony, jest to, że poziom zwinności powinien być napędzany potrzebami klientów / rynku (o których nie poinformowałeś).

  • Na przykład, jako użytkownik IDE, cieszę się, że mogę uaktualnić do nowej wersji raz, a może dwa razy w roku i nigdy się nie spieszy. To znaczy, jeśli ich cykl wydawania wynosi 3 miesiące ( 12 tygodni ), jestem z tego całkowicie zadowolony.
     
    Z drugiej strony mogę sobie łatwo wyobrazić, powiedzmy, że firma zajmująca się obrotem finansowym zbankrutuje, jeśli oprogramowanie zajmie więcej niż miesiąc, aby dostosować swoje oprogramowanie do zmian rynkowych - w tym przypadku 12-tygodniowy cykl testowy byłby drogą do piekła. Teraz - jakie są twoje potrzeby w tym zakresie?

Inną rzeczą do rozważenia jest to, jaki poziom jakości jest wymagany, aby zaspokoić potrzeby klienta / rynku?

  • Przykładowo - w firmie, w której kiedyś pracowałem, stwierdziliśmy, że potrzebujemy nowej funkcji w produkcie licencjonowanym od jakiegoś dostawcy oprogramowania. Bez tej funkcji cierpieliśmy dość mocno, więc tak, naprawdę chcieliśmy, aby były zwinne i dostarczyły aktualizację w ciągu miesiąca.
     
    I tak, wydawali się zwinni i tak, wydali tę aktualizację w ciągu miesiąca (jeśli ich cykl kontroli jakości wynosi 12 tygodni, prawdopodobnie po prostu ją pominęli). A nasza funkcja działała doskonale - nie powinniśmy być szczęśliwi? Nie! odkryliśmy błąd regresji showstopper w niektórych funkcjach, które wcześniej działały dobrze - więc musieliśmy trzymać się starszej wersji.
     
    Minął kolejny miesiąc - wydali kolejną nową wersję: naszą funkcjębył, ale był tam również ten sam błąd regresji: ponownie nie zaktualizowaliśmy. I kolejny miesiąc i jeszcze jeden.
     
    Ostatecznie byliśmy w stanie ulepszyć zaledwie pół roku później tak bardzo ze względu na ich zwinność.

Teraz przyjrzyjmy się bliżej tym 12 tygodniom , o których wspominasz.

Jakie opcje rozważałeś, aby skrócić cykl kontroli jakości? jak widać z powyższego przykładu, zwykłe pominięcie go może nie dać ci tego, czego oczekujesz, więc lepiej być, cóż, zwinny i rozważ różne sposoby rozwiązania tego problemu.

Czy na przykład zastanawiałeś się, jak poprawić testowalność swojego produktu?

A może zastanawiałeś się nad rozwiązaniem brutalnej siły, aby po prostu wynająć więcej QA? Jakkolwiek wygląda to prosto, w niektórych przypadkach tak naprawdę należy. Widziałem niedoświadczone kierownictwo próbujące rozwiązać problemy z jakością produktu, na oślep zatrudniające coraz więcej starszych programistów, w których średnia para profesjonalnych testerów. Całkiem żałosne.

Ostatni, ale nie mniej ważny - myślę, że należy zwinnym w kwestii stosowania zasad zwinności. Chodzi mi o to, że jeśli wymagania projektu nie są zwinne (stabilne lub zmieniają się powoli), to po co? Kiedyś zauważyłem, że najwyższe kierownictwo wymusza Scrum w projektach, w których doskonale sobie radzi. Co za marnotrawstwo. Nie tylko nie było żadnych ulepszeń w ich dostarczaniu, ale co gorsza, wszyscy programiści i testerzy byli niezadowoleni.


aktualizacja na podstawie wyjaśnień zawartych w komentarzach

Dla mnie jedną z najważniejszych części Agile jest możliwość wydania na końcu każdego sprintu. To sugeruje kilka rzeczy. Po pierwsze, należy przeprowadzić poziom testowania, aby upewnić się, że nie występują żadne przeszkody, jeśli uważasz, że możesz udostępnić wersję kompilacji klientowi ...

Wydaje się, że można wysłać . Hm Hmmm. Zastanów się nad dodaniem jednego lub dwóch składników Lean do koktajlu Agile. Mam na myśli, że jeśli nie jest to potrzeba klienta / rynku, oznacza to jedynie marnotrawstwo (testowania) zasobów.

Po pierwsze, nie widzę nic przestępczego w traktowaniu wydania Sprint jako tylko punktu kontrolnego, który zadowala zespół.

  • dev: tak, że wygląda się wystarczająco dobrze, aby przejść do testerów; QA: tak, wygląda to wystarczająco dobrze, jeśli potrzebne są dalsze testy wysyłkowe - takie rzeczy. Zespół (dev + QA) jest zadowolony, to wszystko.

... Najważniejszym punktem, który podałeś, był koniec odpowiedzi w zakresie niestosowania zwinności, jeśli wymagania nie są zwinne. Myślę, że to jest na miejscu. Kiedy zaczęliśmy działać zwinnie, mieliśmy to ustawione, a okoliczności miały sens. Ale od tego czasu wszystko zmieniło się dramatycznie i trzymamy się procesu, w którym może to już nie mieć sensu.

Dokładnie tak. Również z tego, co opisujesz, wygląda to tak, jakbyś osiągnął stan (dojrzałość zespołu / kierownictwa i relacje z klientem), co pozwala ci używać regularnego iteracyjnego rozwoju modelu zamiast Scruma. Jeśli tak, to możesz również wiedzieć, że z mojego doświadczenia wynika, że ​​takie regularne iteracje wydawały się bardziej produktywne niż Scrum. Znacznie bardziej produktywny - po prostu było o wiele mniej kosztów ogólnych, po prostu o wiele łatwiej było skupić się na rozwoju (dla QA odpowiednio skupić się na testowaniu).

  • Zwykle myślę o tym w kategoriach Ferrari (jako zwykła iteracja) vs Landrover (jako Scrum).
     
    Podczas jazdy autostradą (a wydaje się, że twój projekt dotarł do tej autostrady ) Ferrari pokonuje Landrovera.
     
    Jest to teren, na którym trzeba jeepa, a nie samochodu sportowego - to znaczy, jeśli twoje wymagania są nieregularne i / lub jeśli praca zespołowa i zarządzanie nie są tak dobre, musisz wybrać Scrum - po prostu dlatego, że próbujesz jeździć regularnie utknął - jak Ferrari utknie w terenie.

Nasz pełny produkt składa się z wielu mniejszych części, z których wszystkie mogą być ulepszane niezależnie. Myślę, że nasi klienci bardzo chętnie aktualizują te mniejsze komponenty znacznie częściej. Wydaje mi się, że powinniśmy być może skupić się na wydaniu i kontroli jakości tych mniejszych komponentów na końcu sprintu ...

Powyżej brzmi jak dobry plan. Raz pracowałam w takim projekcie. Wydawaliśmy comiesięczne wersje z aktualizacjami zlokalizowanymi w małych komponentach niskiego ryzyka, a podpisywanie ich pod kątem jakości było tak proste, jak to tylko możliwe.

  • Jedną rzeczą, aby pamiętać o tej strategii jest stworzenie dającej się przetestować weryfikację, czy zmiana jest zlokalizowana gdzie oczekiwano. Nawet jeśli dojdzie do porównania plików po kawałku dla składników, które się nie zmieniły, idź, bo inaczej nie dostaniesz go dostarczony. Rzecz w tym, że to QA odpowiada za jakość wydania, a nie my, programiści.
     
    Problemem głowy testera jest upewnienie się, że nieoczekiwane zmiany nie prześlizgną się - ponieważ szczerze mówiąc, jako programista mam wystarczająco dużo innych rzeczy, aby się tym martwić, jest to dla mnie ważniejsze. Z tego powodu oni (testerzy) naprawdę naprawdę potrzebują solidnego dowodu, że wszystko jest pod kontrolą dzięki wydaniu, które testują do wysłania.
komar
źródło
1
Myślę, że jest to prawdopodobnie najlepsza odpowiedź w świetle naszej obecnej sytuacji. Dla mnie jedną z najważniejszych części Agile jest możliwość wydania na końcu każdego sprintu. To sugeruje kilka rzeczy. Po pierwsze, należy przeprowadzić poziom testowania, aby upewnić się, że nie występują żadne przeszkody, jeśli uważasz, że możesz udostępnić wersję kompilacji klientowi. Po drugie, zakładając, że pierwsze stwierdzenie jest prawdziwe, czy możliwe jest, że kontrola jakości powiela wiele pracy, która powinna była zostać wykonana już podczas opracowywania? Myślę, że prawdopodobnie jest coś do rozwiązania, zarówno w naszym zespole ds. Kontroli jakości, jak i w zespole programistów (jestem programistą).
David Hosier
Jednak nie przypominam sobie, abyśmy po wydaniu sprintu udostępniali klientowi kompilację. Co więcej, nasza baza klientów nie chce tak często pełnej wersji produktu. Nasi klienci powoli się aktualizują. Najważniejszym punktem, który podałeś, było zakończenie odpowiedzi pod względem niestosowania zwinności, jeśli wymagania nie są zwinne. Myślę, że to jest na miejscu. Kiedy zaczęliśmy działać zwinnie, kazano nam to ustawić, a okoliczności miały sens. Ale od tego czasu wszystko zmieniło się dramatycznie i trzymamy się procesu, w którym może to już nie mieć sensu.
David Hosier
3
Nasz pełny produkt składa się z wielu mniejszych części, z których wszystkie mogą być ulepszane niezależnie. Myślę, że nasi klienci bardzo chętnie aktualizują te mniejsze komponenty znacznie częściej. Wydaje mi się, że powinniśmy raczej skoncentrować się na wydaniu i kontroli jakości tych mniejszych komponentów na końcu sprintu. Możemy skrócić pętlę sprzężenia zwrotnego dzięki bardziej ukierunkowanemu podejściu i szybciej dostarczać wartość klientom. W pewnym momencie moglibyśmy zrobić pełną wersję produktu, która podsumowuje wszystkie mniejsze elementy. Wtedy QA ma mniej do zrobienia, ponieważ większość została już sprawdzona w poprzednich sprintach.
David Hosier
1
+1 Lubię twoje przykłady różnych potrzeb rynkowych. Można podać bardziej skrajne przykłady. Np. Oprogramowanie kontrolera do zarządzania rakietami kosmicznymi. Klient może być zadowolony z aktualizacji co pięć lat (prawa fizyki niewiele się zmieniają), ale tylko jeden błąd regresji może kosztować setki milionów dolarów .
MarkJ
14

Och, czuję twój ból. Aby to zadziałało, musisz wprowadzić kilka poważnych zmian w zespole kontroli jakości.

Radzę podzielić zespół na trzy zespoły:

Testowanie funkcji - szybki zwrot z testowania nowych rozwiązań.

Testy regresji - W pełni przetestuj produkt, zanim wyjdzie on z domu. Nie powinno to zająć 3 miesięcy, nawet po zmniejszeniu liczebności drużyny, ponieważ większość błędów znajdzie pierwszy zespół.

Testy automatyczne - pisanie pełnego zestawu testów regresji w celu przyspieszenia pracy zespołu testującego regresję.

Trzecia drużyna to bonus, ale jeśli nie możesz mieć dwóch pierwszych drużyn, równie dobrze możesz być wodospadem.

pdr
źródło
+1 zautomatyzowane testowanie - testy regresji są głównym kandydatem.
Joshua Davis
Myślę, że to bardzo dobra odpowiedź. Nie jestem do końca świadomy tego, jak zorganizowany jest zespół ds. Kontroli jakości i jak przeprowadzają testy. Nasz zespół ds. Kontroli jakości znajduje się w Indiach, co moim zdaniem nie jest nieznaczącą częścią problemu. Z tego, co rozumiem, ich plany testów nie są publikowane, aby każdy mógł je przejrzeć i zweryfikować. Co więcej, ze względu na różnicę czasu, zmiana czasu pomiędzy programistami a kontrolą jakości jest okropna. To, co powinno zająć godzinę rozmowy przy czyimś biurku, zamienia się w dni e-maili lub komentarzy JIRA.
David Hosier
13

Tytułem ilustracji:

wprowadź opis zdjęcia tutaj

Pamiętaj, że Twój zespół kontroli jakości prawdopodobnie pracuje poza kręgiem (ATDD), a ty pracujesz w nim.

Myślę, że takie działanie jest w porządku; jeśli możesz udowodnić w swoich automatycznych testach, że spełniasz wymagania klienta na każdym sprincie, możesz zezwolić QA na wykonanie ich testów w czasie wolnym i przyjść do ciebie z wadami, które możesz następnie przepracować do następnego sprintu.

Robert Harvey
źródło
2
Problem polega na tym, że otrzymujesz raporty defektów z pracy wykonanej 4-6 sprintu temu (zakładając 2-3 tygodniowe sprinty). W zależności od zasad i procedur kontroli jakości firmy może być konieczne wylogowanie się przed sprintem, zanim zostanie on udostępniony klientowi. Tak, masz potencjalnie produkty do wysyłki po każdym sprincie, ale mniej niż 25% z nich trafi na kontrolę jakości (zakładając, że po zakończeniu testowania jednego kandydata, zaczną testować ostatniego kandydata), abyś mógł pokazać klientowi produkt co kilka tygodni, ale mogą dostać tylko raz na 12 tygodni i będzie starszy niż to, co właśnie zobaczyli.
Thomas Owens
Dobrze. Właśnie rozmawiałem o tym z kolegą. Powiedziałbym, że tak naprawdę nie robiliśmy odpowiednich wydań pod koniec każdego sprintu. Wykonujemy kompilację na końcu każdego sprintu, ponieważ Agile twierdzi, że powinieneś to zrobić, ale nie mamy zamiaru, aby ktokolwiek widział tę kompilację. Nie wiem, czy QA otrzyma te kompilacje, czy nie, ale zapewniam, że żaden klient nigdy nie zobaczy kompilacji po zakończeniu sprintu. Tylko jedna wersja jest potencjalnie oficjalna i to ta z ostatniego sprintu. Moim zdaniem to wcale nie jest Zwinne. Przy takim przepływie pracy Agile jest tylko sposobem organizowania pracy.
David Hosier
Co więcej, nie przypominam sobie, aby kiedykolwiek otrzymywałem informacje zwrotne od kontroli jakości aż do kompilacji z ostatniego sprintu, jak wspomniałem powyżej. To potwierdza twój punkt. Moim zdaniem może to prowadzić do sytuacji, w których decyzje podejmowane podczas sprintu 1 okażą się błędnymi decyzjami, ale ta błędna decyzja nie zostanie w pełni zrealizowana, dopóki wszystkie kolejne prace nie zostaną wykonane oprócz tej błędnej decyzji. To oczywiście może prowadzić do ogromnej liczby przeróbek.
David Hosier
8

Wygląda na to, że masz problem z definicją ukończenia.

Biorąc pod uwagę, że twoja grupa ds. Kontroli jakości ma charakter zewnętrzny i bierze udział wyłącznie w wersjach wydawanych przez klientów, nie możesz na nich polegać w celu uzyskania terminowej informacji zwrotnej na temat problemów. Oznacza to, że jeśli chcesz uzyskać szybką informację zwrotną, będziesz musiał przeprowadzić pewien test „na miejscu” dla zespołu.

Traktuj grupę QA tak, jakby nie istniała. Działaj, jeśli Twoja wersja pod koniec sprintu zostanie wdrożona w Twoim najbardziej krytycznym środowisku następnego dnia. Oprogramowanie nie jest gotowe, dopóki nie będzie gotowe, aby przejść do klientów.

Kontrola jakości nie powinna niczego znaleźć.

Będzie trudniej się do niego dostać. Prawdopodobnie będziesz miał kilka rzeczy, które przekradną się przez kilka pierwszych razy. Zautomatyzowani testy akceptacyjne i testy „regresji” są tutaj twoimi najlepszymi przyjaciółmi. TDD pomoże ci zbudować duże części takich pakietów. Powinieneś być w stanie szybko wiedzieć, czy coś zepsułeś.

Sean McMillan
źródło
3

Czy masz przedstawiciela klienta / właściciela produktu, który może zobaczyć dane wydanie przed przeprowadzeniem kontroli jakości i dać ci autorytatywną opinię? Jeśli tak, możesz wykonywać zwinne metody i czerpać z nich większość korzyści, traktując kontrolę jakości jako drugorzędne, nieco powolne źródło informacji zwrotnej. Wydanie będzie „oficjalnie gotowe” dopiero po zakończeniu kontroli jakości, ale nie będziesz musiał czekać na nie przed rozpoczęciem następnego.

Ale jeśli zasady firmy mówią, że klient nie może zobaczyć wydania przed przeprowadzeniem kontroli jakości, możesz prawie zapomnieć o zwinności, dopóki nie zmienisz tych reguł.

Michael Borgwardt
źródło
3

Opisany proces nie jest procesem zwinnym. Zespoły, które mają wysoki stopień zwinności, są w stanie dostarczać niezawodne i możliwe do uwolnienia kompilacje podczas każdego sprintu. W większości sprawnych implementacji funkcja zapewniania jakości jest wbudowana w sprawny zespół, pomagając osiągnąć ten cel.

Jeśli Ty, lider projektu, właściciel produktu i programiści nie współpracujecie i nie macie planu usprawnień (retrospektywy), nazwijcie swój proces czymś innym i przejdźcie dalej. Nie wydaje się, że problemy twoich zespołów są z winy menedżerów lub kontroli jakości. Wydaje się, że reagują na jakiś problem systemowy wychodzący z organizacji rozwoju. Nie wszystko stracone, jeśli zespół jest gotowy wziąć na siebie odpowiedzialność i rozpocząć współpracę z interesariuszami.

Możesz spróbować trzech rzeczy. Po pierwsze, upewnij się, że każdy interesariusz ma zwięźle określone role i że każda osoba rozumie swoją odpowiedzialność. Po drugie, ustabilizuj kompilację, a następnie wyloguj się z kontroli jakości bez wprowadzania dalszych zmian. Po trzecie, instytut automatyzacji testów. Zespół QA pokocha cię za to.

GuyR
źródło
Masz 100% racji. Twoje trzy elementy są dobrą radą. Mogę wpłynąć tylko na tak wiele zmian, jak pojedynczy programista, ale mogę spróbować dać przykład i sprawdzić, czy niektórzy pracownicy kontroli jakości chcą przyjść na przejażdżkę. Moją największą frustracją jest to, że nikomu to naprawdę nie obchodzi, co oczywiście stanowi ogromną barierę dla wymaganego udanego zwrotu. Większość osób w zespole jest zadowolona z kontynuacji obecnego stanu rzeczy; przynajmniej tak mam wrażenie.
David Hosier
2

Szkoda, że ​​sprzężenie zwrotne trwa tak długo, ale nie sądzę, aby warto było zwinąć. Pod koniec sprintu (lub kilku) wypuszczasz produkt, który jesteś pewien, że może zostać wprowadzony na rynek. Dla twojego zespołu zwinność zapewnia możliwość skupienia się na pracy do wykonania i utrzymania produktu w stanie gotowości do wydania. Gdy QA znajdzie problemy, sugeruję, aby utworzyć raporty błędów dla tych problemów i rozwiązać je w następnym sprincie (jeśli mają wystarczająco wysoki priorytet).

Nasze testy w terenie trwają 8 tygodni, a ponadto jesteśmy zależni od zewnętrznych producentów. Mimo to, działając zwinnie, jesteśmy w stanie skupić się na pracy i szybko stworzyć nową wersję, gdy zajdzie taka potrzeba.

Problem leży (w twoich oczach) w dziale kontroli jakości. Czy można tam rozwiązać problem? Omówiłeś to?

refro
źródło
Twoja odpowiedź wywołała dobrą rozmowę między kolegą a mną. Główny punkt Twojej odpowiedzi, który mnie przykuł, brzmiał: „Pod koniec sprintu (lub kilku) wypuszczasz produkt, którego jesteś pewien, że można go wprowadzić na rynek”. Nigdy nie przypominam sobie wypuszczania produktu na koniec sprintu, dopóki nie ukończyliśmy całej serii sprintów, przeszedł kontrolę jakości i mieliśmy kilka rund naprawiania błędów. Pod tym względem uważam, że używamy Agile jedynie jako sposobu na zerwanie i uporządkowanie naszego obciążenia pracą i nic więcej. Naprawdę nie czerpiemy żadnych korzyści z Agile.
David Hosier
@David: Zgadzam się z tobą.
Christopher Mahan
1

12 tygodni jest długie, ale mam nadzieję, że w tym czasie QA może dostarczyć informacji zwrotnych i raportów o błędach (a nie po trzech miesiącach).

Dzięki temu nadal możesz reagować na najważniejsze problemy w zwinny sposób i możesz naprawić wiele, jeśli nie wszystkie, zanim jeszcze skończą!

Hugo
źródło
-2

Co robią ludzie odpowiedzialni za kontrolę jakości podczas wykonywania wielu sprintu? Wygląda na to, że czują potrzebę przetestowania wszystkiego po każdej zmianie (dlatego czekają na całą masę zmian).

Zespół programistów jest sprawny, ale reszta firmy nie.

Ktokolwiek jest odpowiedzialny za kontrolę jakości, albo nie wie, co robi, albo wykonał sztuczkę umysłu Jedi na wyższym kierownictwie i wolno mu poświęcić słodki czas. Jak kontrola jakości może trwać dłużej niż programowanie?

JeffO
źródło