Jak przeprowadzić skuteczną weryfikację kodu podczas gorączki wydania?

Ostateczny termin wydania to jutro, twoja koleżanka w końcu zakończyła swoje kluczowe dla tego wydania zadanie, kierownik projektu stoi nad twoim ramieniem i naciska, by w końcu stworzyć kompilację, a podczas przeglądu zauważasz wadę w kodzie kolegi. Nie krytyczny, ale coś, czego nie wypuściłbyś, gdyby nie premiera jutra. I, co gorsza, masz własną pracę, którą musisz wykonać jak najszybciej. Więc co robisz? Czy podniosłeś swój sprzeciw pomimo presji, czy po prostu pozwalasz temu umknąć?

Znalazłem jeden sposób, aby tymczasowo połączyć to zatwierdzenie w innym oddziale i pozostawić recenzję na później. Działa, jeśli problem jest tylko kosmetyczny i jeśli tylko on nadal czeka na sprawdzenie kodu. Czy istnieje jednak bardziej skuteczny sposób, aby sobie z tym poradzić? Na przykład, czy poleciłbyś, aby jedną osobę tylko przeglądać i testować?

Odpowiedź brzmi: komunikować się.

1. Poinformuj kierownika technicznego / zespołu o problemie
2. Porozmawiaj z QA o potencjalnym wpływie
3. Poinformuj kierownictwo projektu (który jest tuż za tobą), że może występować problem, który powoduje opóźnienie wydania, i wrócisz z nimi jak najszybciej (w ciągu kilku minut lub godzin)
4. Oceń, czy ten problem stanowi przeszkodę dla wydania

Jeśli problem nie jest ogranicznikiem programu, kontynuuj wydanie. Poinformuj QA i swoich użytkowników o problemie i zobowiązaj się na termin, w którym problem zostanie załatany. To właśnie staje się kolejnym ryzykiem związanym z produkcją.

Jeśli jest to ogranicznik pokazu (co oznacza, że ​​będzie to miało negatywny wpływ na wynik finansowy lub czyjeś zdrowie), poinformuj o tym w łańcuchu, że Twoim zaleceniem jest opóźnienie wydania i powiedz dlaczego. Następnie wróć do dewelopera i ustal, ile czasu zajmie rozwiązanie problemu, i powiedz zarządowi, że potrzebujesz X liczby minut / godzin / dni.

Szanse są, że kierownictwo nie będzie zadowolone z zatrzymania show tak późno w grze, ale nie będzie chciało, aby to zostało wprowadzone do produkcji.

Komunikuj się i pozwól zarządowi wykonać połączenie.

Nie tylko komunikuj problem, udokumentuj go

Moja wielka obawa związana z pozostałymi dotychczasowymi odpowiedziami: wszystko, co powiesz w ten sposób typowemu kierownikowi projektu w obliczu zbliżającego się terminu, prawdopodobnie zostanie zignorowane lub zapomniane. Wtedy możesz nadal być na haku niedostateczne informowanie o ryzyku, jeśli coś pójdzie nie tak.

Poinformuj kierownika projektu o znalezionym problemie i daj mu znać go udokumentujesz . Musisz być w stanie wskazać swoją należytą staranność.

Gdzie dokumentować i komu powiedzieć, zależy od twojego środowiska pracy, ale zdecydowanie dołącz do swojego szefa.

Zidentyfikuj ryzyko i wpływ

Wspominasz, że problem nie jest krytyczny ale tak naprawdę nie definiujesz, co to znaczy. Wykonanie tego jest kolejnym krokiem.

Wykonaj szybką analizę ryzyka i wpływu identyfikując problem, prawdopodobieństwo jego wystąpienia (ryzyko) i dotkliwość konsekwencji, jeśli ryzyko dojdzie do skutku (wpływu). Użyj dobrze zdefiniowanych terminów (które powinien znać Twój kierownik projektu), takich jak te znajdujące się w powyższym linku, ale także podaj opis, na którym tworzona jest analiza.

Twoja dokumentacja powinna również zawierać zalecany kierunek działania. Tak , możesz zgłosić problem i nadal polecać kontynuowanie wydania. Prawidłowe jest zidentyfikowanie ryzyka .

Kiedy jest twoje następne wydanie?

Jeśli po zakończeniu analizy ryzyka / wpływu nadal masz wątpliwości, co polecić, weź pod uwagę harmonogram wydań. Niektóre niedoskonałe kody można opublikować, jeśli można spodziewać się, że poprawka zostanie dołączona za dwa tygodnie.

Jeśli istnieje szansa, że ​​naprawienie problemu zostanie „zdepriorytetyzowane” (to znaczy zaniedbane na rzecz kolejnego błyszczącego rozszerzenia), jest to kolejny powód do udokumentowania problemu jak najszybciej po jego wykryciu: jeśli skutecznie „zacznie się” zegar ”w tej sprawie.

W takim przypadku poinformuj wszystkich i pozwól im zdecydować. Prawdopodobnie nie jest to pierwszy błąd, który wydałeś.

Termin jest jutro, ale znajdziesz się w takiej sytuacji:

kierownik projektu stoi nad twoim ramieniem i naciska, aby w końcu stworzyć kompilację

Może to być wyjątek, więc nie wprowadzaj żadnych drastycznych zmian w procesie tylko dlatego, że jeden błąd prześlizgnął się. To, co powinieneś zrobić, to wprowadzić pewne środki, aby nie tworzyć kompilacji w ostatniej chwili. Mamy nadzieję, że tworzysz kompilacje z wystarczającą częstotliwością, aby dać ci pewność, że się uda. To wciąż nie jest wystarczający powód, aby je uruchomić w ostatniej chwili. Dobrze przetestowane rzeczy to kolejny element zwiększający pewność siebie.

Przedstaw ten scenariusz każdemu, kto to prowadzi.

• Określ, jakie rodzaje problemów należy przedstawić.
• Zidentyfikuj opcje.
• Kto podejmuje decyzję
• Kiedy o tym wszystkim powinno decydować? Prawdopodobnie będzie to względne w stosunku do daty premiery.

Chociaż nie jest to odpowiedź na pytanie, co zrobić z tym problemem w ostatniej chwili, oferuje sposób na poradzenie sobie z nimi w przyszłości. Zwłaszcza, gdy istnieje presja na uwolnienie, chcesz mieć sposób radzenia sobie z rzeczami w sposób przemyślany i nie napędzany emocjami.

Jeśli jest termin, a twój kierownik stoi tuż za tobą i spogląda przez ramię, każ mu odejść. On odchodzi albo ty odchodzisz. Wyjaśnij mu, że zmuszony do sprawdzania pod presją, równie dobrze możesz nie sprawdzać kodu.

W takiej sytuacji możesz być całkiem pewien, że wystąpi jakiś krytyczny błąd.

Być może masz szczęście, na przykład przesyłając do Apple App Store, gdzie masz kilka dni na wycofanie nowej wersji. Ale jeśli kod zostanie wysłany do klientów, jest to przepis na katastrofę. Następnym razem mam nadzieję, że twój menedżer planuje lepiej.

Inne odpowiedzi koncentrują się na problemie menedżera próbującego zgiąć proces jakości.

Jednak myślę, że pytasz, jak poradzić sobie z faktem, że przegląd kodu wymaga co najmniej 2 osób, a zatem wprowadza znaczne opóźnienia. Na przykład, jeśli zadanie zajmuje 2 godziny na wdrożenie i 2 godziny na sprawdzenie, często między tymi dwiema czynnościami jest długa przerwa. Wykonanie zadania w czasie rzeczywistym może zająć 2 lub 3 dni.

Jest to klasyczny problem przepustowości względem opóźnienia. W maszynach produkujących oprogramowanie (ludzi) przełączniki kontekstu są drogie, więc zapobieganie czyimś zadaniu natychmiastowego przeglądu nie powinno być powszechną praktyką.

Oto kilka wskazówek pozwalających złagodzić problem:

• Podczas pracy nad zadaniem wyślij kod w małych częściach, aby recenzent nie musiał rezerwować długich, ciągłych kawałków czasu.
• Promuj kulturę o wysokim priorytecie podczas recenzji kodu. Nie przerywaj bieżącej jednostki pracy, gdy otrzymasz prośbę, ale gdy zastanawiasz się, co dalej, zawsze wybieraj recenzję z kolejki.
• Skorzystaj z różnicy stref czasowych w swoich zespołach, jeśli taka istnieje.
• Nie angażuj ani jednej osoby do przeglądania kodu. To przynosi efekty. Nie będzie w stanie poradzić sobie z ładunkiem, jeśli będzie poważnie podchodził do swojego zadania. Twój menedżer nie zaakceptuje myśli, że ktoś jest bezczynny, aby potencjalnie zaoszczędzić jeden dzień.