Adam Smith vs. programiści Fullstack - a produktywność w DevOps?

Według Adama Smitha podział pracy może sprawić, że będziesz 240 razy bardziej skuteczny (na przykład w fabryce szpilek produkującej szpilki w 18 krokach).

Dlaczego więc popyt na role wymagające wielu umiejętności jest tak pożądany, jeśli faktycznie zmniejsza produktywność - a może Smith po prostu się mylił, dlaczego?

Liczba wyszukiwań hasła „fullstack developer” nadal jest popularna w Google, jednak najwyraźniej wolniej niż dwa lata temu:

=====

Podsumowując, programista z pełnym stosem byłby w stanie wykonać praktycznie cały łańcuch wartości (popraw mnie, jeśli się mylę):

• Dyskutuj z klientami i dopracuj wykonalne wymagania zwinne dla jego części pracy
• Zdecyduj, którą architekturę, narzędzia i komponenty wybrać - po prostu daj mu notatnik
• Napisz kod dla frontendu, backendu, ingration, który jest kompatybilny z wieloma urządzeniami i nie wymaga wielu testów lub zawiera go
• Profiluj i scapeuj dane, korzystaj z API Cloud AI / ML dla zaawansowanych funkcji
• Podaj wymagany kod IaC i wdrożenie
• Bądź na telefon w przypadku błędów lub procesów sprzedaży
• Pamiętaj o projektach związanych z bezpieczeństwem, ogólnym łataniu, migracji i modernizacji
• Harmonogram konta w zdyscyplinowany sposób, aby ułatwić fakturowanie pracodawcy
• ... zapomniałem o czymś?

UPD - „ potrzebujemy produktywności specjalizacji, ale nie chcemy wyspecjalizowanego światopoglądu„ ekstremalnego podziału pracy ”. (DevOps Guys, „ DevOps, Adam Smith i legenda generalisty ” , 2013-2016)

Istnieją dwa rodzaje pracy:

1. Eksploatacja - dobrze zdefiniowana praca, którą można łatwo podzielić na dobrze zdefiniowane etapy, przy czym każdy etap można samodzielnie opanować i opanować, a przekazanie między etapami nie wymaga komunikacji.

2. Eksploracja - praca nieokreślona, ​​która wymaga uczenia się i eksperymentowania w celu osiągnięcia każdego etapu, a przekazanie między etapami wymaga ogromnej ilości komunikacji na temat całego procesu uczenia się i statusu projektu.

Adam Smith zajmuje się wyłącznie eksploatacją, a nie eksploracją. Praca wykonana w działach badań i rozwoju przemysłu jest z definicji głównie eksploracją, więc nie jest w żaden sposób objęta przez Adama Smitha.

Widzieliśmy jednak, że na późniejszych etapach ciągłego doskonalenia, które są częściowo pracą wyzyskującą, zastosowanie CI / CD może przynieść podobny wzrost wydajności, co prawdopodobnie może być przypisane Adamowi Smithowi przez kogoś bardzo pomysłowego.

Adam Smith nie musiał rozważać przekazywania informacji z jednego etapu na drugi. Jest to krytyczna część każdego znaczącego projektu informatycznego. Tak więc programista fullstack ma znaczące zalety, które:

• nie muszą rozmawiać z nikim w innym dziale, aby załatwić sprawę
• nie muszą czekać, aż inni ludzie się do tego zbliżą
• istnieje znacznie mniejsze prawdopodobieństwo, że coś zginie w tłumaczeniu między warstwami

Więcej informacji na temat znaczenia przekazywania informacji w projektach IT można znaleźć w Mythical Man Month Freda Brooka .

IMHO odpowiedź ma wiele wspólnego ze skalą i dostępnością zasobów.

Wierzę, że teorię Adama Smitha można zastosować tylko na dużą skalę - całe narody / gospodarki w oryginalnym kontekście lub, w kontekście rozwoju SW - duże zespoły programistyczne.

W dużym zespole efektywniej jest zatrudniać bardziej wyspecjalizowane zasoby ludzkie:

• nie są gwiazdami rocka - często uważane za znak niebezpieczeństwa w tak dużych organizacjach
• zazwyczaj są łatwiejsze do znalezienia, tańsze niż osoby o szerszym spektrum wiedzy specjalistycznej
• zazwyczaj nie zwiększają ryzyka ścierania - na przykład nie będą niezadowoleni, ponieważ wykorzystują tylko część swoich umiejętności.
• w (być może dziwnym) porównaniu dewopsji zasada „bydło kontra zwierzęta” może być stosowana w takich większych organizacjach i z całkiem podobnych powodów. Te wyspecjalizowane zasoby są z perspektywy biznesowej dosłownie tylko mieszkańcami w pulach zasobów ludzkich, których rozmiary można szybko dostosować w razie potrzeby, zazwyczaj poprzez zatrudnienie / zwolnienie.

Aha, i takie zespoły mogą funkcjonować tylko wtedy, gdy zostaną uzupełnione wysokiej jakości zasobami architekta, które byłyby konieczne do podzielenia produktu na mniejsze, wyspecjalizowane zadania, które można rozwiązać za pomocą wyspecjalizowanych zasobów.

W mniejszych zespołach, a nawet jednoosobowych zespołach (zazwyczaj startupach, a nawet izolowanych mniejszych zespołach w większych organizacjach) nieefektywne lub nawet niemożliwe jest użycie takich zasobów i nadal wykonywanie pracy:

• po prostu nie mają budżetu / zasobów na zatrudnienie wielu różnych specjalistycznych zasobów niezbędnych do pokrycia całego rozwoju produktu
• faktycznie szukają / doceniają gwiazdy rocka, które mogą nosić wiele czapek i natychmiast zmieniać role z wielką elastycznością, bez ponoszenia opóźnień i dodatkowych kosztów HR

Uważam się za programistę fullstack na podstawie następującej kombinacji obowiązków:

Programowanie interfejsu użytkownika i zaplecza

Mogę wprowadzać zmiany interfejsu użytkownika do pewnego stopnia: pisz HTML, CSS (jako programista), a z drugiej strony w pewnym stopniu dostarczaj dane do interfejsu użytkownika z bazy danych, udostępniaj w usłudze itp.

Odchodzę od testowania, architektury i odłożenia na bok. Spotkania z klientami mogą zostać dodane do opisu roboczego.

Naprzeciwko

Z mojego punktu widzenia przeciwieństwo to ścisłe role facetów z interfejsu użytkownika i facetów z zaplecza.

Wnioski

Nie widzę pełnego stosu tak naprawdę pełnego, jak wspomniałeś, bardziej przypominającego wymyślne wyrażenie, takie jak zwinne lub chmurowe, które w pewnych warunkach trzeba tylko wspomnieć, aby przyciągnąć uwagę ludzi, a rzeczywista implementacja może się znacznie różnić. Przynajmniej o scrumie i zwinności widziałem tak wiele odmian, że terminom zabrakło znaczenia.

Krótko mówiąc, nie sądzę, aby Adam Smith się mylił, ale sądzę, że istnieją poważne różnice między jego modelem podziału pracy w produkcji a silosami w tworzeniu oprogramowania.

Po pierwsze, przykład fabryki szpilek (o ile mi wiadomo) był jedynie hipotetyczny; chociaż większość współczesnych fabryk produkcyjnych ma swoje korzenie w tym podziale pracy, nie znam żadnych badań, które faktycznie przetestowałyby naukowo tę hipotezę.

Po drugie, Smith był przede wszystkim zainteresowany produkcją dóbr materialnych; istnieją pewne namacalne wyniki związane z produkcją materiałów, które nie mają podobnych analogów w tworzeniu oprogramowania. Na przykład przy wytwarzaniu pinów wymiary fizyczne są ważne jako wymóg funkcjonalny; nie ma oczywistego porównania z tym w oprogramowaniu. Jest to ważne, ponieważ materialne obiekty można powielać poprzez dokładne powtórzenie; tworzenie oprogramowania nigdy nie jest tym samym problemem dwa razy. Deweloperzy opracowują wspólne metody uzyskiwania przewidywalnych wyników, ale nigdy nie koduje się tego samego problemu dwukrotnie. Każdy element opracowany na stosie ma zawiłości w przeciwieństwie do składników fizycznych, a zawiłości te mają interakcje wykraczające poza namacalny pomiar (wysokość, waga, długość itp.). Szpilka nie obchodzi, jak działa obcinak do drutu, tak długo, jak drut zostanie przecięty zgodnie ze specyfikacją. W rozwoju oprogramowaniagranice nigdy nie są tak jasne .

Nie oczekuje się, że twórcy pełnego stosu wykonają całą pracę sami (nie mają być twórcami pojedynczych pinów), ale oczekuje się, że będą w stanie zrozumieć wszystkie elementy stosu i ich interakcje. Zespół z pełnym stosem powinien składać się z osób w kształcie litery T, które specjalizują się w jednym lub więcej obszarach, ale rozumieją spektrum (i mogą być w stanie wkroczyć na pewnym poziomie).

Uważam, że praca Smitha w dziedzinie tworzenia oprogramowania dotyczy przełączania kontekstów (lub wielozadaniowości ); jeśli jeden programista jest odpowiedzialny za wszystkie obszary rozwoju, przejście z odpowiedzialności na odpowiedzialność zajmuje trochę czasu. Na dużą skalę współpraca między członkami zespołu z różnymi doświadczeniami w tym samym zespole ds. Produktu może zrównoważyć przełączanie kontekstu i złożone interakcje.

Ważną kwestią do zrozumienia jest to, że podział pracy nie zawsze oznacza inną osobę na krok.

Wziąłbym własną historię w fabryce samochodów, byłem na łańcuchu montażowym siedzeń, aby uzyskać pełne siedzenie z poduszką powietrzną, skórą, zagłówkiem itp. Łańcuch został podzielony na 9 etapów. Pracowaliśmy nad łańcuchem 9. Każda osoba robiła tylko jeden etap na raz, ale co godzinę przechodziliśmy do następnego etapu, aby uniknąć zbyt dużej liczby powtórzeń. Dzień pracy trwał 8 godzin, więc nie wchodziliśmy na każdy etap każdego dnia.

Jest to dokładnie podział pracy, w którym wykonujesz tylko jeden krok zespołu w danym czasie, co nie przeszkadza ci w wykonaniu pełnego montażu.

Jak już wspomniano w innych odpowiedziach, jest to nieco inne niż tworzenie oprogramowania, ale myślę, że to wyjaśnia, dlaczego deweloper Full Stack nie wyklucza się wzajemnie z podziałem pracy, ktoś, kto jest w stanie obsłużyć cały cykl życia aplikacji, nie jest musi to robić cały czas.

Ogólnie mówiąc, kiedy słyszę programistę FullStack, myślę bardziej o kimś, kto potrafi jednocześnie kodować wydajne back-endy i przyjemny interfejs użytkownika, w przeciwieństwie do Front i Back Dev.