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

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.

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.

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.

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.

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.

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.