Metodyka zwinna – po czym ją poznać?

5 czerwca 2012

Agile uwalnia i pozwala tworzyć. To powód, dla którego posiada masy zwolenników. Jednak zwinne podejście to nie tylko ulga z odciążenia od dokumentacji. Wymaga i zobowiązuje! Zanim pochwalisz się, że pracujesz zwinnie, sprawdź czy to prawda 😉

Po czym poznać, że Twój sposób pracy jest zwinny? Podejście Agile, mimo występowania w postaci różnych metodyk wykorzystujących różne praktyki (o tym niebawem:), ma kilka charakterystycznych cech. Oto one.

Przystosowanie do zmian (embracing change)

Jedną z najważniejszych zalet podejścia zwinnego jest możliwość szybkiej reakcji na pojawiające się zmiany (takie coś nigdzie indziej!). Oto przy każdej zgłaszanej uwadze nie otwiera Ci się scyzoryk w kieszeni (burzą całą koncepcję!), ale postrzegasz je jako naturalną część projektu, z którą potrafisz sobie łatwo poradzić. Dzięki temu jesteś bardziej otwarty i kreatywny, a klient szybko otrzymuje dokładnie to, czego chce.

Krótkie cykle/częste dostarczanie (fast cycle/frequent delivery)

Kolejne wydania systemu pojawiają się często (np. co miesiąc). Najważniejsze jest wielokrotne przedstawianie klientowi efektów pracy i postępów. Dzięki temu nabiera on zaufania (mimo braku szczegółowej dokumentacji z ustaleniami) i na bieżąco zgłasza uwagi do kolejnych wersji.

Prosty projekt (simple design)

Klient potrzebuje funkcji dodawania produktu, ale nie chce jego usuwania? Nie ma problemu. Nie martwisz się na zapas, czy będzie wołał o dopełniające się operacje, zgodnie z zasadą minimalistycznego wytwarzania YAGNI (You Ain’t Gonna Need It) – nie rób więcej, niż jest absolutnie konieczne do zaakceptowania efektów bieżącej iteracji.

Refaktoryzacja (refactoring)

Kod tworzony na szybko i często pojawiające się zmiany sprawiają, że z czasem Twoj kod zaczyna przypominać spagetti albo prowizoryczną budowlę podpieraną zapałkami i lataną na gumę do żucia. Żeby dać sobie szansę na dalszą bezstresową pracę, wykonujesz refaktoryzację – zmieniasz kod, by stał się bardziej uporządkowany, ale zachował niezmienione działanie wszystkich przygotowanych do tej pory funkcji. Klient nie widzi różnicy, a Ty możesz odetchnąć z ulgą i spokojnie kodować dalej.

Programowanie w parach (pair programming)

Często w podejściu zwinnym pojawia się motyw programowania w parach. Dwóch programistów pracuje przy jednym komputerze. Nie z powodu cięcia kosztów na sprzęt, ale dla zwiększenia jakości pracy. Drugi programista może wziąć swój komputer, planować i szukać rozwiązań, podczas gdy pierwszy implementuje. Jeden od myślenia, drugi od robienia 😉 A na serio – kiedy dwie osoby pracują nad tym samym kodem, algorytmem, projektem czy testem, drastycznie spada poziom popełnianych błędów. Sprawdzone!

Retrespektywa (retrospective)

Tudzież refleksja. Zezwalasz na częste zmiany w projekcie, więc co jakiś czas powinieneś przejrzeć i zaktualizować swoje oszacowania, zastanowić się nad efektywnością pracy i stosowanych metod. W Agile’u nie ma łatwo, trzeba myśleć!

Wiedza ukryta (tacit knowledge)

Brzmi tajemniczo? Jeśli nie ma dokumantacji, nigdzie nie spisano założeń i szczegółów wymagań (wiedza jawna, explicit knowledge), to gdzie jest ta wiedza? W główie każdego uczestnika projektu! Skąd? Z rozmów z klientem czy przyszłym użytkownikiem. Ważne, by wszyscy wiedzieli wszystko, czego potrzebują i żeby ze zmianami byli zawsze na bieżąco.

Rozwój sterowany testami (Test Driven Development)

Nie ma dokumentów? Jak sprawdzić czy system jest OK? Wszyscy piszą testy! Programiści i klienci. Przed kodowaniem i w jego trakcie. Sukcesywnie od pierwszej do ostatniej funkcji. Z założenia nie powinno zająć to dużo czasu, a zapewni, że system działa dobrze i można go szybko przekazać do klienta w kolejnej iteracji.
 

Nie zawsze, nie do wszystkiego

Metodyki zwinne NIE SĄ UNIWERSALNE i nie pasują do każdego projektu. Chcę być pogromcą tego mitu:) Upewnij się, że Twój projekt, zespół czy organizacja spełniają warunki konieczne (o wystarczających porozmawiamy przy następnej okazji).

Dobry kontakt z klientem

Nie chodzi tylko o bycie na Ty. Klient (czy przyszły użytkownik) powinien mieć dla Ciebie czas, niemalże wprowadzić się do biurka obok, chodzić z Tobą na herbatę, rozmawiać o projekcie, zaglądać Ci przez ramię i na bieżąco korygować. Albo przynajmniej bardzo często się spotykać. W wolnych chwilach powinien myśleć nad priorytetami funkcji, opracowywać kryteria akceptacji. Niełatwo o tak zaangażowaną osobę w dzisiejszych czasach, kiedy każdy ma ręce pełne roboty przy swoich własnych codziennych zadaniach. Trudno zrozumieć wagę bycia w projekcie i poświęcić na to swój czas.

Wykwalifikowany zespół

Nie masz jawnie spisanych wymagań, planów, projektów. Jest tylko niezbędne minimum. Wszystko zawierzasz ludziom, którzy tworzą Twój zespół. Musisz być pewny, że to nie przeciętniacy, ale prawdziwi fachowcy, którym można pozwolić tworzyć w locie! Są doskonale doinformowani i zmotywowani? Świetnie! Od tego zależy czy na koniec spotkacie się na piwie by opłakać czy świętować projekt.

Kultura organizacji

Czy jesteś gotowy na to, by blisko współpracować z innym mężczyzną? Nie zawsze trafisz na ładną, miłą i pachnącą koleżankę 😛 Czy Twój szef wierzy w to, że dwóch programistów jest bardziej efektywnych pracując w parze, niż osobno, a jednocześnie przy końcu miesiąca nie dzieli wypłaty na pół? Jedni wychodzą o 15, drudzy dopiero o tej wstają, a trzecich (np. studentów) połowę tygodnia nie ma w pracy? Jak chcecie się spotykać, informować i planować? Twoja firma musi lubić pracować w sposób zwinny i mieć w tym wsparcie zarządu.

Małe rozmiary projektu

Masz 50 lub 100-osobowy zespół? Twój projekt to budowa stadionu, oprogramowania do rakiety kosmicznej albo sprzętu, który robi operacje na otwartym mózgu? Metodyki zwinne nie nadają się dla dużych, złożonych lub krytycznych pod względem bezpieczeństwa systemów. Musiałbyś się niesamowicie nagimnastykować. Ciągłe zmiany, refaktoryzacja, wiedza ukryta? Czekałyby Cię koszmary.

Ciągłe doskonalenie

Agile przede wszystkim polega na zdolnych ludziach. Nie ma zrzucania odpowiedzialności na kierownika projektu! Każdy członek zespołu posiada część wiedzy o projekcie. Razem muszą analizować metody pracy, dynamicznie je dopasowywać i ciągle doskonalić. W Agile’u nie ma lekko, trzeba myśleć!
 
Źródło:
Boehm B., Turner R., Balancing Agility and Discipline. A guide for the perpexed, Addison – Wesley, 7th Printing, October 2009.

Cześć, jestem Hania.

Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.

Może zaciekawi Cię także:

www.analizait.pl by ProjectUP (C) 2020