Jakie są sposoby na złagodzenie skutków Miesiąca Mitycznego Człowieka?

Prawo Brooksa: dodanie siły roboczej do późnego projektu oprogramowania czyni to później.

W swojej książce No Silver Bullet - Istota i wypadki inżynierii oprogramowania Frederick Brooks definiuje koncepcję miesiąca mitycznego człowieka :

Założeniem Brooksa jest to, że złożonych projektów programistycznych nie można idealnie podzielić na odrębne zadania, nad którymi można pracować bez komunikacji między pracownikami i bez ustanawiania zestawu złożonych wzajemnych powiązań między zadaniami a pracownikami je wykonującymi .

Od 1982 roku z pewnością posunęliśmy się naprzód i zebraliśmy trochę doświadczenia w łagodzeniu tego problemu. Jakie są rozwiązania, które z powodzeniem zastosowałeś w swojej pracy, aby dodać zasoby do projektu bez powodowania dodatkowych problemów.

Co to jest MMM

Najpierw chcę wyjaśnić kontekst prawa Brook'a. Jakie założenie skłoniło go do stworzenia go w 1975 roku?

Miesiąc roboczy to hipotetyczna jednostka pracy reprezentująca pracę wykonaną przez jedną osobę w ciągu jednego miesiąca; Prawo Brooksa mówi, że nie można zmierzyć użytecznej pracy w ciągu osobo-miesięcy.

^{źródło: https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

W przeszłości złożone projekty programistyczne oznaczałyby duże systemy monolityczne. Brooks twierdzi, że nie można ich idealnie podzielić na odrębne zadania, nad którymi można pracować bez komunikacji między programistami i bez ustanawiania zestawu złożonych relacji między zadaniami a osobami je wykonującymi.

Jest to bardzo prawdziwe w przypadku bardzo spójnych monolitów oprogramowania. Bez względu na to, jak wiele oddzielenia zostało zrobione, wciąż duży monolit nakazuje czas potrzebny nowym programistom na poznanie monolitu. Zwiększony narzut komunikacji, który zużywa coraz więcej dostępnego czasu.

Ale czy tak naprawdę musi tak być? Czy musimy pisać monolity i utrzymywać kanały komunikacji n(n − 1) / 2tam, gdzie njest liczba programistów?

Wiemy, że istnieją firmy, w których tysiące programistów pracuje nad dużymi projektami ... i to działa. Musi więc coś się zmienić od 1975 roku.

Możliwość ograniczenia MMM

W 2015 r. PuppetLabs i IT Revolution opublikowały wyniki raportu o stanie DevOps z 2015 r . W raporcie skupiono się na rozróżnieniu między organizacjami o wysokich wynikach a organizacjami o niższych wynikach.

Wysoko wydajne organizacje wykazują nieoczekiwane właściwości. Na przykład, mają najlepszą wydajność w czasie realizacji projektu. Najlepsza stabilność operacyjna i niezawodność w działaniu. Jak również najlepsze osiągnięcia w zakresie bezpieczeństwa i zgodności.

Jedną z zaskakujących rzeczy podkreślonych w raporcie jest liczba wdrożeń na dzień. Ale nie tylko wdrożenia dziennie, zmierzyli także wdrożenie / dzień / programistę i jaki jest efekt dodania większej liczby programistów w organizacjach o wysokiej wydajności w porównaniu do organizacji o niskiej wydajności.

To jest wykres z tego raportu -

Podczas gdy organizacje o niskiej wydajności dostosowują się do założeń Mythical Man Month. Wysoko wydajne organizacje mogą liniowo skalować liczbę wdrożeń / dni / deweloperów w zależności od liczby programistów.

Doskonała prezentacja Gene Kim na DevOpsDays London 2016 mówi o tych ustaleniach.

Jak to zrobić

Po pierwsze, jak zostać organizacją o wysokich wynikach? Jest kilka książek, które mówią o tym, za mało miejsca w tej odpowiedzi, więc po prostu będę do nich link.

• Dobry do wielkiego: dlaczego niektóre firmy robią skok ... a inne nie. Jim Collins
• High-Velocity Edge: jak liderzy rynku wykorzystują doskonałość operacyjną, aby pokonać konkurencję Stevena Speara
• Nowa ekonomia dla przemysłu, rządu, edukacji W. Edwardsa Deminga

W przypadku oprogramowania i organizacji IT jednym z kluczowych czynników umożliwiających uzyskanie wysokiej wydajności organizacji jest: skupienie się na jakości i szybkości .

Na przykład Ward Cunningham wyjaśnia Dług Techniczny jako wszystkie rzeczy, które pozwolono nam pozostawić nierozwiązane. Jest to akceptowane przez kierownictwo, ponieważ zawsze wiąże się z obietnicą, że zostanie to naprawione w odpowiednim czasie.

Nigdy nie ma wystarczająco dużo czasu, a zadłużenie techniczne staje się coraz gorsze.

Co powoduje wzrost długu technicznego?

• starszy kod
• ręczna konfiguracja środowisk
• testowanie ręczne
• ręczne wdrożenia

Starszy kod Zgodnie z definicją podaną w części „Efektywna praca ze starszym kodem” autorstwa Michaela Feathersa, każdy kod, który nie ma automatycznego testowania.

Wszelkie skróty czasowe służą do wprowadzenia kodu do produkcji; operacje są obciążone utrzymywaniem tego długu na zawsze. Następnie proces wdrażania staje się coraz dłuższy.

Gene w swojej prezentacji opowiada historię firmy, która ma sześciotygodniowe wdrożenia. Zaangażowanie dziesiątek tysięcy wyjątkowo podatnych na błędy żmudnych kroków, wiążących 400 osób, i robiliby to cztery razy w roku.

Jednym z założeń DevOps jest to, że niezawodność wynika z częstszego wykonywania mniejszych wdrożeń.

Przykład

• Jon Jenkins na Velocity 2011 : Amazon dokonuje 15 tys. Wdrożeń dziennie
• Ken Exner na AWS Summit 2015 : Amazon wykonuje 136 tys. Wdrożeń dziennie

Te dwie prezentacje pokazują wszystkie rzeczy, które Amazon zrobił, aby skrócić czas potrzebny na wdrożenie kodu na produkcji.

Według Gene'a jedyną rzeczą, która zmienia się w czasie w tych wysoko wydajnych organizacjach, jest liczba programistów. Tak więc na przykładzie Amazona można powiedzieć, że w ciągu czterech lat zwiększyli swoje wdrożenia dziesięciokrotnie, dodając więcej osób.

Oznacza to, że pod pewnymi warunkami, przy odpowiedniej architekturze, właściwych praktykach technicznych, właściwych normach kulturowych, produktywność programistów może rosnąć wraz ze wzrostem liczby programistów. DevOps jest zdecydowanie w środku tego wszystkiego.

To, co zrobiłem (i to jest tylko subiektywne), jest następujące:

Kiedy kierownik myślący o terminie chce dodać ludzi do mojego zespołu, aby skrócić potrzebny czas i wydaje się być w MMM, najpierw dyskutuję z nim, dlaczego to może być złe. Moją ulubioną analogią jest przypomnienie im, że jeśli jedna kobieta może urodzić dziecko za dziewięć miesięcy, dziewięć kobiet nie będzie mieć jednego dziecka za miesiąc, ale urodzi dziewięć dzieci za dziewięć miesięcy. Czas nie jest skrócony, tylko przetwarzanie równoległe jest lepsze.

Gdy decyzja jest wymuszana na naszym zespole, zwykle staramy się albo dalej dzielić niektóre zadania, a gdy nie jest to możliwe, zwykle polegamy na programowaniu par , w którym jeden programista jest odpowiedzialny za pisanie, a drugi dyktuje kod (i okresowo przełącza się ).

Samo pisanie kodu jest wolniejsze, ale podczas testowania jest mniej literówek / błędów i błędów z powodu nieuniknionej recenzji podczas pisania. Wydaje mi się, że ogólna jakość kodu jest również nieco lepsza, ale nie mam danych, które by to potwierdzały.

Mówiąc wyłącznie z perspektywy CI, zwiększenie liczby programistów pracujących nad projektem zazwyczaj przekłada się na większą liczbę osób pracujących w tej samej branży.

Tradycyjne systemy CI mają pod tym względem problem ze skalowalnością: prawdopodobieństwo awarii / regresji / blokad zwiększa spowolnienie prędkości integracji i zaprasza mniejsze zespoły do ​​zerwania i przejścia do oddziałów potomnych (tj. Dalsze spowolnienia). Zobacz Jak można skalować ciągłą integrację bardzo dużych projektów / zespołów? . Jest to zgodne z koncepcją Mythical Man Month.

Rozwiązanie, które sugeruję w odpowiedzi na to pytanie, wysoce skalowalny system CI umożliwi migrację w kierunku prawdziwego CI - integracja oparta na pojedynczej gałęzi / magistrali dla całych większych zespołów (nawet przy dużych rozmiarach).

Dzięki wszystkim na tej samej stronie, korzystającym z tych samych zautomatyzowanych narzędzi / procesów i znacznej większości weryfikacji jakości zautomatyzowanych w samym systemie CI, znacznie łatwiej jest zmieniać role i skupiać się między członkami zespołu. Cały proces rozwoju staje się płynniejszy, bardziej przewidywalny, bardziej zrelaksowany.

Wprowadzanie nowych ludzi na pokład w takim środowisku, zwiększanie produktywności poprzez odciążenie mniej trudnych zadań od bardziej doświadczonych członków zespołu, którzy mogą następnie podjąć trudniejsze, jest łatwiejsze.

Wszystko to, jak sądzę, można postrzegać jako kojące efekty koncepcji Miesiąca Mitycznego Człowieka.