Za dużo kontroli wersji i narzutów związanych ze śledzeniem błędów na zmianę?

Pracuję w miejscu, które jest szalone z CVS i szalone z Bugzilli.

1. W każdym wydaniu jest tyle gałęzi, że nie można ich policzyć. Wszyscy ciągle się scalają.

2. W tej pracy nie ma płynności . Wszystko wydaje się być krok po kroku . Zajmuje 25 kroków nawet dla prostej sprawy. To nie jest tak, jak na fabrycznej linii produkcyjnej: to tak, jakby codziennie zakładać fabrykę.

Przykładowa sytuacja:

Aby naprawić pojedynczy błąd, najpierw otrzymuję czystą, nową maszynę wirtualną. Następnie tworzę gałąź dla tej pojedynczej poprawki błędu, na podstawie innej gałęzi opisanej w raporcie Bugzilli. Instaluję gałąź na komputerze, konfiguruję ją. Naprawiam błąd. Sprawdzam to, zostawiając to i maszynę do przetestowania przez innych. Następnie muszę przejść do oprogramowania do kontroli błędów i wyjaśnić, co zrobiłem, i napisać test, wykonując wszystkie kroki. W końcu ktoś inny połączy to z wydaniem.

Bez względu na to, jak malutki jest błąd, muszę robić wszystkie te rzeczy. Czasami ludzie łączą pracę nad wieloma błędami, ale jak powiedziałem, istnieje tak wiele gałęzi, że jest to prawie niemożliwe.

Przy każdej innej pracy po prostu wchodzę i naprawiam błąd. Prawie nawet nie pamiętam korzystania z SCM, chociaż każda praca, z której korzystałem, korzystała z niej: to dlatego, że przy każdej innej pracy w jakiś sposób trzymały ją z dala .

Czy istnieje punkt, w którym proces staje na przeszkodzie i staje się celem samym w sobie? Czy to w ogóle inżynieria?

Czy istnieje punkt, w którym proces staje na przeszkodzie i staje się celem samym w sobie?

Niestety ciężkie procesy są powszechne. Niektórzy ludzie - zwłaszcza kierownictwo - wyobrażają sobie religijnie, że procesy wytwarzają produkty. Przesadzają więc procesy i zapominają, że to naprawdę garstka pracowitych, inteligentnych ludzi, którzy faktycznie tworzą produkty. Dla wyższej kadry kierowniczej przerażające jest nawet myślenie, że ich interesy są w rękach niewielu maniaków, a więc zamykają oczy na rzeczywistość i myślą o swoim drogim „procesie”, co daje im złudzenie kontroli.

Dlatego sprawne startupy z garstką dobrych inżynierów mogą pokonać duże, ugruntowane korporacje, których pracownicy spędzają 95% energii na przetwarzaniu i raportowaniu. Kilka przykładów niegdyś małych startupów, które kiedyś pokonały konkurentów i / lub stworzyły zupełnie nowe rynki:

• Apple (Apple I został stworzony przez 1 inżyniera; wtedy w firmie było 3 mężczyzn).
• Google (utworzony pierwotnie przez 2 programistów).
• Facebook ( pierwotnie 1- osobowy wysiłek).
• Microsoft ( 2 -man spółka w 1975 roku).

Można z łatwością powiedzieć, że są to tylko wartości odstające, skrajne wyjątki, a żeby zrobić coś poważnego, lepiej być dużą, ugruntowaną korporacją. Ale lista jest długa. I dalej Jest krępująco długie. Prawie każda dziś ważna korporacja zaczynała jako sklep garażowy, który robił coś niezwykłego. Coś dziwnego. Robili to źle. Myślisz, że robili to zgodnie z procesem?

Firmy zwykle cierpią z powodu tego, co chciałbym nazwać dylematem kontroli elastyczności. Im mniej zasad, struktur i biurokratycznych kosztów ogólnych, tym łatwiej i szybciej można osiągnąć pewne cele (jest to również więcej zabawy). Jednak równie łatwe jest robienie „złych” rzeczy, jak „dobrych”. Oznacza to, że nic ci nie jest, gdy masz wykwalifikowanych pracowników, którzy popełniają niewiele niekrytycznych błędów.

Z drugiej strony, jeśli masz dużo pracowników o niskich do średnio wykwalifikowanych pracownikach i / lub koszty popełnienia błędów są zbyt wysokie (takie jak ryzyko odpadków wahadłowca kosmicznego na półkuli północnej), firmy zwykle stosują coraz więcej „zasad” ”i„ procesy ”, aby spróbować je zminimalizować.

Jedynym problemem jest to, że skumulowane obciążenie tych procesów utrudnia osiągnięcie czegokolwiek, co spowoduje, że bardziej utalentowani pracownicy odejdą z firmy. Powoduje to, że średnia umiejętność spada jeszcze bardziej, co wymaga jeszcze większej liczby procesów i biurokracji. Tak więc spirala śmierci trwa, dopóki nie wydarzy się coś radykalnego lub firma nie upadnie.

Jeśli znajdziesz się w firmie, która wydaje się, że przekroczyła granicę braku powrotu w tym aspekcie, możesz albo zdecydować się na „nie dbanie” o swoją pracę (to, co większość pozostała, zrobiła), albo wydostać się z piekła rodem tam z nietkniętą duszą :)

Jeśli firma nie posunęła się za daleko i masz środki, możesz spróbować odwrócić kurs dzięki czystej determinacji i sile woli. Uważaj jednak, że może to wymagać ogromnej ilości pracy i osobistej energii bez gwarancji sukcesu, więc upewnij się, że warto. Czasami lepiej po prostu zmniejszyć stratę i policzyć się bogatszym doświadczeniem.

Jest tylko jeden ważny powód takiego stylu rozwoju: opracowane oprogramowanie jest absolutnie kluczowe dla misji i pod żadnym pozorem nie może zawierać żadnych błędów. Pomyśl o oprogramowaniu układowym wtrysku paliwa do silników odrzutowych w samolotach pasażerskich, oprogramowaniu stymulatora serca lub systemie wystrzeliwania pocisków jądrowych.

We wszystkich innych sytuacjach koszty ogólne zabijają firmę. Czas by iść naprzód.

To pytanie naprawdę zawiera dwa pytania, które należy rozwiązać osobno:

Dlaczego niektóre zespoły mają ścisły proces rozwoju?

Prosta odpowiedź brzmi, ponieważ jeśli nie, błędy się zdarzają. Kosztowne błędy. Dotyczy to zarówno rozwoju, jak i reszty dziedziny IT (sysadmins, DBA itp.).

Jest to bardzo trudne do zrozumienia dla wielu programistów i pracowników IT, ponieważ większość z nas pracowała tylko w jednej z „skrajności” - dużych firm w stylu Fortune z co najmniej tuzinem programistów i surowymi procedurami do spełnienia, lub małe, mikro-niezależnych dostawców oprogramowania lub nawet niezależni pracują tam, gdzie ludzie po prostu nie psują się źle, lub koszt zepsucia jest niski.

Ale jeśli kiedykolwiek widziałeś firmę między tymi fazami - nawet firmę z jasną, utalentowaną kadrą IT - zrozumiesz niebezpieczeństwo związane z brakiem procesu lub procesem połowicznym. Widzisz, komunikacja między pracownikami cierpi na problem wybuchu kombinatorycznego ; kiedy osiągniesz poziom około 6-10 programistów w jednym zespole, główną przyczyną poważnych lub krytycznych defektów nie jest brak talentu lub wiedzy, ale raczej brak komunikacji.

Alice pyta w poniedziałek rano i decyduje, że można wykonać operację rekonstrukcyjną w bagażniku, ponieważ nikt inny nie pracuje nad tą częścią. Bob przybywa godzinę później, wracając z wakacji i pełen energii, i postanawia wdrożyć nową ważną funkcję w tym samym obszarze, i po co zawracać sobie głowę oddziałem, ponieważ nikt i tak nigdy nie dotyka tego kodu? Więc Alice spłaca ten „dług techniczny”, Bob wdraża swoją funkcję zabójcy, która była na tylnym palniku przez 6 miesięcy, a kiedy w końcu oboje sprawdzają swój kod (oczywiście przed zamknięciem w piątek, oczywiście!), Cały zespół musi pozostać w tyle i próbować przetrwać koszmarne piekło konfliktów, które nadal trwają jako błędy i regresy przez następne kilka tygodni.

Alice i Bob obaj świetnie spisali się w zadaniach związanych z kodowaniem, ale obaj zaczęli od złej decyzji („co najgorszego może się zdarzyć?”). Kierownik zespołu lub kierownik projektu prowadzi ich przez sekcję zwłok i opracowuje listę kontrolną, aby zapobiec ponownemu wystąpieniu problemu:

• Zameldowanie musi odbywać się codziennie, aby zminimalizować wpływ konfliktów;
• Zmiany, które potrwają znacznie dłużej niż 1 dzień, należy wprowadzić w oddziałach;
• Wszystkie ważne zadania (w tym prace niefunkcjonalne, takie jak refaktoryzacja) muszą być odpowiednio śledzone i przypisywane w module do śledzenia błędów.

Założę się, że dla wielu z nas ten „proces” wydaje się po prostu zdrowy rozsądek. To stary kapelusz. Ale czy wiesz, że wiele mniejszych zespołów tego nie robi? Dwuosobowy zespół może nawet nie zawracać sobie głowy kontrolą źródła. Kogo to obchodzi? To naprawdę nie jest konieczne. Problemy zaczynają się pojawiać dopiero, gdy zespół rośnie, ale proces nie.

Oczywiście optymalizacja procesu jest jak optymalizacja wydajności; podąża odwrotną krzywą wykładniczą. Powyższa lista kontrolna może wyeliminować 80% defektów, ale po jej wdrożeniu okaże się, że pozostałe 80% odpowiada za pozostałe 80% defektów. W naszym fikcyjnym, ale znanym przykładzie mogą występować błędy kompilacji z powodu różnych środowisk kompilacji, co z kolei wynika z faktu, że nie ma standardowego sprzętu, a programiści używają bibliotek open source, które są aktualizowane co 2 tygodnie.

Masz więc trzy możliwości: albo (a) ujednolicić sprzęt i poważnie ograniczyć wykorzystanie bibliotek innych firm, co jest kosztowne i może znacznie zaszkodzić produktywności, lub (b) skonfigurować serwer kompilacji, który wymaga współpracy grupy sysadmin i pełnoetatowy programista, aby go utrzymać, lub (c) pozwolić programistom zrobić to samodzielnie, dystrybuując standardową maszynę wirtualną i polecając programistom, aby na tym oparli. Oczywiście (b) jest najlepszym rozwiązaniem długoterminowym, ale (c) ma lepszą równowagę między niezawodnością a celowością w perspektywie krótkoterminowej.

Cykl trwa i trwa. Każda „polityka”, którą widzisz, została wprowadzona w celu rozwiązania prawdziwego problemu. Jak pisał Joel Spolsky w 2000 roku (na zupełnie inny temat, pamiętajcie o tym, ale istotne):

Kiedy wchodzisz do restauracji i widzisz znak z napisem „Zakaz wstępu dla psów”, możesz pomyśleć, że znak ten ma charakter czysto prowokacyjny: Pan Restauracja nie lubi psów w pobliżu, więc kiedy zbudował restaurację, postawił ten znak.

Gdyby to wszystko się działo, pojawiłby się również znak „No Snakes”; w końcu nikt nie lubi węży. I znak „Brak słoni”, ponieważ łamią krzesła, kiedy siadają.

Prawdziwy powód, dla którego znak jest tam jest historyczny: to historyczny znacznik, który wskazuje, że osoby wykorzystywane do starają się doprowadzić swoje psy do restauracji.

Tak samo jest w większości (nie powiem wszystkich) zespołów programistycznych: zasady takie jak „Musisz dodać przypadek testowy dla każdej poprawki błędu” prawie zawsze wskazują, że zespół historycznie miał problemy z regresjami. Regresje to kolejny z tych problemów, które najczęściej wynikają z awarii komunikacji, a nie niekompetencji. Tak długo, jak rozumiesz zasady, możesz być w stanie przyjąć uzasadnione skróty (np. Musiałem naprawić 6 małych błędów, ale wszystkie były w tej samej funkcji, więc mogę po prostu napisać jeden przypadek testowy dla wszystkich 9).

To wyjaśnia, dlaczego procesy istnieją, ale to nie jest cała historia. Druga połowa to:

Dlaczego proces jest tak trudny do naśladowania?

To jest właściwie prostsze pytanie, na które należy odpowiedzieć: to dlatego, że zespół (lub jego kierownictwo) koncentruje się na powtarzalnych wynikach i minimalizowaniu defektów (jak wyżej), ale nie poświęcił wystarczającej uwagi optymalizacji i automatyzacji tego procesu.

Na przykład w pierwotnym pytaniu widzę kilka problemów:

• System kontroli wersji (CVS) jest dziedzictwem dzisiejszych standardów. W przypadku nowych projektów został prawie całkowicie zastąpiony przez subwersję (SVN), która sama w sobie szybko zostaje przyćmiona przez systemy rozproszone, takie jak Mercurial (Hg). Przejście na Hg sprawiłoby, że rozgałęzienie i scalenie byłyby znacznie prostsze, a nawet w moim hipotetycznym przykładzie powyżej codzienne wymaganie zatwierdzenia stałoby się o wiele mniej bolesne. Kod nawet nie musi się kompilować, ponieważ repozytorium jest lokalne; - leniwi programiści mogliby nawet zautomatyzować ten krok, gdyby chcieli, ustawiając skrypt wylogowania, aby automatycznie zatwierdzać zmiany w lokalnym repozytorium.

• Nie poświęcono czasu na automatyzację procesu maszyny wirtualnej. Cały proces uzyskiwania, konfigurowania i pobierania źródła / bibliotek na maszynę wirtualną może być w 100% zautomatyzowany. Może to być nienadzorowany proces uruchamiany gdzieś na centralnym serwerze podczas pracy nad poprawką błędu na komputerze lokalnym (i używaj tylko maszyny wirtualnej, aby zapewnić czystą kompilację).

• Z drugiej strony, na pewną skalę rozwiązanie VM-per-developer zaczyna być głupie i powinieneś mieć tylko serwer Continuous Integration. To właśnie tutaj pojawiają się rzeczywiste korzyści produktywności, ponieważ (głównie) uwalnia to indywidualnych programistów od konieczności martwienia się o kompilacje. Nie musisz się martwić konfigurowaniem czystych maszyn wirtualnych, ponieważ serwer kompilacji jest zawsze czysty.

• Sformułowanie pytania („przypadek testowy ze wszystkimi krokami”) sugeruje, że trwają testy ręczne . To znowu może działać w przypadku małych zespołów o stosunkowo niskim obciążeniu pracą, ale w ogóle nie ma sensu na większą skalę. Testy regresji można i należy zautomatyzować; nie ma „kroków”, tylko klasa lub metoda dodana do zestawu testów jednostkowych / integracyjnych.

• Nie trzeba dodawać, że przejście z Bugzilli do nowszego (lepszego) systemu śledzenia błędów sprawi, że ta część doświadczenia będzie o wiele mniej bolesna.

Firmy niekoniecznie są tanie lub głupie tylko dlatego, że nie rozwiązały tych problemów. Wiedzą tylko, że obecny proces działa , aw niektórych przypadkach są niechętni ryzyku i niechętnie zmieniają cokolwiek na ten temat. Ale tak naprawdę muszą być przekonani o korzyściach .

Jeśli programiści spędzili tydzień na śledzeniu swojego czasu we wszystkich zadaniach niekodujących, możesz łatwo go podsumować, pokaż kierownictwu, że (na przykład) inwestycja o zerowym kapitale, 100 roboczogodzin w aktualizację do Mercurial wyeliminować do 10 roboczogodzin tygodniowo przy rozwiązywaniu konfliktów scalania, to jest to 10-tygodniowa wypłata i prawie na pewno się na to zgodzą. Ten sam pomysł z serwerami kompilacji (CI) lub lepszym śledzeniem błędów.

Podsumowując: zespoły jeszcze tego nie zrobiły, ponieważ nikt nie przekonał kierownictwa, że ​​jest to wystarczająco ważne, aby zrobić to dzisiaj . Więc przejmij inicjatywę i zmień ją w równanie kosztów i korzyści; dowiedzieć się, ile czasu poświęca się na zadania, które można uprościć / zautomatyzować przy minimalnym ryzyku, i obliczyć próg rentowności i ewentualną wypłatę nowego narzędzia lub techniki. Jeśli nadal nie słuchają, to wiesz już, jakie masz pozostałe opcje.

Jeśli programiści spędzili tydzień na śledzeniu swojego czasu we wszystkich zadaniach niekodowania, możesz łatwo go dodać, pokazać zarządzanie ... i przekształcić w równanie kosztów i korzyści itp.

Powyższa część wygląda na dalszą rozbudowę.

Mogę potwierdzić, że to działa. Programiści używali go kilka razy w jednym z projektów, nad którymi pracowałem i za każdym razem doprowadzało to do pożądanych zmian.

Moje ogólne wrażenie było takie, że jeśli zrobimy to dobrze, ta sztuczka może unieważnić całkiem duże zarządzanie ignorancją i bezwładnością.

Chciałbym jednak zauważyć, że firma, w której my (programiści) musieliśmy stosować tego rodzaju podejście do majsterkowania, była bardzo niedojrzała pod względem informatycznym. U bardziej doświadczonych dostawców oprogramowania widziałem, że takie rzeczy są w większości wykonywane przez samych menedżerów. I z reguły byli bardziej wydajni niż my, programiści. Znacznie bardziej produktywny.

Jeśli pracujesz w silnie regulowanej branży, może być jakiś powód tego uciążliwego procesu: pewnego dnia możesz zostać poddany audytowi i będziesz musiał pokazać wszystkie swoje dane, aby wyjaśnić, kto naprawił ten błąd, jak, kto go sprawdził, kto przetestował itd.

Może to być zło konieczne.

Z drugiej strony, jeśli nie ma uzasadnienia dla tego procesu, poza brakiem zaufania ze strony kierownictwa, powinieneś spróbować porozmawiać z menedżerem i powiedzieć mu, jak możesz zaoszczędzić czas (a tym samym pieniądze) dla firmy.

Nikt przy zdrowych zmysłach nie odmówi szybszego i lepszego procesu, jeśli zostanie poprawnie wyjaśniony.

Ale bądź gotów bronić swojego argumentu, aby uzasadnić zmianę.

Połowa problemu polega na tym, że używasz przestarzałych narzędzi w procesie, do których nie zostały zaprojektowane. To, co opisujesz, jest bardzo łatwe w nowoczesnych DVCS, bez żmudnego zadania tworzenia gałęzi dla każdego błędu.

Innym problemem jest to, że najwyraźniej nie jesteś w pracy, którą lubisz. Pracujesz w zakresie konserwacji, a chcesz rozwoju. Niewiele można z tym zrobić poza zmianą pracy.

Dyscyplina inżynierii oprogramowania jest z natury „wszystkim związana z procesem”, więc zastanawianie się, czy „tak się stało”, w pewnym sensie nie ma sensu.

Podczas gdy większość programistów wolałaby niepokoić się absolutnym minimum procesu, do tego stopnia, że ​​niektórzy będą opowiadać się za zwinnymi metodologiami, nawet jeśli nie rozwiążą problemów, przed którymi stoi ich organizacja, jest całkowicie możliwe, że firma zdecyduje się na użycie „ ciężkie „procesy z uzasadnionych powodów biznesowych, takie jak„ klient tego wymaga ”. Jest to powszechne, jeśli Twoimi klientami są firmy z listy Fortune 500, uniwersytety lub agencje rządowe. Korzyści ze sprzedaży tym klientom mogą być na tyle duże, że uzasadniają dodatkowe koszty procesu.

Twoja firma to jeden punkt danych i nie można uogólnić swojego doświadczenia na trend w branży w kierunku lub od trudniejszych procesów. Prawdziwe pytanie brzmi: jaka równowaga działa najlepiej dla Twojej firmy, Twoich produktów, Twoich klientów i Ciebie, jako programisty? Jeśli nie lubisz pracować dla tej firmy, zainicjuj zmianę lub zdobądź inną pracę.

Z drugiego pytania , które dziś widziałem, wydajesz się niezadowolony ze swojej pracy. Nie byłeś tam długo, możesz po prostu powiedzieć swojemu przełożonemu, że uważasz, że popełniłeś błąd, i nadszedł czas, abyś rozstał się wcześniej niż oczekiwano.

Jeśli jesteś dobry w swojej pracy, naprawdę nie będziesz miał trudności ze znalezieniem nowego, i szczerze mówiąc, jeśli nie ma dobrego powodu, aby istnieć ten proces, prawdopodobnie rozważę przeprowadzkę. Korzystanie z CVS byłoby dla mnie naprawdę przełomem, ale zawsze zadaję pytanie kontroli źródła podczas wywiadu. Oczywiście nie znam twojej sytuacji i może być niemożliwe odejście z pracy, jeśli masz inne obowiązki.

Zamierzałem opowiedzieć o tym, jak inżynieria oprogramowania jest zalewana przez bardzo złych programistów, ale opisywana sytuacja jest okropna.

Z mojego osobistego doświadczenia, część tego „procesu”, który opisujesz, towarzyszy temu, że zarządzanie i administracja systemem są całkowicie nieświadome nieefektywności systemów, które narzucają programistom. Przykłady obejmują ograniczenie wyboru systemu operacyjnego, ograniczenie wykorzystywanego oprogramowania, dostęp do Internetu, uprawnienia administracyjne na pulpicie osobistym; wszystkie te rzeczy są niezbędne dla dobrego rozwoju.

Ponadto wymagania dotyczące zgodności między „magicznymi rozwiązaniami” stosowanymi przez różne oddziały firm. Przykłady obejmują centrale narzucające scentralizowaną kontrolę źródła, zewnętrzne serwery Outlook oraz wytyczne i języki programowania, które mogą nie być odpowiednie dla każdego problemu.

Niezbyt fajnie jest utrzymywać koła korporacyjnych żonglerów, ale zauważyłem, że w niektórych firmach istnieją małe bąbelki innowacji, kreatywności i błyskotliwości.

Prawdopodobnie pracujesz w firmie zorientowanej na proces . Zamiast tego spróbowałbym znaleźć firmę zorientowaną na wyniki , w której liczy się to, czego nie robisz, jak to robisz.

W mojej firmie też mamy „proces” (ale jest to bardzo prosty) .. Ale kiedy mi przeszkadza, łamię zasady i pomijam kroki. Nikt nigdy nic mi nie powie, dopóki nie będę niczego łamał przez stosowanie skrótów, ponieważ otrzymuję wyniki.

Czy istnieje punkt, w którym proces staje na przeszkodzie i staje się celem samym w sobie? Czy to w ogóle inżynieria?

Dosłownie większość inżynierii łączy dobrze ustalone elementy w ustalonej kolejności w odpowiedzi na konkretny problem. Jest to najbardziej oczywiste, jeśli zapytasz ME, co robią przez cały dzień. Mylisz inżynierię z architekturą lub rozwojem produktów na wczesnym etapie (w dowolnej dziedzinie). Mam dwie uwagi na temat twojego pytania.

1. Wygląda na to, że przydzielono Cię do prac naprawczych, a nie prac związanych z architekturą lub projektowaniem.
2. Wydaje się, że twoi współpracownicy wymyślili ograniczone obejścia (łączenie maszyn wirtualnych naprawiających błędy), aby zwiększyć ich wydajność, wydaje się, że nie podążasz za ich rozsądnym przykładem.

Jest to po prostu fakt, że w każdym konstruktywnym przedsięwzięciu, które wymaga dużej liczby osób, niektórzy ludzie wykonują projekt, a większa grupa „dostaje”, aby wykonać. Przepraszamy, ale należysz do tej drugiej grupy.

Jak zauważyli inni komentatorzy, CVS nie jest najlepszym narzędziem do pracy w wysoce rozgałęzionym modelu programistycznym, ale zauważam również, że nie jesteś odpowiedzialny za łączenie ... więc nie martw się o to.

Większość twoich skarg wydaje się brzmieć: „Nie chcę testować przed, w trakcie lub po rozwoju!” Podzielmy twoje kroki, punkt po punkcie.

• Aby naprawić pojedynczy błąd, najpierw otrzymuję czystą, nową maszynę wirtualną. Środowisko testowe
• Następnie tworzę gałąź dla tej pojedynczej poprawki błędu, na podstawie innej gałęzi opisanej w raporcie Bugzilli. - Powielasz środowisko, w którym znaleziono błąd ... jak to jest nieuzasadnione?
• Instaluję gałąź na komputerze, konfiguruję ją. Naprawiam błąd. Sprawdzam to - Podstawowy proces tworzenia
• ... pozostawiając urządzenie i maszynę do testowania przez innych. - Twój zespół scalający prawdopodobnie chce, aby był w stanie zweryfikować poprawkę, jeśli scalenie pójdzie na południe.
• Potem muszę przejść do oprogramowania do kontroli błędów i wyjaśnić, co zrobiłem - jeśli jesteś w sklepie, który tego nie robi ... dlaczego w ogóle śledzisz błędy?
• i napisz test ze wszystkimi krokami. - Mogę się mylić, ale wydaje się, że w tym kierunku idą wszystkie „fajne dzieciaki”
• W końcu ktoś inny połączy to z wydaniem. - I kilka powyższych kroków ma na celu ułatwienie ich pracy

Ktoś przed tobą najwyraźniej dokonuje segregacji błędów, aby upewnić się, że znaleziony błąd nie zostanie naprawiony w innym wydaniu lub uszkodzony w późniejszym wydaniu (po to są przypadki testowe).

Jedyną rzeczą, nawet zdalnie nietypową lub nadgorliwą w tym procesie, jest sprawa VM. Istnieje spora szansa, którą uznalibyśmy za rozsądną, gdybyśmy wiedzieli, w której dziedzinie pracujesz.

Ciekawy. Czy masz testerów? Powinni to zrobić. Jestem jednym i tam, gdzie pracuję, mamy przyzwoite rozwiązanie.

W przypadku defektu funkcjonalnego, jak wyjaśniasz, nasz proces wygląda następująco:

1. Testuję pod kątem defektu na maszynie wirtualnej (zgłoszonej przez klienta lub podczas moich testów eksploracyjnych lub w / e)
2. Błąd został znaleziony / naprawiony.
3. Tworzę błąd. Błędy obejmują:
   • Pełne repro, od momentu instalacji do momentu zauważenia błędu.
   • Link do migawki maszyny wirtualnej (jeśli myślę, że deweloper będzie jej potrzebował ... i tak robię migawkę, na wypadek, gdyby poprosili o nią).
   • Informacje o systemie, wszelkie specjalne ustawienia, które musiałem wprowadzić.
4. Ten błąd zostaje przypisany do dewelopera. Podczas pracy nad poprawką I:
   • Utwórz przypadek testowy
   • Napisz (lub przekonwertuj) test ręczny na test automatyczny

Potem czekam na rozwiązanie i pomagam twórcy w dowolny sposób, którego potrzebują. Kiedy powróci jako rozwiązany, ja:

1. Uruchom automatyczną skrzynkę testową i wersję ręczną (czasami), aby potwierdzić poprawkę.
2. Zamknij błąd.

TL; DR: Jeśli nie masz testerów, potrzebujesz trochę. Jeśli je masz, to nie „wykonują swojej roli”.

Tom DeMarco:

... Moja wczesna książka metryk ... najczęściej cytowany wiersz to pierwsze zdanie: „Nie możesz kontrolować tego, czego nie możesz zmierzyć”. Ta linia zawiera prawdziwą prawdę, ale coraz bardziej nie czuję się dobrze z jej użyciem. Cytat (i rzeczywiście w tytule książki) sugeruje, że kontrola jest ważnym aspektem, być może najważniejszym, każdego projektu oprogramowania. Ale tak nie jest.

... im bardziej skupiasz się na kontroli, tym bardziej prawdopodobne jest, że pracujesz nad projektem, który stara się dostarczyć coś o stosunkowo niewielkiej wartości.

Moim zdaniem pytanie o wiele ważniejsze od tego, jak kontrolować projekt oprogramowania, dlaczego, u licha, realizujemy tak wiele projektów, które zapewniają tak marginalną wartość? ...

Inżynieria oprogramowania: pomysł, którego czas minął?

„Następnie tworzę gałąź dla tej pojedynczej poprawki błędu”

Nie ma potrzeby tworzenia gałęzi dla pojedynczej poprawki błędów. Najpierw utwórz błąd w Bugzilli. Sprawdź gałąź wydania. Dokonaj poprawki. Wykonaj zatwierdzenie z komunikatem zatwierdzenia zawierającym numer błędu, który aktualizuje błąd i oznacza go jako „naprawiony, wymaga testu” lub „naprawiony, przetestowany, wymaga scalenia” odpowiednio, w zależności od słów kluczowych tekstowych zapisanych w komunikacie zatwierdzenia. Baza danych błędów jest idealnym mechanizmem śledzenia wszystkich wprowadzonych zmian i powodów ich wprowadzenia; raporty mogą być uruchamiane z bazy danych błędów w celu wyodrębnienia tych informacji.

Myślę, że większość procesu można zautomatyzować , tak aby tworzenie maszyny wirtualnej i gałęzi (w tym kompilowanie kodu, konfigurowanie debuggerów itp.) Zostało wykonane za Ciebie przed rozpoczęciem pracy nad błędem.

Opisanie tego, co zrobiłeś i jak należy go przetestować, jest warte wszystkich poprawek. Odkryłem, że pisanie tekstu może wychwycić problemy , ponieważ każę mi myśleć o ryzyku itp.

Myślę więc, że proces ten może być nieco „przesadzony”, ale prawdziwym problemem jest brak niestandardowych zautomatyzowanych narzędzi do obsługi procesu.

O, człowieku, twój proces myślowy jest prawidłowy, ponieważ to, co opisałeś, jest całkowicie beznadziejne i stanowi prawdziwy dowód na to, jak złe mogą być rzeczy w oprogramowaniu. Oto dobra wiadomość, jest tak wiele firm praktykujących Agile w prawdziwych nastrojach. Firma, w której pracuję, jest taka. W dzisiejszych czasach jest wiele dobrych wiadomości.

Kiedy czujesz, że w twoim miejscu pracy naprawdę nie ma rzeczy, są dwie rzeczy, które możesz zrobić - albo możesz wpłynąć na pozytywne zmiany, albo opuścić to miejsce i dołączyć do lepszego.

CVS lub inny system zarządzania konfiguracją nie jest zły. Niestety sposób, w jaki jest używany, bez znajomości jego przeznaczenia, powoduje ten ból w całej organizacji! @ # $.

Aby szybko zrozumieć, na czym tak naprawdę polega Agile, zapoznaj się z książką Venkata Subramaniam „Practices of a Agile developer”. Jest ładnie napisany w łatwo zrozumiałym języku.

Życzę Ci szczęścia!