Nie jesteś „zwinny", gdy… modele hybrydowe

Rozmowy, które prowadziłem z kolegami, czytelnikami mojego bloga oraz profesorem z Pennsylvania State University na temat takich przeszkód, wywołały pełne pasji dyskusje o względnej wartości i użyteczności modeli hybrydowych.

Waterfall

Klasyczne metody wytwarzania oprogramowania są jak waterfall, który zaczyna się od definiowania wymagań, a kończy na implementacji. Praca jest wykonywana w poszczególnych krokach wzdłuż etapów tego wodospadu – podobnie jak praca przy taśmie montażowej w produkcji samochodowej. Produkt jest gotowy do użycia dopiero po zejściu z taśmy na końcu. W tym modelu określone prace są zawsze wykonywane przez tych samych wyspecjalizowanych ekspertów. Henry Ford zrewolucjonizował rynek motoryzacyjny tą metodą.

Ten rodzaj wytwarzania oprogramowania może jednak sprzyjać wszelkiego rodzaju negatywnym zachowaniom. Powodem jest zazwyczaj niezgodność pracy taśmowej (np. w produkcji) z bardziej dynamiczną pracą, która jest bardziej ukierunkowana na badania i rozwój. Przykładem takiego negatywnego zachowania jest nieprawidłowe stosowanie tzw. „Stage Gates" (kamieni milowych między poszczególnymi sekcjami). Często zespoły po prostu kontynuują pracę, nawet gdy metoda właściwie zakłada oczekiwanie na decyzję dotyczącą Stage Gate. Problem polega jednak na tym, że nigdy nie zdążyłyby na czas, gdyby czekały na decyzję. Menedżerowie ZAWSZE wiedzą, co się dzieje, ale wolą nie zadawać pytań. Powodem jest zazwyczaj nie to, że ktoś w procesie pracuje źle, ale raczej że sam proces jest wadliwy.

Agile jest inne

Agile przerywa ten waterfall i dzieli pracę na mniejsze elementy. Te mniejsze części są następnie projektowane, rozwijane, testowane i dostarczane za pomocą krótkich Sprintów, aby uzyskać bezpośrednią informację zwrotną. Dzięki „nowemu" procesowi nie ma już powodów, by ignorować znaki stopu Stage Gates.

Modele hybrydowe mają czerpać to, co najlepsze z klasycznych i zwinnych frameworków i tym samym optymalnie pasować do aktualnej kultury i struktury organizacji. Chęć dostosowania metod zwinnych do organizacji, która w zasadzie jest zbudowana na metodach klasycznych, jest punktem, w którym często wkradają się problemy. Wymagane kompromisy często stoją w sprzeczności z założeniami zwinnych wartości i zasad.

Przykłady takich założeń w Agile to stabilne zespoły, odpowiedzialność własna i dostarczanie działającego oprogramowania na koniec każdego Sprintu. Łatwiej jest odejść od tych wartości i zasad niż zmieniać kulturę i strukturę organizacji. Jeden z najczęstszych (i najbardziej szkodliwych) kompromisów można zaobserwować w organizacjach, które nadal pracują z dynamicznie obsadzanymi zespołami (często nazywanymi organizacjami macierzowymi). Stabilne zespoły często wymagają zmiany granic organizacyjnych i dokładniejszego przeglądu kompetencji.

Oto typowe problemy, które – jeśli nie zostaną rozwiązane – mogą skłonić organizację do korzystania z mieszanin metod klasycznych i zwinnych:

Silosy: Kiedy poszczególne grupy są od siebie oddzielone, potrzeba więcej planowania i koordynacji, aby zapewnić, że właściwe osoby są dostępne we właściwym czasie – nawet przy opóźnieniach. Duże organizacje deweloperskie dodały do swojego schematu organizacyjnego rolę schedulera (planisty pracy) lub ekspedytora (kontrolera terminów), aby radzić sobie z tego rodzaju problemami.

Zbyt szczupłe zasoby: Wiele organizacji deweloperskich cierpi z powodu wieloletnich cięć oszczędnościowych i ma znacznie mniej ludzi do dyspozycji, niż jest potrzebne do ukończenia pracy, do której się zobowiązały. Pracownicy aktywnie pracują nad kilkoma różnymi projektami, aby sprawiać wrażenie postępów w całej gamie firm. Przełączanie się między różnymi zadaniami jest wysoce nieefektywne i zmniejsza dostarczoną wartość, co często prowadzi do jeszcze większej presji na obniżenie kosztów.

Brak skupienia: Liderzy w organizacjach deweloperskich często odczuwają potrzebę akceptowania i realizowania wszystkich zaprezentowanych projektów. Nazywa się to też „syndromem mówienia tak". Najczęściej występuje w organizacjach, które nie mają silnego zarządzania portfolio. W rezultacie oznacza to, że zespoły i pracownicy są zmuszani do multitaskingu, co z kolei prowadzi do nieefektywności.

Niewystarczająca automatyzacja: Nigdy nie spotkałem metody wytwarzania, której nie można by przeprowadzić na małą skalę z kartką i długopisem. Większa skala jest jednak możliwa dzięki automatyzacji. Weźmy na przykład, że musisz ręcznie napisać kilka tysięcy testów regresji. Aby móc przeprowadzić testy, potrzebowałbyś albo bardzo dużo czasu, albo bardzo dużo ludzi. Wielu ludzi zazwyczaj oznacza też więcej zespołów, więcej granic między nimi, więcej hierarchii i więcej nakładu pracy – co może potencjalnie prowadzić do mniejszej liczby przeprowadzanych testów, ponieważ trzeba dotrzymać terminu lub budżetu.

Wartości i zasady, na których opiera się Agile, są naprawdę ważne. Wpływają na zachowania, tak że bardziej skupiamy się na szybszym dostarczaniu wartości. Cztery wartości w Manifeście Agile są przedstawione w parach. Na przykład pierwsza z czterech wartości mówi: „Ludzie i interakcje ponad procesy i narzędzia". Rzeczy po lewej stronie mają wyższą wartość niż te po prawej (choć oczywiście te po prawej również mają wartość). Modele hybrydowe często tworzą kompromisy, które przesuwają nacisk od punktów po lewej stronie bardziej w kierunku środka, a nawet z powrotem ku punktom po prawej stronie.

Modele hybrydowe nie są z gruntu złe

Jeśli jednak odsuwa się od podstawowych zwinnych wartości i zasad zamiast podejmować trudne tematy w organizacji, są to często tylko manewry omijające. Niezależnie od tego, czy się z tym zgadzasz, twoje przemyślenia na ten temat są ważne i kierują rozmową o tym, czym jest Agile, a czym nie jest.

Ten tekst pochodzi z bloga SPaMCAST i został przez nas przetłumaczony.