8 maja 2017

Gdzie jest majster?

Majster na budowie to człowiek odpowiedzialny za to, że wszyscy pracownicy robią to, co powinni. On jest tym człowiekiem z miarką, który kręci się dookoła i upewnia się, że wszystkie ściany są ustawione odpowiednio. On jest tym człowiekiem, który sprawdza wszystkie rozpórki, spoiny i belki, aby upewnić się, że są zmontowane odpowiednio i nie mają żadnych znaczących uszkodzeń. On jest tym człowiekiem, który liczy wkręty w podłodze, aby upewnić się, że podłoga nie będzie skrzypieć, jeżeli będziesz po niej chodzić. On jest tym człowiekiem -- człowiekiem, który bierze na siebie odpowiedzialność -- człowiekiem, który upewnia się, że wszystko jest robione właściwie.

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony:
https://8thlight.com/blog/uncle-bob/2014/02/21/WhereIsTheForeman.html
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


Gdzie jest majster naszych projektów budowy oprogramowania? Gdzie jest człowiek, który upewnia się, że wszystkie testy zostały napisane? Gdzie jest człowiek, który upewnia się, że wszystkie wyjątki zostały obsłużone. Gdzie jest człowiek, który upewnia się, że błędy są sprawdzone i obiekty nie są nullami i zmienne są bezpieczne dla wielu wątków. Gdzie jest człowiek, który upewnia się, że programiści wystarczająco programują w parach, wystarczająco rozmawiają ze sobą, wystarczająco planują? Gdzie jest człowiek, który sprawia, że podłogi nie skrzypią?

Bez dobrego majstra budowa pogrążyłaby się w chaosie. Ściany nie schodziłyby się. Drzwi wisiałyby krzywo. Zimna woda wypływałaby z gorącego kurka, a gorąca woda z zimnego. Bez dobrego majstra podłoga i dach przeciekałyby i z kominka dymiłoby do salonu. Bez dobrego majstra budowa skończyłaby się dużo po czasie, daleko poza budżetem i w nędznej jakości.

Bez majstra podłogi skrzypiałyby.



Co robiłby majster na projekcie budowy oprogramowania? Robiłby to samo, co na budowie.  Upewniałby się, że wszystko zostało zrobione, zrobione dobrze i zrobione na czas. Byłby jedynym z prawami do kommitów. Wszyscy inni wysyłaliby mu pull requesty. On przeglądałby każdy request po kolei i odrzucałby te które nie miałyby odpowiedniego pokrycia testami albo miałyby burdel w kodzie, albo złe nazwy zmiennych, albo funkcje byłyby za długie. On odrzucały te, które w jego mniemaniu nie spełniają poziomu jakości żądanego dla tego projektu.

Mogę sobie wyobrazić, że wielu programistów odrzuca pomysł, że ktoś inny ma władzę oceny ich kodu i odrzucania ich kommitów. No bo przecież, jak można dostarczyć na czas całą tę funkcjonalność, jeżeli kod ma być jeszcze czysto napisany? Jak możesz dotrzymać harmonogramu, jeżeli musisz jeszcze napisać te wszystkie testy? Mam na myśli to, że jeżeli będzie człowiek, który w rzeczywistości będzie patrzył na kod, nie będzie możliwości postawienie siebie w dobrym świetle, mówiąc, że kod jest skończony, jeżeli w rzeczywistości nie będzie. To byłoby okropne.

Okropne czy nie, tak właśnie robi większość branż. Jeżeli chcesz mieć robotę zrobioną, zrobioną dobrze i zrobioną na czas to potrzebujesz majstra.  I ten majster musi być technicznie wnikliwy, aby móc sprawdzić pracę, wszystkich pracowników. On musi mieć prawo do odrzucania każdej pracy, którą uważa za poniżej standardów. I on także musi mieć władzę, aby móc powiedzieć "Nie" nierealnym żądaniom klientów i menedżerów.

Gdzie jest majster naszych projektów informatycznych? Gdzie jest człowiek z jedynymi prawami do kommitów? Gdzie jest człowiek, który upewnia się, że wszystkie testy są napisane i wszystkie warstwy abstrakcji są rozdzielone i wszystkie zależności są odwrócone?


Dlaczego nie mamy takiego człowieka?

Czy można się jeszcze dziwić, że nasze podłogi skrzypią?




Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony:
https://8thlight.com/blog/uncle-bob/2014/02/21/WhereIsTheForeman.html
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


2 komentarze:

  1. A kto powiedział że majstrem nie może być cały zespół? Dobry SM ma właśnie za zadanie doprowadzić do takiej sytuacji gdzie każdy członek zespołu czuje odpowiedzialność A nie tylko jakiś wybraniec. Lider, kapitan zespołu w grupie tak. Ale to nie rodzaj audytora tylko drogowskaz dla reszty którędy podążać.
    Ale taka konstrukcja jest o rząd wielkości trudniejsza do zbudowania niż setup z majstrem. Boję się że częściej mamy majstrow, albo SM z mentalnością audytora, dla tego software trzeszczy i skrzypi...

    OdpowiedzUsuń
    Odpowiedzi
    1. Cześć Artur,

      Dzięki za komentarz.
      Słusznie zauważyłeś, że majster to rola i może być spełniana przez jednego człowieka i może być spełniana przez grupę ludzi. Jednak, tak jak piszesz profesjonalizm w grupie nie rozprzestrzenia się łatwo, a już na pewno nie rozprzestrzenia się samoczynnie. Warto więc zacząć od jednego człowieka.

      Usuń

Podstawy Programowania Funkcyjnego Epizod 3

Czy wszystkie Zasady Się Zmieniają? Kiedy tylko zaczynamy używać nowego paradygmatu , porównujemy z nim na...