Rentowność zespołu programistów bez * dedykowanej * roli testera [zamknięte]

9

Ostatnio dużo myślałem o tym, jak zbudować szczupły zespół programistów. Ostatecznie chciałbym otworzyć własny mały program z małą liczbą podobnie myślących ludzi. Celem nie będzie stać się bogatym, ale raczej zdrowe środowisko pracy.

Do tej pory definiuję szczupły zespół jako:

  • Mały;
  • Samoorganizujący się;
  • Wszyscy członkowie muszą mieć na uwadze kontrolę jakości;
  • Członkowie muszą mieć możliwość wykonywania wielu ról

Ostatni punkt dotyczy mnie trochę, bo jak mówi mantra ...

Programiści tworzą złych testerów.

Chociaż rozumiem, że często programiści są „zbyt blisko” swojego kodu lub kodu współpracownika, aby dokonywać oceny jakości na wyższym poziomie, nie jestem przekonany, że są de facto złymi testerami. Przeciwnie, uważam, że cechy dobrego programisty w dużym stopniu pokrywają się z cechami dobrego testera.

Zakładając, że jest to poprawne, myślałem o różnych sposobach obejścia problemu dewelopera / testera i wierzę, że wymyśliłem realny model.

Mój model wymaga:

  • Mały dom oprogramowania z ponad 2 projektami
  • Zwinne (iteracyjne) podejście do rozwoju i dostarczania
  • 1 zespół na projekt
  • Wszyscy członkowie zespołu będą programistami
    • Ich opis stanowiska wyraźnie określa obowiązki w zakresie rozwoju , zapewnienia jakości , testowania i dostawy

Jeśli wszystkie te warunki wstępne zostaną spełnione, projekty można zorganizować w następujący sposób (ten przykład będzie dotyczył dwóch projektów A i B ):

  • Każdy członek zespołu będzie na przemian między rolą programisty a rolą testera
  • Jeśli członek zespołu jest programistą w projekcie A , będzie testerem w projekcie B.
    • Uczestnicy będą pracować tylko na 1 projektu w czasie, a zatem oczekuje się, że działa jako jednej z Dev lub Tester.
  • Cyklu Rola składa się z 3 powtórzeń jako Dev i 2 iteracji Tester (ponownie, w dwóch różnych projektów)
  • Zespoły projektowe miałyby zawsze 3 deweloperów i 2 testerów.
  • Cykle roli członka powinny być poza fazą o 1 iterację.
    • Minimalizuje to nagłe zmiany w zespole. Dla każdej iteracji 2 Devs i 1 Tester pozostaną takie same jak poprzednia iteracja.

Biorąc pod uwagę powyższe, widzę następujące zalety i wady:

Plusy

  • Dystrybuuje wiedzę projektową w całej firmie.
  • Zapewnia, że ​​członkowie zespołu nie testują kodu, który pomogli napisać.
  • Cykle ról poza fazą oznaczają, że żaden projekt nigdy nie ma przełącznika członka w 100%.
  • Naprzemienne role przerywają monotonię nudnych projektów.

Cons

  • Iteracje obu projektów są ściśle powiązane. Jeśli jeden projekt miałby anulować iterację w połowie i rozpocząć od nowa, oba projekty nie byłyby zsynchronizowane. Utrudniłoby to zarządzanie cyklem ról.
  • Zależy od zatrudniania Deweloperzy również pracują jako testerzy.

Otrzymałem mieszane recenzje podczas omawiania tego podejścia z przyjaciółmi i współpracownikami. Niektórzy uważają, że niewielu programistów kiedykolwiek chciałoby zmieniać takie role, podczas gdy inni twierdzą, że osobiście chcieliby spróbować.

Więc moje pytanie brzmi: czy taki model mógłby działać w praktyce? Jeśli nie, to czy można go ulepszyć w działający model?

Uwaga: Ze względu na zwięzłość skupiłem się tylko na rolach deweloperów i testerów. W razie potrzeby rozwinę inne role.

MetaFight
źródło
Chociaż nakładają się na siebie, czy Deweloperzy mogą lub powinni być testerami, myślę, że sedno tego pytania dotyczy roli poza fazą 2 w modelu 2 projektów.
MetaFight
2
FWIW moja osobista opinia jest taka, że ​​ryzykujesz dość dużo z takim podejściem. Jestem byłym testerem (i nie najgorszym) i kiedy raz wylądowałem w projekcie, w którym mogłem „przeplatać” 2 role, po raz pierwszy pomyślałem, wow, szansa, aby wymyślić, jak zrobić to dobrze. Po około pół roku zmieniłem zdanie i nigdy więcej nie chcę tego próbować. Obie role (deweloper i kontrola jakości) wymagają 100% koncentracji, aby zrobić to dobrze, ale kiedy się przeplatasz, odwracasz uwagę i tracisz jakość, wydajność lub jedno i drugie. BTW oddanie się testerowi w tym projekcie przyniosło najbardziej imponujący zwrot z inwestycji, jaki kiedykolwiek byłem świadkiem
gnat
2
@gnat, ale nie wyjaśniłeś, dlaczego programista nie mógł pełnić roli testera. To prawda, że ​​dana osoba będzie musiała potraktować ją poważnie jako pełnoetatową rolę, dlatego zasugerowałem, że naprzemiennie realizują projekty i pracują tylko nad jednym projektem na raz. Nie oczekuję, że jakiś programista będzie w stanie to zrobić ... tylko ci, którzy zrobiliby dobrych testerów, gdyby wybrali tę ścieżkę.
MetaFight
2
Parafrazując to, co chcesz zrobić: „Chcę otworzyć operację medyczną, zamiast zatrudniać kilku anestezjologów, zatrudniam wystarczającą liczbę chirurgów i obracam ich do tej roli”. Twoja propozycja pokazuje (typowy) brak zrozumienia tego, co profesjonalny tester oferuje zespołowi. Możesz to zrobić, wielu tak, niektórzy sprawiają, że działa. To, czego nigdy nie będziesz wiedzieć, to to, czego przegapiłeś i co możesz robić lepiej. Nawiasem mówiąc - Testowanie to nie jakość - tylko jedna lekcja, której nauczy Cię profesjonalny tester.
mattnz

Odpowiedzi:

8

Nie zgadzam się z

Programiści tworzą złych testerów

Większość zespołów, nad którymi pracowałem w swojej karierze, nie otrzymała wsparcia w zakresie kontroli jakości. Obejmuje to kilka dużych globalnych korporacji obejmujących produkty takie jak ich globalny system logowania i rejestracji. W innym przypadku 30% przychodów firmy przeszło przez skrzynkę na biurku. (Te praktyki nie są zalecane BTW;)) Firmy te polegały na inżynierach, aby upewnić się, że ich kod działa poprawnie. A my, będąc zorientowani na szczegóły, trochę kompulsywni i dumni z naszej pracy, dokładamy wszelkich starań, aby nasze oprogramowanie działało poprawnie.

Jako programista wykonuję znacznie więcej testów niż testerzy. Rutynowo testuję mój kod do 90% lub 100%, jeśli nie pracuję z Javą.

Lubię pracować z Testerami, ponieważ przychodzą na to z innej perspektywy i łapią rzeczy, o których nie myślałem. Ale tak naprawdę nie liczę na to, że zapewnią więcej niż około 30-50% pokrycia testowego, a ja odpowiadam za 100%. (BTW, to nie jest ich trzask - zwykle są rozrzucone na różne projekty).

Zamiast zapytać inżynierów w wywiadach, czy chcą przeprowadzić kontrolę jakości, zapytaj: jeśli w produkcji pojawi się błąd, kto jest odpowiedzialny? Jeśli przedstawię błąd, a klient go doświadczy, źle się czuję i biorę odpowiedzialność. Nie winię facetów z QA. IMHO To inżynier, którego chcesz zatrudnić (i pracować)

Moja metoda zapewniania jakości to: a) bardzo agresywne testowanie jednostkowe (chociaż nie mogę do końca zmusić się do pełnego rozwoju opartego na testach), b) silny proces przeglądu kodu naprawdę pomaga, oraz c) integrowanie nietolerancji i niecierpliwości z wady w kulturze zespołu.

Zawsze wydawało mi się, że to starsi ludzie byli najbardziej pracowici i uważni nawet na drobne problemy, ponieważ mogli wskazywać na większy problem. Ale przede wszystkim to oni byli najchętniej poświęcać czas, aby zrobić to dobrze.

Ale większość zespołów, nad którymi pracowałem, szczególnie dla małych firm, nie miała formalnego komponentu kontroli jakości.

Obrabować
źródło
6

Zgadzam się z odpowiedzią @Rob Y i chciałbym dodać kilka punktów:

  • W zwinnym, oddani testerzy w zespole są anty-wzorcem, ponieważ zmuszają zespoły do ​​pracy nad rurociągiem i są z natury nieefektywne. Ciągle kończysz na historiach, które są „opracowane”, ale nie są testowane. Dedykowani testerzy są w porządku, jeśli pracują poza zespołem (lub oddzielnym zespołem).

  • Twórcy tworzą złych testerów ... a testerzy robią złych testerów. Kontrola jakości jest trudna. W rzeczywistości jest to bardzo trudne. Twoim problemem mogą nie być ludzie i role. Twój problem może polegać na tym, że twoje oprogramowanie zostało wyrzucone. Ponownie, w trybie zwinnym, twój zespół jest odpowiedzialny za testowanie przed produkcją (niezależnie od tego, czy mają dedykowaną kontrolę jakości, czy nie).

  • Kontrola jakości jest częścią rozwoju, np. Refaktoryzacji, architektury itp. Zadaniem zespołu programistów jest wytwarzanie oprogramowania o określonym, uzgodnionym, realistycznym standardzie. Kontrola jakości nie poprawi tego standardu. Lepsi programiści prawdopodobnie to zrobią.

  • Prowokacja: Kto mówi, że QA są lepsze niż deweloperzy w QA-ing? Ludzie to mówią, ale ... [potrzebne źródło]. Potrzebna mentalność „hakera” zapewniania jakości to mentalność programisty. W rzeczywistości wszyscy hakerzy są lub byli programistami, a nie QA ...

  • Prowokacja 2: 99% pracy związanej z kontrolą jakości można (i ośmielę się powiedzieć, że powinno ) być zautomatyzowane za pomocą skryptów. Dobry zespół to zrobi, a aby zrobić to poprawnie, potrzebujesz ... programistów.

Sklivvz
źródło
Komentowanie Provocation 2: programiści mogą przeprowadzić automatyzację testów, ale niekoniecznie. Testerzy, którzy potrafią pisać (ale nie na poziomie profesjonalnego programisty), potrafią pisać wystarczająco dobre skrypty.
Mate Mrše
4

W poprzednim zadaniu mieliśmy tylko programistów i nie mieliśmy personelu ds. Kontroli jakości. W rezultacie nie było nikogo innego, kogo można by obwinić, jeśli problem przejdzie do produkcji. Bardzo poważnie podeszliśmy do obowiązków związanych z kontrolą jakości i polegaliśmy w dużej mierze na zautomatyzowanych pakietach testowych. Ponieważ pisanie automatycznych testów wciąż jest kodowane, nie było wielkim problemem, aby zachęcić programistów do zrobienia tego.

Kluczową sprawą jest uczynienie go częścią kultury zespołu i częścią każdego projektu. Napisaliśmy plany testów (krótkie listy testów, które zamierzaliśmy napisać dla projektu), a inni programiści sprawdzili i zasugerowali przypadki i scenariusze, które przeoczyliśmy.

Jeśli jesteś wobec tego rygorystyczny, może działać bardzo dobrze. Zrobiło to dla nas - mieliśmy doskonały czas pracy i niskie wady w stale dostępnym serwisie internetowym e-commerce.

Rory Hunter
źródło
ten post jest raczej trudny do odczytania (ściana tekstu). Czy mógłbyś edytować go w lepszym kształcie?
komar
2
Przepraszam, poranny zrzut mózgu. Zerwałem to teraz.
Rory Hunter
2

Najpierw zastrzeżenie - pracowałem zawodowo zarówno jako inżynier ds. Kontroli jakości, jak i inżynier oprogramowania.

Czy taki model mógłby działać w praktyce?

Wszystko jest możliwe.

Chociaż rozumiem, że często programiści są „zbyt blisko” swojego kodu lub kodu współpracownika, aby dokonywać oceny jakości na wyższym poziomie, nie jestem przekonany, że są de facto złymi testerami. Przeciwnie, uważam, że cechy dobrego programisty w dużym stopniu pokrywają się z cechami dobrego testera.

To zależy od tego, jakiego rodzaju testów potrzebujesz. Jeśli potrzebujesz odrętwiających, monotonnych, powtarzalnych testów ręcznych, aby upewnić się, że każdy ekran lub element naprawdę został przetłumaczony na język Elbonian ... będziesz mieć problemy.

Z mojego doświadczenia wynika, że każdy projekt wymaga co najmniej trochę tego rodzaju testów (nawet jeśli nie każdy projekt przeprowadzał tego rodzaju testy). Problem polega na tym, że nie dostajesz tego rodzaju testów od osób niezaznajomionych z najlepszymi praktykami kontroli jakości. Do diabła, nie dostajesz go nawet od ludzi, którzy znają najlepsze praktyki, ale „ufają” programistom.

Jako tester nie możesz ufać programistom. Straciłem liczbę znalezionych błędów, które „nie mogły być spowodowane tą zmianą” lub „działają doskonale na moim urządzeniu deweloperskim”.

Nawet jeśli znajdziesz programistów, którzy będą tolerować nie robienie tego, co lubią robić 2 tygodnie na 5, również spotkasz się z tą podstawową sprzecznością. Co gorsza, spędzasz czas i energię, aby szkolić ludzi, aby byli dobrzy w dwóch miejscach pracy zamiast w jednym. Firmy mają dość czasu na znalezienie i przeszkolenie ludzi w jednej pracy, a co dopiero w dwóch.

Może jesteś niesamowity w jakiś sposób, którego jeszcze nie spotkałem - ale wątpię w to.

Telastyn
źródło
Być może mój model potrzebuje roli Sr QA do przeglądu proponowanych podejść moich programistów i do zalecania najlepszych praktyk. Och, i większość ludzi nie uważa mnie za świetnego, ale moja mama ma :) i to mi wystarczy!
MetaFight
Przekształcam niektóre z naszych ról kontroli jakości w właścicieli produktów. Wygląda na to, że nie akceptujesz historii użytkowników ani recenzji sprintu przez właściciela produktu. Oba z nich złapią wiele problemów, które zespół programistów mógł przegapić. Wcześniej jednak, jeśli nie możesz ufać programistom w kwestii jakości, musisz znaleźć różnych programistów. Taki jest mój wniosek - z mojego doświadczenia - nie można wyszkolić złej jakości od złego programisty. Pracowałem z wieloma programistami „załatw sprawę”, a to jest wynik, który otrzymujesz od nich. Dobry zespół scrumowy wymaga dobrych programistów.
David Anderson,
0

Myślę, że to może zadziałać, ale jest kilka rzeczy, które powinienem upewnić.

  1. Bądź bardzo otwarty na temat podwójnej roli kandydatów. To nie jest dla wszystkich z wielu powodów. Jeśli masz zbyt wielu ludzi, którzy tego nie lubią, będziesz mieć porażkę i obrót.
  2. Przygotuj plan, w którym możesz ocenić najlepszy sposób włączenia tego w zespół. Chociaż lubię skupiać się na jednym zadaniu / projekcie na raz, nie jestem pewien, czy nie chciałbym programować przez bardzo długi czas. Może testowanie to miłe wakacje z dala od programowania. Nie jest to łatwiejsze, wystarczy użyć różnych komórek mózgowych dla odmiany. Przygotuj się na wypróbowanie go na różne sposoby, zanim zdecydujesz, co jest najlepsze.

Synchronizacja projektów nie wydaje się praktycznym rozwiązaniem. Jeśli ktoś jest testerem w projekcie, może być najlepszym kandydatem do zastąpienia programisty i odwrotnie.

Ten plan nie pozwala zespołom wystarczająco się samoorganizować. Jedna strategia prawdopodobnie nie pasuje do wszystkich zespołów i wszystkich projektów.

JeffO
źródło
Rola Testera w tym przypadku prawdopodobnie obejmowałaby testowanie ręczne i automatyczne. Spodziewałbym się, że programiści będą pisać testy jednostkowe i integracyjne, ale testerzy zrobiliby to samo. Miejmy nadzieję, że dokładny podział pisania kodowanego testu będzie naturalną równowagą osiągniętą po kilku iteracjach.
MetaFight
Naprawdę nie powinno to nawet oznaczać, czy kandydaci są gotowi do odgrywania podwójnych ról, czy nie. Jeśli chcesz prowadzić odnoszącą sukcesy firmę, powinieneś postawić ludzi tam, gdzie się wyróżniają. Po co testować faceta, który potrafi samodzielnie zaprojektować i zakodować 2 niezawodne systemy, skoro zespół 4 lub 5 zajmuje się tworzeniem jednego systemu w tym samym czasie? Podobnie, testowanie ma swoje umiejętności, aby móc to zrobić dobrze. Największe postępy w ludzkiej cywilizacji nastąpiły, gdy ludzie zaczęli się specjalizować. Dlaczego prowadzenie firmy programistycznej różni się od tego, co matka natura już udowodniła, że ​​działa najlepiej?
Dunk