Project Manager prosi o pełne 100% zaufania za każdym razem, gdy popełnia kod

Jak mam odpowiedzieć na jego pytanie w tym przypadku, nie wydając się niekompetentny? Szczerze mówiąc, nigdy nie mam 100% pewności siebie na miejscu, ale mam zaufanie do moich metod badawczych. I jako programista wiem również, że nierzadko zdarza się, że niespodziewane błędy pojawiają się później po tych zasadniczych zmianach.

Kierownik projektu nie rozumie oprogramowania wystarczająco dobrze, a na pewno nie rozumie testowania wystarczająco dobrze. Być może musi być wykształcony.

Jeśli miałbyś profesjonalny dział kontroli jakości, powiedziałbym Ci, abyś skorzystał z pomocy kierownika projektu i wyjaśnił mu naturę oprogramowania, naturę błędów i naturę testowania. Powiedziałbym Kierownikowi ds. Zapewnienia Jakości, aby wskazał, dlaczego po prostu nie jest możliwe przetestowanie każdego warunku i jak wypuszczanie/nie wypuszczanie jest działalnością biznesową wspomaganą przez wyniki testów, ale nigdy przez doskonałe informacje.

Możesz chcieć otrzymać kopię doskonałej książki Geralda Weinberga “* Idealne oprogramowanie i inne iluzje dotyczące testowania **”. W rozdziale 3 (“Why Not Just Test Everything?”), Weinberg ma rozdział zatytułowany “There are an infinite number of possible tests.”

Mówi on o tylnych drzwiach umieszczonych w wysoce bezpiecznym programie, w którym zwykła ochrona hasłem może być ominięta poprzez wpisanie litery W, po której następują trzy spacje, następnie M, po której następują trzy spacje, następnie J, po której następuje dokładnie 168 kolejnych naciśnięć klawiszy bez użycia raz litery L.

Następnie pisze: “Do you get the point by now? Jeśli nie zgadłeś, że liczba testów wymaganych do wyczerpującego przetestowania oprogramowania jest nieskończona, lub przynajmniej "liczba większa niż mogłam uruchomić w moim życiu”, to nie zrozumiałeś sensu tego rozdziału. Teraz rozumiesz.“

Wyjaśnij swojemu Kierownikowi Projektu, że każdy dzień dodatkowych testów poprawi nieco Twoje zaufanie do kodu, ale nigdy nie może osiągnąć 100%. Powiedz mu, że byłbyś szczęśliwy mogąc kontynuować testowanie kosztem swojej innej produktywnej pracy. Następnie zapytaj go, ile dni jeszcze chciałbyś spędzić na testowaniu i którą z pozostałych prac powinieneś odłożyć na później.

Jeśli Twój Project Manager nadal tego nie rozumie, a czujesz się trochę roztargniony, zapytaj go, czy jest w 100% pewien, że każda publikowana przez niego ocena jest dokładnie poprawna i nigdy nie zostanie pominięta. Zapytaj go, czy jest w 100% pewny, że żaden e-mail, który napisze od teraz do końca życia, nie będzie miał literówki. Zapytaj go, czy jest w 100% pewny, że nigdy nie popełni błędu - teraz i w przyszłości.

Boss:Czy jesteś w 100% pewien, że ta poprawka nie złamie żadnych istniejących funkcji lub nie spowoduje żadnych negatywnych skutków dla doświadczenia użytkownika?

Me:Nie. Ponieważ nie posiadamy 100% pakietu testów pokrycia nie ma możliwości sprawdzenia, czy jakakolwiek zmiana kodu zapobiegnie złamaniu aplikacji lub wystąpieniu negatywnych skutków. Jednakże, wykonałem następujące czynności, aby upewnić się, że jest mało prawdopodobne, że będą one wykonywane w niezamierzony sposób:

• Ograniczyłem zakres zmiany tylko do modułu, na który ma ona wpływ
• Przeczytałem i zaktualizowałem odpowiednio dokumentację
• Przeprowadziłem testy jednostkowe dla tego modułu i modułów, na które ma ona wpływ
• Stworzyłem testy jednostkowe, aby sprawdzić nowe dodane funkcjonalności, oraz przestarzałe testy, które nie mają już znaczenia ze względu na zmianę

Choć nie mogę dać Wam dokładnie 100% pewności, dałem Wam tyle pewności, ile mogłem w ramach czasowych, które uważam za rozsądne dla wdrożenia tej funkcjonalności. W rzeczywistości już osiągnęłam punkt zmniejszenia zwrotów. Mogę poświęcić kolejne 5 godzin na udzielenie kolejnego zapewnienia 0,1%, ale jest to już tak mała szansa, że taki wysiłek nie jest uzasadniony. Jednak to Ty jesteś odpowiedzialny za projekt i ramy czasowe, więc daj mi znać, ile jeszcze czasu powinienem poświęcić na tę funkcję.

• *

Teraz piłka jest na jego boisku. Jeśli naprawdę chce, żebym przeniósł moje osobiste oszacowanie z, powiedzmy, 95% pewności do 95.1% pewności na kilka godzin pracy, to hej - mogę to zrobić.

Jeśli nadal będzie się wkurzał, będę miał z nim i “właścicielem” projektu rozmowę mailową na temat tego “100% testowanego” wymogu i tego, jakie zasoby są moim zdaniem potrzebne do jego spełnienia.

Jako deweloper, jesteś UNIT-em testującym zmiany w swoim kodzie. Moim zdaniem (jako dewelopera), to znaczy sprawdzanie, czy nie ma oczywistych błędów, wszystko się kompiluje, wszystkie błędy są uwięzione. Nie masz możliwości sprawdzenia, jakie scenariusze zostaną napotkane po uruchomieniu kodu (złe dane, nieoczekiwane wejście, zmiana w oprogramowaniu klienta, lista jest niekończąca się)

Aby mieć 100% pewność, że zmiana nie wpłynie na nic, potrzebujesz środowiska testowego, które WYRAŹNIE odzwierciedla środowisko na żywo (dane, sprzęt, uprawnienia, łączność) oraz zestawu skryptów testowych, które pokrywają każdy scenariusz. To, jak dobrze wiadomo, jest to praktycznie niemożliwe do stworzenia środowisko z różnych powodów

Jeśli oczekuje 100% pewności siebie, to musi zapewnić środowisko i siłę roboczą, aby wesprzeć swoje oczekiwania

Jest to trochę jak wtedy, gdy kierownicy projektów i klienci proszą o rzeczy, które są przyszłościowe!

Brzmi jakby wpadł w zły nawyk. Zadaje pytanie, które w pewnym sensie zna, jest głupie. Ale jest w tym pewien element kompulsywny. Domyślam się, że działa w oparciu o lęk, a zadawanie nierozsądnych pytań sprawia, że czuje się bardziej opanowany.

W takich sytuacjach staram się rozproszyć dynamikę, będąc pewnym siebie i wstrzykując odrobinę humoru. Jeśli rozumiesz, że jego pytanie nie pochodzi z rozumowania, ale z lęku, wtedy możesz zająć się tym lepiej pośrednio niż bezpośrednio.

W takich sytuacjach zazwyczaj usuwam lęk przed zarządzaniem, przedstawiając wszystkie środki, które podjęłam, aby zapewnić jakość. On jest przecież klientem i musi wiedzieć, że Twoje priorytety są zgodne z jego. Spójrzcie na te testy jednostkowe. Spójrzcie na ten monitoring. Spójrz na strukturę kodu, aby zachować zmiany lokalne, modułowe itd. Jeśli przekażesz mu poczucie pewności siebie i kontroli, rozwieje to jego niepokój i prawdopodobnie będziesz w stanie prowadzić bardziej racjonalną rozmowę.

W tym właśnie tkwi sztuka tego biznesu. Nie tylko “to działa”, ale także sprawia, że klient czuje się z tym dobrze.

Ostatecznie jednak, jest to relacja biznesowa. Jeśli umowa jest dla Państwa wygodna i opłacalna, warto się z tym dziwactwem pogodzić. Nie brzmi to tak, jakby był w tym cały poważny, tylko trochę uparty. Jak mówię, ma irytujący nawyk. Jeśli zacznie reagować negatywnie, a ton stanie się bardziej wrogi, wtedy równowaga w układzie biznesowym może sprawić, że nie będzie się to dla ciebie opłacało. Ale z twojego krótkiego opisu, wydaje mi się, że nadal możesz skutecznie zarządzać relacją.

Wiele osób określiło to jako problem edukacyjny, a ja nie twierdzę, że się mylą.

Możliwe, że jest to również problem polityczny. W rzeczywistości pytanie może oznaczać, że kierownik projektu chce być zwolniony z odpowiedzialności za wszelkie błędy. Otrzymuje od Ciebie przysięgę, że czuje, iż może “rozsądnie” polegać na swoich działaniach, więc jeśli coś pójdzie nie tak, mówi, że zrobił wszystko, co w jego mocy, aby temu zapobiec, ale Ty zawiodłeś.

To nie jest dobre zarządzanie i nie jest również w 100% gwarantowane, aby postawić go w sytuacji, gdy pojawią się problemy.

Przyznaję, że to są spekulacje z mojej strony, ale ćwiczenia przykrywające tyłek nie są wcale rzadkością w życiu zawodowym i musisz sobie z nimi poradzić. Więc jeśli to brzmi prawdziwie, to co musisz zrobić, aby rozwiązać ten problem, to nie tylko uświadomić menadżerowi, że 100% pewność siebie jest niemożliwa. Musisz go również przekonać, że błąd nie jest katastrofą - dla niego osobiście lub dla firmy.

Może to oznaczać na przykład dostarczenie przykładów radzenia sobie z błędami po rozsądnych kosztach i bez żadnej winy. Może to oznaczać przyjrzenie się własnej kulturze organizacyjnej, czy w firmie jest ktoś inny, kto szykuje się do tego, by zrzucić na niego niesprawiedliwą winę, jeśli coś pójdzie nie tak. Może to również oznaczać wprowadzenie procedur postępowania z przyszłymi błędami tak szybko i tanio, jak to możliwe. Gdyby firma naprawdę była w 100% pewna kodeksu, takie procedury byłyby bezcelowe, ponieważ byłaby gotowa postawić arbitralnie duże sumy pieniędzy na to, że w przyszłości nie będzie żadnych błędów!

Jako ostateczną sankcję, jeśli on (pracodawca) poprosi Cię (wykonawca) o sprzedanie mu zapewnienia, którego nie możesz dać o swojej pracy, a nic nie zmieni jego zdania na ten temat, wtedy wszystko co możesz zrobić, to wyraźnie powiedzieć, że nie jesteś w stanie dać takiego zapewnienia, i że może zatrudnić kogoś innego, jeśli uważa, że jest ktoś, kto może. Oczywiście jest to długa droga w dół, ale równie dobrze możesz znać swoją BATNĘ zanim zaczniesz.

Ściśle mówiąc, nigdy nie można być w 100% pewnym, że zobowiązanie nie złamie programu.

Nawet przy wszystkich możliwych testach (test jednostkowy, integracja, komponent, system, ręczny, UI, fuzz, bezpieczeństwo, penetracja… nazywasz to). Jest to spowodowane Problem zatrzymania . Poniżej znajduje się odpowiedni wyciąg z Wikipedii:

W teorii obliczeń, problem z zatrzymaniem można stwierdzić następująco: “Biorąc pod uwagę opis dowolnego programu komputerowego, zdecyduj, czy program zakończy działanie, czy będzie działał wiecznie”. Jest to równoznaczne z problemem decydowania, biorąc pod uwagę program i wejście, czy program ostatecznie zatrzyma się, gdy zostanie uruchomiony z tym wejściem, czy też będzie działał wiecznie.

Alan Turing udowodnił w 1936 roku, że ogólny algorytm do rozwiązywania problemu zatrzymania dla wszystkich możliwych par program-wejście nie może istnieć. Kluczową częścią tego dowodu była matematyczna definicja komputera i programu, który stał się znany jako maszyna Turinga; problem zatrzymywania jest niezdecydowany w stosunku do maszyn Turinga.

Jeśli Twojemu PM'owi zależy na wartości i stabilnej przewidywalnej dostawie, być może przekonasz go, aby przyjrzał się ramce SCRUM .

Inni dali wiele interesujących rad, jak współpracować z Twoim PM'em. Osobiście radziłbym umówić się na spotkanie z Twoim premierem i zespołem, na którym będziesz mógł omówić swoje procesy. Jestem zdecydowanym zwolennikiem SCRUM, więc byłoby to w dużej mierze związane z SCRUM.

Spróbuję wyjaśnić, że cel 100% jest nieuchwytny. Nie da się go osiągnąć. Nigdy. W całym wszechświecie. Historia widziała wiele takich przykładów, na przykład demo wydania Windows 95 . Dawno temu? Cóż, zobacz ile czerwonych buduje się na publicznym serwerze CI dla projektów open source; zaloguj się jako gość, jeśli nie masz tam konta. Więc rezultat tego - oprogramowanie zawiedzie.

Po drugie, radziłbym przyjąć praktykę, gdzie można dostarczyć wartość, zamiast zaufania zobowiązania. Coś, na czym klientom zależy. Iteracyjnie, wielokrotnie i niezawodnie. Teraz można zmienić perspektywę PM z 100% pewności na coś, co rzeczywiście ma znaczenie. To znaczy: oprogramowanie jest w użyciu, Twój produkt jest coraz lepszy, a zespół dostarcza wartość dla klienta.

Po trzecie, powinna być definicja zrobione. Czegoś, co wymyślił zespół programistów. Może to być: dokumentacja, implementacja, testy, bramki jakości itp. Jest to bardzo ważne, ponieważ możesz teraz przesunąć podmiotowość (czyli “jesteś 100% pewien?”) na obiektywność (czyli wszystkie punkty definicji done są zakończone).

Istnieją inne bardzo ważne kroki, które SCRUM promuje. Ale wszystkie z nich pozwolą deweloperom złagodzić tę frustrację i pozwolą im na uzyskanie obiektywnie policzalnych wyników, w porównaniu do subiektywnej pewności.

Typową odpowiedzią na tego typu cele są recenzje i testy regresji.

1) Nie zobowiązuj się do niczego w produkcyjnym strumieniu kodu, dopóki nie sprawdzi go nie tylko autor, ale także jeden lub więcej innych programistów, aby upewnić się, że zmienia tylko to, co jest konieczne, że spełnia wszystkie uzgodnione kryteria dobrej praktyki kodowania, że przychodzi z testem, który daje przyzwoite szanse na wykrycie, czy późniejsza zmiana znów złamie logikę, i tak dalej.

2) Nie angażuj niczego do strumienia kodu produkcyjnego, dopóki WSZYSTKIE testy regresji nie zostaną powtórzone i nie zostanie udowodnione, że nie łamie niczego, dla czego test jest przeznaczony. Jeśli podczas tego testu wystąpi jakiekolwiek niepowodzenie, zmiana musi zostać wycofana aż do momentu, gdy będzie można wyraźnie stwierdzić, że nie spowodowało to problemu.

3) Alpha- i beta-testy wcześnie i często z rzeczywistymi scenariuszami klientów. Klienci zrobią z Twoim kodem rzeczy, których się nigdy nie spodziewałeś.

Żaden z nich nie jest w 100%, ani nie jest ich kombinacją. Ale dzięki nim jesteś znacznie bliżej. Wymagają nietrywialnej inwestycji dodatkowych zasobów. Spowalniają rozwój w porównaniu do skunkworks “po prostu zrób to, a my to naprawimy, gdy się złamie” praktyki kodowania. Ale jeśli naprawdę chcesz kod wolny od błędów, uznanie, że ludzie są podatni na błędy i wprowadzenie praktyk pomagających wyłapać błędy zanim dotrą do klientów może być więcej niż warte tych kosztów.

Powiedziano mi, że w kodzie napisanym przez IBM dla NASA nie było nigdy błędu - ponieważ był on recenzowany i testowany na śmierć podczas projektowania, podczas rozwoju i przed wydaniem.

Jeśli robisz coś, co jest krytyczne dla życia, to oczywiście warto zainwestować. Jeśli robisz coś, co jest infrastrukturą dla dużych firm, to jest to warte tej inwestycji; nie chcesz być tym, którego błąd niszczy procesy biznesowe firmy za miliard dolarów.

Tak, doprowadza dobrych programistów do szaleństwa. Do czasu, gdy po raz pierwszy uratuje ich zachowanie.

Prawda jest taka, że to kiepska próba. Prawda jest taka, że firma, która nie chce inwestować w zespół QA, będzie miała słabe testy. Dobre testowanie jest kosztowne i wymaga czasu. Firma przyjęła na siebie ryzyko nie zatwierdzając czasu i pieniędzy.

Nawet zespół ds. zapewnienia jakości nie może zagwarantować, że każda możliwość jest testowana, ponieważ możliwe ścieżki przez złożony program są w zasadzie nieskończone. Niemniej jednak, zbliżą Cię one znacznie bardziej niż jesteś teraz. Jednym z powodów jest to, że dev nie jest w stanie odpowiednio przetestować swój własny kod. Wiedzą, co robi, więc mają tendencję do projektowania testów wokół tego, co ich zdaniem ma robić. Tęsknią za skrajnymi przypadkami, tęsknią za głupimi rzeczami, które użytkownicy robią tak, jak nigdy nie zrobiłby tego dev, ponieważ wiedzą jak to działa, czasami interpretują wymóg nieprawidłowo, ale wszystkie ich testy będą odzwierciedlać ich oryginalną, błędną interpretację. Często tęsknią za błędami w wymaganiu i robią to, o co zostali poproszeni, a nie to, co powinni byli zrobić (jest to przyczyna ogromnej liczby błędów, które są znajdowane dopiero po tym, jak faktyczni użytkownicy [którzy zbyt często nie są konsultowani przy definiowaniu wymagania] spróbują użyć oprogramowania). Brakuje im efektów na częściach aplikacji, które nigdy nie miały powodu, aby pracować w szczególności w częściach, które są wykonywane przez specjalistów (np. zmiana tabeli, która ma sens dla aplikacji, ale przerywa automatyczny proces importu lub raport)

Jeśli chce wyższej jakości, będzie musiał za to zapłacić zarówno w czasie jak i w pieniądzach. Nawet z pełną QA nie można dostać się do 100%, choć z pewnością NASA i jej wykonawcy są blisko. Oni również wydają więcej pieniędzy niż Twoja firma wydaje. Nawet wtedy, udało im się całkowicie przegapić MARS jeden raz.

Jeśli to, czego chce, jest zapewnienie, że wszelkie problemy nie spowodują mu szkody z klientami, a następnie porozmawiać o swoim procesie do testowania (Pokaż mu listę testów zrobiłeś.), co myślisz, że będzie miał wpływ i jak to sprawdzić, proces, jak można odwrócić złe pchnięcie i proces do błędów logowania tak, że będzie je zobaczyć, zanim większość klientów zauważy je. Daj mu pewność, że nawet jeśli jest jakiś problem, można go naprawić. Porozmawiaj o wartości uzyskania kodu (nowa funkcja lub naprawić) szybko vice versa dodatkowy czas, który byłby potrzebny do dokładniejszego przetestowania. Porozmawiaj o ryzyku nie wydostania go szybko.

Możesz również poprosić go o dostarczenie dokładnego testu regresji systemu za każdym razem, gdy dokonujesz zmiany, ponieważ nie jest możliwe, aby dev całkowicie przetestował swoją własną pracę (wiesz jakie były twoje założenia, jeśli nie są one poprawne, nigdy byś tego nie przetestował). Upewnij się, że wie, że będzie musiał przetestować każdą stronę aplikacji i każdą pojedynczą rzecz, która mogłaby być zrobiona na stronie w każdej możliwej kolejności. O tak, przetestuj wszelkie import/eksport, raporty, zautomatyzowane zadania, jak również. I wszelkie związane z tym aplikacje, których może to dotyczyć. Kiedy już raz spróbuje dokładnie przetestować system, zrozumie, dlaczego nie można tego zapewnić.

Kolejną rzeczą, którą warto spróbować, jest powiedzenie mu z góry, że nie można zrobić tej gwarancji, ale jeśli autoryzował X godzin testów, można zbliżyć się do zrobienia tej gwarancji. Daj mu szczegółową listę dodatkowych testów i godziny, jakie zajęłoby zaprojektowanie i przeprowadzenie każdego z nich. Powiedz mu, jaki procent pewności siebie miałbyś po wykonaniu tych wszystkich testów i jaki procent pewności masz teraz.

Powiedz mu, ile czasu zajęłoby wykonanie wszystkich aktualnych testów jednostkowych, które posiadasz, niezależnie od tego, czy są one związane z tym problemem, czy nie. Więc jeśli masz obecnie 1000 testów jednostkowych i każdy z nich trwa pięć minut, aby skonfigurować i uruchomić i ocenić wyniki, które będą wynosić 83 godziny. Poproś go o autoryzację i poświęć ten czas.

Jeśli rzeczywiście zarządza tobą w skali mikro i patrzy ci przez ramię przez cały proces budowania projektu, jest prosty sposób, aby upewnić się, że możesz ‘zagwarantować’ 100% pewności siebie bez konieczności, aby później cię o tym powiadomić.

Pozwól mu to zatwierdzić samemu

Aby było jasne, nie powinieneś tego robić jako żądania, ale raczej jako sugestię, że jeśli naprawdę chce 100% idealnego kodu, to powinien spojrzeć na to, co robisz sam i zatwierdzić każdą zmianę, którą wprowadzasz po drodze. Nie oznacza to, że powinien dosłownie przeczytać kod, ale raczej zobaczyć go w działaniu i potwierdzić “tak, tak powinno być”.

Jeśli jesteś jedynym testerem swojego własnego kodu, nie jest to nierozsądne - jesteś już w pełni skoncentrowany na projekcie, a jeśli chce on osiągnąć doskonałość, powinien sam wziąć na siebie odpowiedzialność za zapewnienie tej doskonałości.

Ponadto, rób notatki na temat wszystkiego, co akceptuje, tak aby później, gdy nieuchronnie się złamie, można było wskazać na swoją dokumentację pokazującą, że on to zaakceptował.

Jeśli z jakiegokolwiek powodu nie sądzisz, że dobrze by się to skończyło (na przykład, jeśli poproszenie go o więcej pracy jest czymś, o czym już wiesz, że byłoby katastrofalne), wszystko co możesz naprawdę zrobić, to jak najciężej przetestować błędy, zapisać w swoich raportach wszystko, co wiesz, że działa poprawnie i dać mu 100% pewności, że “w granicach moich testów, jestem w 100% przekonany o tych zmianach”.

Niestety, możesz mieć “szefa”, którego rozumienie Twojej pracy jest ograniczone, co jest zawsze dokuczliwe, gdy próbujesz wyjaśnić, jak niemożliwe jest zachowanie 100% pewności siebie w kwestii korygowania błędów. Podsumowując, najlepiej będzie, jeśli zrobisz wszystko, co w twojej mocy, nagrasz wszystko i zrozumiesz, że robisz to, co możesz w swoich granicach.

Całkiem niezłe odpowiedzi, PM zdecydowanie musi być wyedukowany i dowiedzieć się trochę o tym, co to znaczy pisać oprogramowanie.

Nie chcę niczego z tego powtarzać, ale wrzucić kolejny, dość nietypowy pomysł. Ta metoda jest dość ryzykowna i zależy w dużej mierze od tego, jak wysoka jest Twoja reputacja, jak dobre są Twoje umiejętności (lub bardziej jak są one postrzegane), a także od Twojej osobowości i osobowości PM. Zakładam, że nie zrozumiałeś go źle, a on naprawdę ma na myśli 100% (często widzę, że ludzie mówią 100%, ale naprawdę oznacza to “rób co możesz”)

Raz mi się to udało i to jest jedyny powód, dla którego o tym tutaj mówię. Zostałeś ostrzeżony. W większości przypadków jest to możliwy sposób na wykształcenie PM'a, jeśli wszystkie inne środki zawiodą.

Czasami PM (lub inny menadżer) po prostu nie chce słuchać, więc musisz gdzieś sprawić, żeby on (lub zespół) uderzył w ścianę, żeby zatrzymać się na chwilę i pomyśleć. W tym scenariuszu oznacza to: Pracuj tak dobrze jak potrafisz, staraj się testować tak dobrze jak potrafisz. Daj z siebie wszystko, a potem powiedz: “Tak, jestem w 100% pewien, że to zadziała”.

Jeśli masz ogromne szczęście, żaden błąd nigdy się nie pojawi i wszyscy są szczęśliwi; ale w rzeczywistości to co się stanie to: jest błąd. Co teraz zrobisz? Przyznajesz, że popełniłeś błąd. Połącz się z robakami i popełnij błąd polegający na tym, że jesteś w 100% pewny. Ludzie są niedoskonali i mogą tworzyć błędy w oprogramowaniu. Ludzie są niedoskonali i mogą tworzyć błędy w testach. W związku z tym ludzie są niedoskonałe i mogą “tworzyć błędy” w ich postrzeganiu jest 100% pewny, że nie ma błędu.

Przedstaw tę studnię, i 100% wodoszczelne (haha, j/k, 100% ponownie). Upewnij się, że po tym wszystkim, komunikat, który przeszedł jest “nie mogę być w 100% pewny w moich testach”. Jeśli PM nie może zrobić logicznego kroku “To będzie takie samo dla wszystkich programistów”, to cała nadzieja jest prawdopodobnie stracona…

Ale proszę, spróbuj najpierw innych rzeczy!

Kluczowym wskaźnikiem jest to, że jest to ostatnia zmiana. Coś (lub ktoś) prawdopodobnie dało Twojemu PM'owi złe doświadczenia, a teraz jest na krawędzi za każdym razem, gdy coś się zmienia. A może przeczytał coś w książce lub magazynie.

Jeśli możesz nakłonić premiera, aby opowiedział Ci swoją historię (być może nad wybranym przez niego napojem), możesz mu współczuć, a on może stać się otwarty na “innowacje”, czyli solidną praktykę inżynierii oprogramowania.

Jest to Twoja szansa, aby porozmawiać o ludzkich błędach i o tym, jak ta branża znalazła sposób na zwiększenie poziomu zaufania do naszych projektów i kodu. Aby porozmawiać o kompromisach w zakresie zaufania, jakości, zasobów i harmonogramu, które wynikają z różnych podejść do testowania, wzajemnej weryfikacji kodu, metod formalnych (alias correctness-by-construction).

Mów jego językiem: Użyj metafory, aby zilustrować wielkość problemu. Czy jest to 40,000 linii kodu? Powiedz mu, że to jest jak 600-stronicowa tajemnica morderstwa w obcym języku. Jeśli chcesz coś zmienić w środku rozdziału 12, jak możesz się upewnić, że nie spowoduje to zerwania ciągłości z resztą historii?

Szukaj sposobów na zwiększenie zaufania do akceptowalnego celu w rozsądnych granicach ekonomicznych. Nie będziesz w stanie wdrożyć modelu dojrzałości do zdolności SEI na poziomie 5 w ciągu jednej nocy. Ale być może będziesz mógł przejść od obecnego pytania do “czy automatyczny zestaw testów regresji przechodzi?” i “jak wyrazić to nowe wymaganie w systemie testów regresji?”.

Odpowiedziałbym na to w najbardziej matematyczny sposób, biorąc pod uwagę, że prosi o prawdopodobieństwo ze 100% pewnością siebie i całkowicie ignorując wpływ rozkładów statystycznych na taką liczbę: Powinieneś dać mu 2 lub 3 liczby, z towarzyszącą im pewnością siebie: 1 tydzień przy 90%, 2 tygodnie przy 95%, 6 miesięcy przy 100%. Ostatnia liczba była przesadą, ale jestem pewien, że masz rację.

Zobacz Wikipedia’s article on Confidence Intervals aby przeczytać więcej.