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.
8 komentarzy do “Metodyka zwinna – po czym ją poznać?”
Przy kliencie jest ważne, by wiedział czego potrzebuje. Z mojego doświadczenia wynika, że klienci tego nie wiedzą 😉 I wówczas zaczyna się zabawa w zmianę tego co zostało zmienione. Wszystko fajnie, jeśli firma rzeczywiście ma z klientem podpisaną umowę SCRUMową. Czyli po prostu płacą za każdy kolejny przebieg.
Czy ktoś się spotkał w Polsce z takimi umowami na wytworzenie oprogramowania? Ja niestety nie.
Bardzo interesujący artykuł pokazujący w prosty sposób zasady działania metodologii Agile- gratulacje! 🙂 Co do punktu „Małe rozmiary projektu” mam jednak pewne zastrzeżenia. Wg mnie Agile można z powodzeniem wykorzystać także w przypadku dużych projektów, nawet jeżeli są krytyczne pod względem złożoności, bezpieczeństwa czy też innych czynników. Przykład dużego projektu, w którym Agile zdał egzamin to projekt SKOK Ubezpieczenia nad którym w szczytowym momencie pracowało nawet 25 osób. Polecam przeczytanie artykułu opisującego w jaki sposób wdrożono metodologię Agile w przypadku tak dużego projektu: http://pl.goyello.com/skok-goyello-agile-business-case
Cieszy mnie, że dzięki popularności Scruma zaczęliśmy dostrzegać znaczenie metodyki w projekcie 🙂 Znakomicie, że dzielicie się sukcesem i dobrymi praktykami. Warto też pamiętać, że mamy wybór i agile to nie jedyne dobro i panaceum na wszystko.
Przyjmuje się, że duże projekty to >50 osób, 25 zalicza się jeszcze do małych na potrzeby tego rozróżnienia w artykule. Miały miejsce projekty, które miały 50 a nawet 100 uczestników i zakończyły się sukcesem, jednak z badań autorów książki, która jest podana jako źródło, wynika, że osoby odpowiedzialne za zarządzanie takimi dużymi projektami twierdziły, że zwinne metodyki były jednak nieco uciążliwe.
Case study ciekawe i pokazuje, że stosowane były rzeczywiście techniki Scrumowe, czym już nie każdy może się pochwalić:) Artykuł ma kilka punktów zachęcających do dyskusji. Szkoda, że nie ma możliwości komentowania na stronie.
Na czym polegała krytyczność pod względem złożoności, bezpieczeństwa w tym projekcie?
Rzeczywiście w przypadku 100 osób poziom trudności prowadzenia metodyk zwinnych rośnie drastycznie. Proponowanym rozwiązaniem w takich przypadkach jest wprowadzenie m.in. pojęcia Area Product Ownerów oraz konceptu Scrum of Scrums ( o czym traktuje między innymi artykuł http://agile.pl/2011/08/scrum-w-duzych-projektach/ ).
Jeżeli chodzi o krytyczność złożoności w projekcie SKOK Ubezpieczenia to wynikała ona w głównej mierze z bardzo rozległej i specyficznej domeny biznesowej projektu oraz faktu iż cały system składał się z wielu podsystemów, dość mocno ze sobą powiązanych. Krytyczność pod względem bezpieczeństwa związana była z faktem, że w bazie danych przechowywane były wrażliwe dane (prywatne dane klientów) a część systemów zbudowana została w postaci publicznych portali internetowych. W związku z tym wszelki security leak skutkować mógł przejęciem krytycznych danych klientów przez niepowołane osoby.
Btw. przedstawiony przeze mnie w poprzednim komentarzu artykuł jest również dostępny pod adresem http://proseedmag.pl/aktualnosci/duze-firmy-tez-moga-byc-agile-business-case gdzie istnieje możliwości pozostawiania komentarzy i dyskusji na temat przedstawionych tez 🙂
Hej Bardzo fajny tekst. Czytam ostatnio sporo o Agile i tak zastanawiałem czy Agile można powszechnie wdrożyć w projektach niezwiązanych z IT? Właściwie nic nie stoi na przeszkodzie. Przynajmniej tak mi się wydaje, ale widzę, że wciąż te metodologia pojawia się głównie w programowaniu. Próbowałem kiedyś opisać jak ja bym to widział http://businesslifemanual.pl/agile-o-co-chodzi/, ale nie wiem czy to jest dobry kierunek. Swoją drogą ciekawę czy ta metoda w tym szybko zmieniającym się świecie nie zostanie niedługo zastąpiona czymś jeszcz bardziej zwinnym…
Tak, agile można stosować też poza IT. Bardziej zwinnie się chyba nie da niż to, co mamy – zasada, żeby ciągle dostosowywać sposób pracy do obserwowanych efektów. To, co się może zmienić, a w sumie chyba już widać, że się zmienia, to wyzwania w dużych, złożonych projektach, gdzie mamy kilkadziesiąt zespołów, które ze sobą współpracują nad wytwarzaniem jednego produktu. Pojawiają się wyzwania w komunikacji, synchronizacji pracy, przekazywaniu celów, ogarnianiu wymagań przechodzących przez wiele zespołów, dzieleniu pracy na kilka poziomów. Częstą odpowiedzią jest „trzeba rozmawiać i usprawniać”, ale wiele osób dochodzi do tego, że to nie takie poste i potrzebne są sprytniejsze narzędzia. Wtedy pojawiają się pomysły typu skalowalny agile, niektórzy sięgają po pewne rzeczy z zarządzania lub analizy biznesowej. To wszystko ewoluuje, przekształca się i pewnie za jakiś czas spotkamy się gdzieś po środku syntezując pomysły z różnych dziedzin (tak jak i agile jest taką koncepcją wyrastającą z wielu innych wcześniejszych).