Najważniejsze pytanie dotyczące skalowania zwinności

Zdjęcie od Sohrab Salimi
Sohrab Salimi
4 min Czas czytania
Ta treść została przetłumaczona przez AI. Zobacz oryginał

Od niemal każdej dużej firmy, z którą pracujemy, słyszymy: „Potrzebujemy frameworku do skalowania zwinności." Kiedy 50 lub więcej deweloperów musi ze sobą współpracować, korzystanie z frameworku do skalowania jest rzeczywiście korzystne. Jednak jedno pytanie pozostaje bez odpowiedzi. Nad każdym podejściem do skalowania unosi się niczym widmo niewyartykułowane, niekwestionowane założenie. Zanim jednak zadamy to pytanie, przyjrzyjmy się powodom, dla których warto na nie odpowiedzieć.

Tworzenie złożonego produktu

Złożone systemy są złożone – choćby z definicji. Powszechnym założeniem jest, że Divide+Conquer (D+C) to dobre podejście do rozwiązywania złożonych problemów: dzielimy duży problem na wiele małych, rozdzielamy je i scalamy rozwiązania. Brzmi obiecująco.

Framework do skalowania może wtedy służyć maksymalizacji efektywności D+C.

Zacznijmy od pytań peryferyjnych, by zbliżyć się do pytania kluczowego:

Jak zdefiniować problem?

Kiedy zaczynasz tworzyć duży produkt, masz najpierw potrzebę – i chcesz zbudować produkt, który tę potrzebę zaspokoi. Natura wytwarzania produktów polega na tym, że rozwiązanie oparte na tej potrzebie jeszcze nie istnieje.

Czy problem jest w ogóle poprawnie opisany? Czy jest już wystarczająco jasne, na co idzie wysiłek? Czy domena wyzwania jest już na tyle czytelna, że D+C można sensownie zastosować?

Jaki jest prawdziwy problem?

Kiedy organizujesz wytwarzanie produktów, po prostu zakładasz, że potrzeba jest jasno zdefiniowana, a reszta to „tylko praca".

Ale co się stanie, jeśli nawet pytanie, na podstawie którego dokonano planowania, było od początku błędne? Co się stanie, jeśli plan zawiedzie i podążasz za złą odpowiedzią? Czy to pomoże, jeśli więcej osób będzie pracować nad złymi rzeczami?

Gdzie leży prawdziwy problem?

Podstawowe założenie skalowania zwinności: „Głównym problemem jest więcej pracy niż nieliczni mogą wykonać." Jak opisano w innym artykule, główny problem z dużą ilością pracy polega na tym, że dużo pracy powoduje jeszcze więcej pracy! Chodzi tu o pracę nietworzącą wartości – koordynację, przełączanie kontekstu, spotkania i tym podobne.

Czy kiedykolwiek zastanawiałeś się, jak duży jest udział pracy tworzącej wartość dla produktu w porównaniu z udziałem pracy nietworzącejwartości w procesach twojej organizacji? Ile czasu twoi deweloperzy poświęcają na koordynację z powodu złożoności struktur? Czy skupiasz się na dostarczaniu produktów, czy na przestrzeganiu procesów? Co dzieje się z narzutem, gdy rozszerzasz procesy? Co dzieje się z czasem poświęconym na tworzenie wartości?

Czy problem jest naprawdę tak duży?

Przy skalowaniu zwinności po prostu zakładasz, że potrzebujesz wielu ludzi, by zbudować planowany produkt. Kolejne pytanie brzmi wtedy: jak najlepiej zorganizować tych ludzi.

Czy wiesz, że Google we wczesnych latach tworzyły dwie osoby? A Facebooka jedna?

Czy twój produkt jest naprawdę tak duży, że przyćmiewa Google i Facebooka? Czy naprawdę zarobisz miliardy? Czy twoje rozumienie i podejście są naprawdę optymalne?

Czy „im więcej, tym lepiej"?


Książka „The Mythical Man-Month", napisana około 40 lat temu przez Fredericka P. Brooksa, już dawno obaliła przekonanie, że „im więcej osób pracuje nad produktem, tym szybciej zostanie ukończony". Ale nawet dziś wiele firm wciąż wierzy, że „skalowanie zwinności" jest rozwiązaniem „mitycznego człowieko-miesiąca". Jak wspomniano wcześniej, świetne produkty powstawały przy zaledwie kilku osobach – a więcej osób tworzy więcej pracy, ale nie więcej wartości!

Czy nie udałoby ci się znaleźć lepszego rozwiązania z mniejszą liczbą deweloperów i mniejszą ilością pracy? Czy naprawdę byłoby wolniej, gdyby zaangażowanych było mniej osób?

Po tak wielu pytaniach dochodzimy do kluczowego, decydującego pytania:

Czy „skalowanie zwinności" jest naprawdę konieczne?
Zadaj to pytanie, zanim zaczniesz skalować!

Weź pod uwagę następujące kwestie:

  • Czy deweloperzy mają 100% najlepszą wiedzę, by dostarczyć rozwiązanie?

  • Czy mają 100% najlepszą możliwą technologię do rozwiązywania problemów?

  • Czy deweloperzy są w 100% skupieni na dostarczaniu maksymalnej wartości?

  • Czy każda czynność w 100% tworzy wartość?

  • Czy praca jest wykonywana w 100% efektywnie?

Jeśli doda się więcej osób, te wartości procentowe zazwyczaj nie rosną. One maleją.

Gdy zsumuje się te wartości, wyniki są często przerażające. Może masz dziesięć osób, które mogą wykorzystać tylko 20% swojego potencjału – więc trzy osoby, które mogą wykorzystać 80% swojego potencjału, posuwałyby się szybciej!
Jeśli 100 deweloperów jest ograniczonych do 5% swojego potencjału, być może jeden zespół byłby bardziej efektywny niż wszyscy razem!

Czy zbadałeś wszystkie możliwości, by zrobić więcej z mniejszymi zasobami?

Tylko jeśli na wszystkie te pytania odpowiedź brzmi już „Tak" – wtedy odpowiedź na kluczowe pytanie również brzmi „Tak". Wcześniej będziesz skalować swoje problemy – a nie ich rozwiązanie!

Więcej na ten temat

Flight Levels w praktyce – Klaus Leopold

Ucz się od eksperta: Klaus Leopold prezentuje „Flight Levels w praktyce” w tym nagraniu z pierwszej konferencji agile100!

Skalowanie Agile: Frameworki i wskazówki eksperta

Dowiedz się więcej o różnych frameworkach do skalowania agile od naszego certyfikowanego Scrum Trainera Sohraba Salmiego i sprawdź, który pasuje do ciebie!

Wydania Minecrafta: Planowanie wersji z Henrikiem Knibergiem

Jak działa planowanie wydań w Minecrafcie? Henrik Kniberg opowiedział na agile100, jak planuje się wydania tak dużej gry!

Porozmawiaj z naszym asystentem Porozmawiaj z naszym asystentem