Agile, czyli metodyka zwinna, a może wcale nie metodyka? Czym jest Agile i 12 zasad „metodyki” zwinnej? Kiedy w ogóle stosować Agile? Jakie są zalety prowadzenia projektów wg Agile? Dzisiaj wszystko, co warto wiedzieć o Agile i o metodykach zwinnych na start.
“Metodyka” Agile
Dlaczego słowo metodyka wrzuciłem w cudzysłów? Bo Agile jest na tyle modnym słowem, że przyczepia się do wszystkiego. O metodyce powiem czy jest czy nie jest, jak o tym myśleć, bo dużo osób jak usłyszy Agile to myśli, że tam jest pewne rozwiązanie na wszystkie problemy.
Co to jest Agile? Zacznijmy od definicji Agile to iteracyjne podejście do zarządzania projektami i tworzenia oprogramowania, które pomaga zespołom dostarczyć wartość klientom szybciej i przy mniejszej liczbie problemów. Zamiast stawiania wszystkiego na jedno wielkie wdrożenie zespoły Agile dostarczają pracę w niewielkich ale użytecznych przyrostach. (źródło definicji: attlasian.com/pl/agile).
W skrócie jak myśleć o Agile – to pewien sposób podejścia do wytwarzania czegokolwiek. Nie chcesz tego robić na zasadzie dużej kobyły, gdzie najpierw sobie zaplanujesz, później przygotujesz i czekasz na wynik. Agile powstało, dlatego, że są sytuacje, w których nie do końca wiesz co chcesz uzyskać. Wtedy planowanie, myślenie nic nie da, bo niektóre rozwiązania można zrobić tylko wtedy, gdy robi się je w trakcie doprecyzowując. Popełniasz dużo błędów, żeby sobie uświadomić o co naprawdę chodzi. Są projekty, które w ten sposób warto poprowadzić, ale są też projekty, w których już ktoś dobrze wymyślił pewne rzeczy i tam nie ma co wydziwiać. Tradycyjne projekty typu budowa mostu, wiesz jakie są zasady budowania mostów, zbudowano ich miliony, jest więc pewna rama według której będziesz postępował. Jednocześnie w trakcie wytwarzania możesz działać w zwinny sposób, bo na froncie robót dzieją się różne rzeczy – coś nie dojedzie, coś się zmienia, mimo całej analizy coś idzie nie tak. W skrócie zwinność polega na tym, żeby nie zakładać, że jesteś w stanie wszystko przemyśleć od początku do końca, tylko ruszyć w drogę i dać sobie prawo do dopracowania rozwiązania w trakcie. To jest esencja Agile. Problemy będą inne niż w projektach, w których dokładnie wiesz co robisz.
SCRUM, Lean, Kanban, Extreme Programming i inne
Powstało bardzo dużo rozwiązań, które jakoś starają się filozofię Agile przełożyć na narzędzia, metody i techniki, które można wykorzystać. Są podejścia bardziej lżejsze i takie, które są bardziej złożone.
Do tych lżejszych będzie należał SCRUM, gdzie cała metoda jest opisana, cały framework jest opisany na 16 czy 20 stronach, nigdy nie pamiętam, ale to małą ilość. Mówi o tym, że jak będziesz pracować w ten sposób to zachowasz zwinne zasady, jednocześnie masz zespół, który dostarcza wartość kawałkami i to wszystko rośnie.
Lean software development to połączenie podejścia z produkcji z software. Kanban, Extreme Programming – wykorzystywałem częściowo to podejście jak tworzyłem moja własną metodę.
Zwinność u źródła dotyczyła małych zespołów, bardzo dziwne jest to, że ta zwinność faktycznie działa przy mniejszych zespołach, a przy większych logika zaczyna się załamywać. Ludzie dążyli do tego, żeby stosować podejście Agile na większych zespołach i tak powstało Scrum-of-Scrums, Large-scale Scrum, Scaled Agile Framework itd. Jest cała masa metod, które mówią o zwinności na większą skalę. Nie neguję ich, warto rozumieć dlaczego takie powstały i gdzie możesz je zastosować, bo nie ma szansy, żeby wybrać z tego coś w miarę szybko.
Skąd się wziął Agile
Zaczęło się od spotkania kilkunastu doświadczonych managerów IT, którzy pracowali nad tym jakie sposoby zarządzania wytwarzaniem oprogramowania będą najlepsze. Stworzyli Manifest zwinnego wytwarzania oprogramowania. W skrócie chodziło o to, że IT miało taki problem, że przychodził np. dział sprzedaży z komunikatem “zróbcie mi, żebym miał raporty ze sprzedaży”, 9 miesięcy później ktoś dostawał gotowy produkt od IT, następnie szedł komunikat “ale nie o to nam chodziło”. Ponieważ IT się zamykało w swojej jaskini, dwa różne światy, nie rozumieli się wzajemnie, na koniec powstawało coś z czego nikt nie był zadowolony. Nie można było pokazać wartości.
Powstał więc manifest, który skupia się na kilku rzeczach. Po pierwsze lepsze sposoby rozwiązania tworzenia oprogramowania, polegają na tym, że skupiasz się na ludziach i współpracy bardziej niż na narzędziach i procesach. Działające oprogramowanie ponad kompleksową dokumentacją. Współpraca z klientem nad negocjacje kontaktów i odpowiadanie na zmiany ponad podążanie za planem. Cenimy procesy, dokumentację, negocjacje i plan, ale ważniejsze są interakcje, działające oprogramowanie, współpraca i odpowiedź na zmiany. Temat chwycił. Jest w tym dużo prawdy, tak warto pracować. Agile sprowadza się do manifestu i do 12 zasad, które zostały dodane do niego przez twórców i osoby, które brały udział w spotkaniu. Te zasady nie są obowiązkowe do stosowania zawsze. Manifest i 12 zasad to wszystko co definiuje Agile. Cała reszta to są zastosowania, sposoby, różne techniki i to nie jest biblia.
Chcesz być Agile popatrz na Manifest, na zasady, postaraj się je zrozumieć i dopiero poszukaj narzędzi, które pasują do tego w jaki sposób pracujesz. To najsensowniejsze podejście.
12 zasad Agile
1. Najważniejsze jest zadowolenie klienta przez wczesne i stałe dostarczanie działającego oprogramowania – nastawienie na wartość.
2. Otwarcie się na zmianę wymagań, nawet na późnym etapie produkcji – cel ponad zakres.
3. Dostarczenie działającego oprogramowania często, od kilku tygodni do kilku miesięcy, z nastawieniem na skracanie tego czasu – wartość i doskonalenie.
4. Przedstawiciele biznesu i developerzy muszą pracować wspólnie i codziennie w trakcie trwania projektu – współpraca.
5. Budowanie projektu wokół zmotywowanych jednostek. Dawanie im środowiska i wsparcia, którego potrzebują oraz zaufanie, że wykonują swoją pracę – przywództwo.
6. Najbardziej efektywną metodą przekazywania informacji w zespole jest rozmowa twarzą w twarz – współpraca.
7. Działające oprogramowanie jest główną miarą postępu – pułapka długu technologicznego! Robisz, żeby działało a potem się okazuje, że na przykład coś jest nieserwisowalne. Akurat tą zasadę warto zrozumieć trochę głębiej, bo tworzy ona najwięcej problemów.
8. Procesy zwinne promują stabilne środowisko. Sponsorzy, developerzy i użytkownicy powinni utrzymać stałe tempo cały czas – dyscyplina. Kolejny element na który rzadko się zwraca uwagę.
9. Stałe zwracanie uwagi na techniczną doskonałość i dobry design wspiera zwinność – pułapka perfekcjonizmu. Działające oprogramowanie i techniczna doskonałość. Te dwie zasady warto ze sobą połączyć, bo inaczej albo zrobimy coś co nie będzie serwisowalne, albo będziemy tak długo łupać tematy, gdzie wrócimy do rzeczywistości sprzed Agile.
10. Sztuka maksymalizacji pracy, która nie zostanie wykonana, jest kluczowa- prostota.
11. Najlepsze architektury, wymagania i design pojawia się w samoorganizującym się zespole – przywództwo i doskonalenie.
12. W regularnych odstępach czasu zespół dokonuje refleksji jak mógłby być bardziej efektywny, a potem zmienia i dopasowuje swoje zachowanie zgodnie z sytuacją – doskonalenie.
Zanim zaprosicie kogokolwiek do rozmowy o zwinności wydrukujcie sobie Manifest Agile i przedyskutujcie co o nich myślicie, które wam pasują, jak je rozumiecie. To punkt startowy do tego jakiego Agile potrzebujecie.
Podsumowując – wartość, cel, doskonalenie, współpraca, przywództwo, dyscyplina i prostota to punkty wokół których warto krążyć.
Kiedy stosować “metodyki” Agile?
Trochę inaczej będziemy pracować w sytuacji standardowych kontraktów, które są najczęściej podpisywane na zasadzie fixed price. Jest określona cena za dany zakres. Jeżeli masz przypisany stały zakres to czas i koszt potrafią się zmieniać, bo nie do końca jesteś w stanie przewidzieć czas trwania i koszt. Dlatego przy kontraktach fixed price dostawca wpisuje sobie w cenę kontraktu ryzyko. Przy zwinnym podejściu działa to inaczej – czas i koszt są stałe. Umawiasz się z zespołem, który będzie pracował zwinnie , że będzie pracował przez 10 miesięcy, w tym czasie co miesiąc dadzą wydanie oprogramowania, albo konkretnej wartości, ale co powstanie w ciągu tych 10 miesięcy to trzeba dopiero odkryć. Tu się pojawia pierwszy problem – wywalę kasę i nic z tego nie będę miał? Jeżeli wrzucisz kasę i nie będziesz tego kontrolować w zdyscyplinowany sposób, to tak się skończy, ale można do tego podejść inaczej. Mamy kontrakty albo fixed price albo time and material. To podejście było dawno stosowane – jak analizujesz projekt to robisz podejście time and material, bardziej zwinny sposób. Później jak jest doprecyzowane co ma być w zakresie to drugą część kontraktu podpisujesz na zasadzie fixed price.
To prowadzi do myślenia kiedy zwinność ma sens a kiedy nie. Przy tematach, gdzie nie do końca znasz zakres popracuj zwinnie. W tematach, gdzie masz dokładny zakres popracuj na fixed price.
Jakie są zalety prowadzenia projektów “metodą” Agile
Szybki feedback i reakcja. To zdecydowanie jest to co lubię w podejściu zwinnym. Dostajesz coś, informacja zwrotna, korygujemy i jedziemy dalej. Świetny sposób pracy i weryfikowania oczekiwań oraz niepopełniania błędów na dużą skalę.
Skupienie na rezultacie i “lekkość”. Skupiasz się nad tym co chcesz osiągnąć i nie dodajesz dużo biurokracji.
Skuteczne, jeżeli wiesz co robisz. Jeżeli masz zdyscyplinowany zespół, który rozumie jak zgłaszać problemy, bez zamiatania pod dywan to super działa. Jeżeli nie masz zespołu, który potrafi tak działać to zwykle się wysypie.
Wady “metodyki” zwinnej
To nie jest metodyka. To pewna filozofia działania i wartości, które przekładają się na to jak będziesz organizować swoją pracę i co będzie twoim kompasem. Do tego dodajesz dopiero metody SCRUM czy inne. Jeżeli masz dobrze zdefiniowane zasady, masz je dopasowane do dojrzałości zespołu to działa. Jeżeli oczekujesz, że będzie to odpowiedź na wszystkie problemy to jej tam nie znajdziesz.
Ujawnia niekompetencję dużo szybciej. Wtedy samoorganizacja zespołu leży, trzeba go poprowadzić w hierarchiczny sposób.
Łatwa do zrozumienia, trudna do zastosowania. Wszyscy się zgadzają, że “to jest fajne”natomiast, żeby stosować prostotę, utrzymać feedback, przywództwo itd to nie jest łatwe nawet w zespołach, które się lubią i mają wysokie kompetencje.
Agile w praktyce
Jak szukasz jakiejś metody to spotkasz PDCA czyli cykl plan – do- check – act. Planujesz, robisz, sprawdzasz, poprawiasz. To stary dobrze znany cykl Deminga, praca w iteracjach. Wymyślono to już dawno temu.
Bonus na koniec
Manifest Agile trzeba czytać obrócony na bok. Dlaczego tak i co to znaczy? Wyszło nam z naszych badań, że skupienie się na ludziach działa, jeżeli masz podstawy związane z procesami, z dobrym kontraktem, dokumentacją itd. Manifest trzeba czytać obrócony na bok, bo pisali go ludzie, którzy byli bardzo doświadczeni i wiedzieli co robić. W momencie, kiedy jesteś świetny technicznie skupianie się na ludziach jest tym co napędza projekt. Natomiast jeżeli skupisz się na ludziach bez podstawy technicznej, procesowej itd to wszystko się wypierdzieli, albo zwiniesz projekt albo firmę. Firmy dokładnie tak rosną – najpierw są zarządzanie hierarchicznie później dojrzałość procesów rośnie zaczyna być większe skupienie na ludziach i podejście zwinne, turkusowe dzieje się gdy jest osiągnięty bardzo wysoki poziom dojrzałości procesów.
Agile, Lean, Prince2, co wybrać? Jeśli zastanawiasz się co zastosować u siebie w firmie to zapraszam cię do kontaktu z nami https://leadership-center.pl/kontakt/
pVIDEO