10 warunków skalowalności, które trzeba znać przed skalowaniem

Jeśli wystarczająco długo działasz w branży tworzenia oprogramowania, najprawdopodobniej doświadczyłeś tego koszmaru:

1. Klientowi obiecuje się wiele funkcji w nierealistycznie krótkim czasie (którego nikt nie ma odwagi zakwestionować).
2. Później, gdy termin niebezpiecznie się zbliża, ktoś mający władzę postanawia rzucić do problemu więcej zespołów, aby dotrzymać terminu.
3. Wszystko zaczyna się rozpadać.

Brzmi znajomo?

W tym artykule wyjaśnię, co należy zrobić, aby uniknąć ponownego znalezienia się w takiej koszmarnej sytuacji (a jeśli miałeś wystarczająco dużo szczęścia, by jej nie doświadczyć — aby całkowicie jej uniknąć).

Moje spostrzeżenia zawarte w tym artykule wynikają ze skalowania zespołów tworzących oprogramowanie, ale podstawową teorię możesz zastosować do skalowania firmy lub powiększania zespołu w dowolnej branży. Będzie to przydatne nawet wtedy, gdy wdrażasz jeden z gotowych modeli skalowania — Large Scale Scrum (LeSS), Scrum@Scale, SAFe.

Dzieje się tak, ponieważ skupiam się na kilku ważnych aspektach skalowalności, o których te metodyki nigdy nie wspominają — na fundamentalnej prawdzie dotyczącej natury skalowania, o której często się zapomina lub ją ignoruje.

Fundamentalne prawo skalowania

Fundamentalne prawo skalowania to empiryczna obserwacja tego, co dzieje się w projektach podczas ich skalowania:

Skalowanie wzmacnia to, co złe, i utrudnia to, co dobre.

To ja sformułowałem te słowa, ale nie jestem ani jedyną, ani pierwszą osobą, która doszła do tego spostrzeżenia.

Zobaczmy na przykładach skalowalności, co to prawo oznacza w praktyce.

1. Przykład: komunikacja i skalowalność

Pierwszym i najbardziej oczywistym przykładem jest komunikacja. Powszechnie wiadomo, że gdy rośnie liczba osób w projekcie, rośnie również liczba kanałów komunikacji. Jeśli kanały komunikacji od początku nie są wystarczająco dobre, skalowanie pogorszy problem.

Z drugiej strony, jeśli kanały komunikacji od początku są dobre, skalowanie wprowadzi pewne wyzwania wynikające nie tylko ze zwiększonej liczby osób, lecz także z ich rozmieszczenia. Często nowe zespoły powstają w różnych lokalizacjach, co wymusza zmiany w kanałach komunikacji — na przykład przejście ze spotkań bezpośrednich na wideokonferencje albo zastąpienie tablicy białej narzędziem elektronicznym.

2. Przykład: ciągła integracja, ciągłe dostarczanie i skalowalność

Fundamentalne prawo skalowania obserwujemy również w potokach ciągłej integracji (CI) i ciągłego dostarczania (CD). Gdy istnieje tylko jeden zespół, wszystko jest dość proste.

Przejście z jednego zespołu do dwóch sprawia, że systemy CI i CD stają się bardziej skomplikowane — zazwyczaj, gdy istnieje n zespołów, liczba potoków CI wynosi n+1 (po jednym potoku na zespół oraz jeden do integracji). Ma to oczywiste konsekwencje dla udostępniania środowisk oraz koordynacji między zespołami.

3. Przykład: pętle informacji zwrotnej i skalowalność

Ostatni przykład to pętle informacji zwrotnej. Większe projekty mają dłuższe pętle informacji zwrotnej. Dlatego iteracyjne udoskonalanie systemu staje się znacznie trudniejsze, co zwiększa prawdopodobieństwo stworzenia niewłaściwego produktu.

To tylko trzy przykłady niektórych wyzwań wprowadzanych przez skalowanie. Jestem pewien, że potrafisz wskazać wiele kolejnych.

Załóżmy, że jesteś gotów zaakceptować związane z tym kompromisy. Kolejną rzeczą, której potrzebujesz, jest spełnienie przez projekt kilku ważnych warunków wstępnych, aby potwierdzić jego skalowalność.

10 warunków wstępnych skalowania

To, czy masz skalowalną firmę, projekt lub zespół, zależy od kilku wymienionych poniżej warunków wstępnych. Jeśli je spełnisz, będziesz mieć wysoką skalowalność. Z drugiej strony, jeśli którykolwiek z nich nie zostanie spełniony, prawdopodobieństwo niepowodzenia drastycznie wzrośnie.

1. Obecność jasnych, wspólnych celów

Powinno to być oczywiste, ale z mojego doświadczenia wynika, że brak jasnych, wspólnych celów jest niezwykle częsty. Bez nich zespoły będą podążać w różnych kierunkach, co utrudni dostarczenie czegoś użytecznego.

2. Stosowanie odpowiednich mierników

Im większy projekt, tym ważniejsza jest możliwość mierzenia wpływu podejmowanych decyzji. Na przykład: czy dodanie nowego zespołu poprawiło zdolność projektu do realizacji zadań? Czy wywieramy na zespoły tak dużą presję, że jakość spada? Czy zespoły dobrze ze sobą współpracują, czy też wzajemnie sobie przeszkadzają?

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

3. Odpowiednia architektura

Jeśli „kształt” systemu nie odpowiada strukturze zespołów, dodanie kolejnych zespołów tylko pogorszy sytuację. Jest to bezpośredni skutek prawa Conwaya — dobrze znanej obserwacji empirycznej, której słuszność potwierdzono w praktyce.

4. Dostępność umiejętności menedżerskich i technicznych

Problemy wynikające z braku umiejętności będą miały zwielokrotniony negatywny wpływ wraz ze zwiększaniem skali projektu.

5. Dobre kanały komunikacji

Im więcej osób jest zaangażowanych, tym więcej zachodzi komunikacji. Pomyślne zwiększanie skali wymaga usprawnionej komunikacji.

6. Dobre ustalanie priorytetów i planowanie

Brak odpowiedniego ustalania priorytetów i planowania jest, z mojego doświadczenia, bardzo częstym czynnikiem niepowodzeń projektów. W szczególności, gdy zaangażowany jest więcej niż jeden zespół, działania związane z ustalaniem priorytetów i planowaniem muszą uwzględniać sposoby łagodzenia skutków opóźnień i braku synchronizacji.

7. Dobre pozyskiwanie i zarządzanie wymaganiami

Jest to ściśle związane z ustalaniem priorytetów i planowaniem. Ponadto wpływ błędnych, źle zrozumianych lub niepotrzebnych wymagań będzie się zwiększał wraz ze wzrostem liczby zespołów.

8. Praca wysokiej jakości

Im większy projekt, tym większy negatywny wpływ niskiej jakości. W niektórych patologicznych (i częstych) sytuacjach pewne błędy mogą stać się funkcjami, ponieważ pętle informacji zwrotnej potrzebne do ich naprawienia mogą być tak długie, że inne zespoły zdążą zaprojektować obejścia neutralizujące ich skutki.

9. Dostępność zasobów

Więcej zespołów potrzebuje większej liczby biurek, komputerów, narzędzi i środowisk.

10. Bezwzględna automatyzacja

Każda ręczna czynność jest wąskim gardłem, którego skutki nasilają się wraz ze wzrostem liczby osób i zespołów. Bardzo częsty przykład stanowią ręczne działania testowe mające zapewnić, że przed wydaniem wersji produkcyjnej nie wprowadzono regresji. Z mojego doświadczenia wynika, że jest to jedno z największych wąskich gardeł w każdym projekcie, ale szczególnie w projektach, w których pracuje więcej niż jeden zespół.

Uważaj na zbyt wczesne zwiększanie skali

Skalowalność jest jednym z najważniejszych tematów dla startupów i seryjnych przedsiębiorców — a oni mają nam co nieco do powiedzenia na temat zbyt wczesnego zwiększania skali.

Jeśli podejmiesz próbę zwiększenia skali, zanim naprawdę spełnisz warunki wstępne pomyślnego zwiększenia skali firmy, zespołu lub organizacji, otrzymasz to, co społeczność startupowa nazywa „zbyt wczesnym zwiększaniem skali”.

Prosta definicja zbyt wczesnego zwiększania skali autorstwa seryjnego przedsiębiorcy Jima Pitkowa:

Zbyt wczesne zwiększanie skali: rozwój w oczekiwaniu na popyt zamiast rozwoju napędzanego popytem.

Właściwe zwiększanie skali rzeczywiście wymaga czasu — a prawdziwa skalowalność jest napędzana rzeczywistą potrzebą zwiększenia skali wynikającą z popytu, a nie sztucznie narzuconym przekonaniem, że należy po prostu stać się większym i szybciej robić więcej rzeczy.

Społeczność startupowa oferuje kilka lekcji, które możemy przenieść do naszych zespołów i projektów, gdy zastanawiamy się, czy nadszedł czas na zwiększenie skali. Oto kilka statystyk z raportu Startup Genome Report Extra dotyczącego zbyt wczesnego zwiększania skali:

• Startupy, które właściwie zwiększają skalę, potrzebują o 76% więcej czasu, aby osiągnąć docelową wielkość zespołu, niż startupy, które zwiększają skalę zbyt wcześnie.
• 74% szybko rozwijających się startupów internetowych upada z powodu zbyt wczesnego zwiększania skali.
• Startupy, które właściwie zwiększają skalę, rozwijają się około 20 razy szybciej niż startupy, które zwiększają skalę zbyt wcześnie.

Jeśli interesuje Cię więcej statystyk dotyczących przedsiębiorczości, zapoznaj się z naszym badaniem na temat najbardziej przedsiębiorczych stanów Ameryki.

Czy naprawdę jesteś gotowy na zwiększenie skali?

Jeśli Twój projekt jest dobrze prowadzony i spełnia powyższe warunki wstępne, kolejne pytanie powinno brzmieć:

„Ile zespołów może produktywnie wnosić swój wkład?”

Odpowiemy na to pytanie w następnej sekcji.

Jaka jest granica skalowalności? Prawa Brooksa i Amdahla

Jest powszechnie wiadomo, że dodanie większej liczby osób do projektu programistycznego niekoniecznie zwiększy produktywność.

W rzeczywistości w większości przypadków dodanie większej liczby osób spowoduje znaczny spadek produktywności.

Fred Brooks poczynił tę obserwację w swojej książce Mityczny osobomiesiąc, która stała się znana jako prawo Brooksa:

„Dodanie pracowników do opóźnionego projektu programistycznego jeszcze bardziej go opóźnia […] Liczba miesięcy trwania projektu zależy od jego ograniczeń sekwencyjnych. Maksymalna liczba osób zależy od liczby niezależnych podzadań. Na podstawie tych dwóch wartości można opracować harmonogramy z mniejszą liczbą osób i większą liczbą miesięcy[…]. Nie można jednak uzyskać wykonalnych harmonogramów, wykorzystując większą liczbę osób i mniejszą liczbę miesięcy”.

Druga połowa powyższego cytatu jest moim zdaniem najciekawsza. W rzeczywistości jest to zasadniczo wersja prawa Amdahla wyrażona prostym językiem — wzoru określającego maksymalne teoretyczne przyspieszenie systemu współbieżnego:

Prawo Amdahla

Przyspieszenie = 1 / (s + p / n )

Gdzie:

s = procent zadań szeregowych

p = procent zadań równoległych

s + p = 1

n = liczba procesorów (w naszym przypadku zespołów)

W rzeczywistości projekt realizowany przez wiele zespołów jest rodzajem systemu współbieżnego, w którym każdy zespół stanowi jednostkę przetwarzającą. W praktyce prawo Amdahla mówi, że maksymalna ilość pracy współbieżnej jest ograniczona ilością pracy szeregowej, którą należy wykonać.

Mówiąc prościej, oznacza to, że zadania, które należy wykonać w określonej kolejności, ograniczają ilość pracy, nad którą zespoły mogą pracować jednocześnie.

Czym jest praca szeregowa w kontekście tworzenia oprogramowania?

Możesz się zastanawiać, jaki rodzaj pracy szeregowej wpływa na zespoły programistyczne.

Oto kilka przykładów (z pewnością możesz wymyślić wiele innych):

• Wszelkie prace związane z potokami integracji i wdrażania
• Scalanie zmian w oprogramowaniu w kodzie współdzielonym przez różne zespoły
• Wszelkiego rodzaju synchronizacja — na przykład sytuacja, w której zespół zależy od rezultatów pracy innego zespołu, zanim będzie mógł kontynuować swoje zadania
• Oczekiwanie na udostępnienie zasobów

Zastosowanie prawa Amdahla do skalowania zespołów

Poniższy wykres przedstawia wpływ prawa Amdahla na produktywność przy zwiększaniu liczby zespołów.

Widzimy, że produktywność będzie rosła w sposób podliniowy wraz ze wzrostem liczby zespołów — aż do osiągnięcia maksimum, po którym ponownie zacznie spadać.

Ilustracja prawa Amdahla: przepustowość rezultatów rośnie wraz z liczbą zespołów, ale tylko do pewnego momentu — a zazwyczaj nie jest to wynik, na który liczą menedżerowie.

Jeśli z tego artykułu zapamiętasz tylko jedną rzecz, niech będzie nią ta:

Zwiększenie liczby zespołów może zwiększyć przepustowość — ale tylko do pewnego momentu.

Jaka jest więc idealna liczba zespołów dla danego projektu?

Niestety nie ma równań pozwalających z wyprzedzeniem obliczyć idealną liczbę zespołów dla danego projektu. Jedynym sposobem jest wykorzystanie zestawu miar projektowych do pomiaru takich kwestii jak produktywność i jakość oraz obserwowanie, co się dzieje po dodaniu lub usunięciu zespołów. Zalecam rozpoczęcie od małego zespołu liczącego 3–6 osób i zwiększanie jego liczebności tylko wtedy, gdy jest to konieczne.

W pewnym momencie możesz odkryć, że osiągnięto już maksymalną liczbę zespołów, ale projekt nadal nie jest w stanie wywiązać się ze swoich zobowiązań. Wtedy przydają się umiejętności ustalania priorytetów i komunikacji, ponieważ możesz być zmuszony do przeprowadzenia trudnych rozmów z klientami.

Rozważania dotyczące struktury zespołu: zespoły funkcjonalne czy komponentowe?

Jak nowy zespół dodany do projektu powinien pracować? Na początek zadaj sobie te dwa pytania:

1. Czy będą odpowiedzialni za kompleksowe opracowywanie funkcji widocznych dla klienta, czy za osiąganie celu poprzez wprowadzanie zmian w systemie?
2. Czy będą odpowiedzialni za pracę nad konkretnym komponentem zapewniającym część funkcjonalności widocznej dla użytkownika?

Jeśli odpowiedź na pytanie nr 1 brzmi „tak”, zespół będzie zespołem funkcjonalnym.

Jeśli odpowiedź na pytanie nr 2 brzmi „tak”, będzie zespołem komponentowym.

Wskazówki dotyczące wyboru odpowiedniej struktury zespołu

Wybór odpowiedniej struktury i organizacji zespołu jest bardzo ważny, ale nie jest łatwy. Obecnie zespoły funkcjonalne wydają się preferowaną opcją w większości sytuacji. Jednak ten wybór często opiera się na przyzwyczajeniu lub rutynie, a nie na danych.

Rzeczywistość jest taka, że „to zależy”. Mówiąc dokładniej, zależy to od architektury systemu. Projekty programistyczne zwykle podążają za tym, co znane jest jako prawo Conwaya — empiryczną obserwacją Melvina Conwaya:

„Organizacje, które projektują systemy… są ograniczone do tworzenia projektów będących kopiami struktur komunikacyjnych tych organizacji”

Innymi słowy, „kształt” struktury zespołów musi odpowiadać „kształtowi” systemu, w przeciwnym razie projekt napotka poważne problemy.

Dlatego zawsze zalecam menedżerom angażowanie starszych architektów i liderów technicznych w decyzje dotyczące struktury zespołów — w przeciwnym razie menedżerowie faktycznie projektują system, nie zdając sobie z tego sprawy (i nie mając odpowiednich umiejętności). To z kolei może znacznie zwiększyć ryzyko niepowodzenia projektu.

Dwa paradoksy skalowalności

Na podstawie mojego doświadczenia jako konsultanta przy wielu projektach realizowanych na dużą skalę doszedłem do wniosku, że w większości przypadków projekty są skalowane z niewłaściwych powodów.

Opracowałem dwa paradoksy, które podsumowują to, co obserwowałem w praktyce:

Pierwszy paradoks skalowania

Większość projektów jest rozbudowywana, ponieważ nie spełnia warunków wstępnych skalowania

Drugi paradoks skalowania

Projekty spełniające warunki wstępne skalowania mają mniejszą potrzebę skalowania

Pierwszy paradoks mówi, że w większości sytuacji projekty postępują powoli po prostu dlatego, że nie są dobrze zarządzane.

Drugi mówi, że dobrze zarządzane projekty będą miały mniejszą potrzebę skalowania po prostu dlatego, że są dobrze zarządzane.

W rzeczywistości najbardziej produktywne projekty, które widziałem, miały tylko jeden lub dwa małe zespoły i spełniały wszystkie warunki wstępne skalowania. Spośród wszystkich projektów realizowanych na dużą skalę, w które byłem zaangażowany, nie widziałem ani jednego, w którym spełnione byłyby wszystkie warunki wstępne skalowania. W rzeczywistości wszystkie miały wiele problemów ze spełnieniem któregokolwiek z tych warunków.

Jeśli uczestniczysz w projekcie, w którym występują problemy i opóźnienia, najlepszym zaleceniem, jakie mogę dać, jest uporządkowanie bałaganu poprzez zmniejszenie skali, zanim rozważysz zwiększenie skali projektu.

Najważniejsze wnioski dotyczące właściwego skalowania zespołów

Skalowanie zespołów programistycznych nie jest łatwe i wymaga zachowania szczególnej ostrożności. Na zakończenie przedstawiam kilka przemyśleń dotyczących znalezienia najskuteczniejszego sposobu skalowania zespołu programistycznego:

1. Jeśli skoncentrujesz się na spełnieniu warunków wstępnych skalowalności, możesz odkryć, że warto utrzymać niewielki zespół i uniknąć wszystkich problemów związanych z większym rozmiarem.
2. Z drugiej strony, jeśli Twój projekt jest już duży i boryka się z problemami, najpierw skup się na uporządkowaniu bałaganu poprzez zmniejszenie skali.

Oto pierwsze kroki, które sugeruję podjąć po przeczytaniu tego artykułu:

1. Dowiedz się, co dzieje się w praktyce
2. Wprowadź pewne wskaźniki, aby móc ocenić bieżącą sytuację, a także jakość podejmowanych decyzji.