Metodyki zwinne (Agile) powstały, gdy zaczęto zauważać, że tradycyjny model wytwarzania oprogramowania zajmuje dużo czasu od momentu wystartowania projektu do momentu uzyskania gotowego produktu. Czasem czas ten był liczony w latach!
Wprowadzenie do Agile
Zaczęto dostrzegać, że, w tym czasie, otoczenie biznesowe ulega znacznym zmianom, zmieniają się np. przepisy i technologie. Wszystko to wpływa na wymagania do systemu/produktu a dotychczas wykorzystywane procesy wytwórcze były mało odporne na zmiany. Każda zmiana wymagań w trakcie projektu była bardzo kosztowna (i jeszcze bardziej wydłużała proces).
Zaczęto też zauważać, że nakłady idące na dokładne udokumentowanie każdego etapu są znaczne. Trwające latami procesy wytworzenia nowego oprogramowania sprawiały, że firmy nie mogły być wystarczająco konkurencyjne na dynamicznie zmieniających się rynkach.
Zwinnie, czyli jak? Manifest Agile
Eksperci zaczęli więc szukać sposobów na usprawnienia zarówno na poziomie całego projektu, jak i na poziomie pracy samego zespołu. Na przestrzeni lat wypracowano różne sposoby usprawniania procesów o różnych tajemniczych nazwach. Powstał Extreme Programming (?), Scrum, DSDM, a nawet PRINCE2Agile. Zaczęto też w projektach IT wykorzystywać koncepcje wcześniej znane z branż produkcyjnych jak Lean Management czy Kanban.
I w końcu w 2001 roku doszło do spotkania ekspertów ze wszystkich „nurtów” zwinnych. Panowie się spotkali, pojedli (😉), pogadali, pojeździli na nartach a efektem tego spotkania był Manifest Agile znany jako Agile Manifefsto: https://agilemanifesto.org/
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Co to właściwie jest Agile?
Te kilka zdań to kwintesencja podejścia zwinnego, doświadczeń wielu projektów i wielu, wielu ludzi. Wyraźnie widać jakie wartości niesie ze sobą podejście zwinne. Jakkolwiek w Agile cenione są wartości po prawej, tak te po lewej cenione są bardziej.
Co to oznacza w praktyce? Że ludzie i interakcje, to co wnoszą do projektu, mają dużo większe znaczenie niż procesy, procedury i narzędzia. Przedkładamy działające oprogramowanie nad obszerną (jakże często przerośniętą lub wręcz zbędną) dokumentację. Współpraca z klientem jest ważniejsza niż negocjowanie umów a reagowanie na zmiany jest ważniejsze niż sztywne trzymanie się raz ustalonego planu.
Dwanaście Zasad Zwinnego Tworzenia Oprogramowania
Warto jeszcze zwrócić uwagę na pryncypia zdefiniowane wraz z Manifestem Agile. Twórcy zdefiniowali Dwanaście Zasad Zwinnego Tworzenia Oprogramowania. Wyznaczają one najlepsze praktyki w zakresie organizacji pracy (zalecenie krótkich iteracji), interakcji z klientem (nacisk na zadowolenie klienta i bliską współpracę biznesu z programistami) oraz pracy zespołu (nacisk na właściwą motywację zespołów). Można je wszystkie zobaczyć tu: https://agilemanifesto.org/principles.html.
Parasol Agile
Dziś, w ramach wprowadzenia do Agile, chciałam napisać kilka słów o najpopularniejszych metodykach zwinnych. Zaczniemy od parasola Agile. Przez lata wypracowano kilka zwinnych sposobów zarządzania projektami i pracy zespołu. Zazwyczaj przedstawia się je zebrane pod parasolem. Nie znalazłam genezy przedstawiania Agile jako parasola (ale przyznaję, że szukałam tylko chwilę). Zwracam uwagę na jedną ważną rzecz – sposób organizacji pracy zespołu a sposób organizacji projektu, choć przedstawiane pod jednym parasolem, to dwie odrębne kwestie.
Po lewej stronie mamy zbiór, który często określany jest jako lżejsze podejście zwinne. Mamy tu wszystko, co operuje na poziomie zespołu, sposobach jego rozwoju i organizacji pracy. Po prawej stronie jest szersze podejście zwinne, czyli skalowanie Agile koncentrujące się na projektach.
Jak widać, nie wystarczy tylko podjąć decyzji o zastosowaniu Agile. Należy jeszcze wybrać odpowiednie dla nas sposoby jej realizacji.
Jak wybrać właściwe podejście zwinne?
Odpowiedź nie jest jednoznaczna. Jak zwykle — to zależy. To, po której stronie parasola znajdziemy odpowiednie narzędzia zależy od wielu zmiennych. Przede wszystkim od tego, co właściwie chcemy zrobić.
• Czy wprowadzamy zupełnie nowy produkt?
• Dowiedzmy się czy projekt to jednorazowa inicjatywa, czy pracujemy w środowisku wielu powiązanych projektów?
• Czy wprowadzamy Agile tylko w małym zespole, czy w całej organizacji? Jaka jest nasza organizacja, jak duży nacisk kładzie na formalizm.
• Zweryfikujmy czy będziemy mogli pozwolić sobie na minimalny poziom dokumentacji na rzecz bliskiej współpracy z biznesem?
Co będzie lepsze?
Jeśli będziemy pracować nad rozwojem prostych produktów wystarczy nam to, co jest pod parasolem po lewej stronie. Np. w zespole rozwojowym wdrożymy Scruma. Jeżeli jednak mówimy o dużych przedsięwzięciach, całych programach to należy korzystać z tego, co jest po prawej stronie np. Agile PM.
Przy podejmowaniu decyzji branża, w której operujemy, też ma znaczenie. Choćby ze względu na tempo zmian. W jednych zmiany następują szybko (np. branże kreatywne) a w innych zdecydowanie wolniej (np. branże uzależnione od zmian legislacyjnych).
Agile czy SCRUM wywodzą się z branży wytwarzania oprogramowania jednak ludzie próbują adaptować je w różnych dziedzinach życia. I czasem wychodzi im to całkiem nieźle.
Filozofia Agile – zawsze jest jakieś „ale”
Zanim jednak przejdziemy do szczegółów chciałabym napomknąć kilka słów o ideologii Agile jako takiej. Myślę, że określenie filozofia czy ideologia jest bardzo trafne w odniesieniu do Agile. Agile zmienia podejście do współpracy między uczestnikami projektów, wymaga zmiany nastawienia i przyjęcia różnych ról. Niezależnie od wybranego sposobu wdrożenia (SCRUM, Lean) konieczne jest wypracowanie nowego podejścia i porzucenie korporacyjnych nawyków.
Doceniam korzyści płynące z szybkiego uzyskania działającego produktu. Widzę też jak może to dobrze działać przy odpowiednio dobranym i zmotywowanym zespole. Jestem jednak przeciwna wpychaniu Scruma (lub innych) na siłę wszędzie, często tylko po to, żeby móc się pochwalić tym na jakiejś konferencji czy w artykule. Nie pochwalam forsowania na siłę takiej formy pracy, gdy ludzie i organizacja nie zostali do niej przygotowani.
Pamiętam czasy zachwytu nad Scrumem i ten moment, gdy padało „wszyscy teraz robią Scruma, chyba my też powinniśmy”.
Wszystko jest dla ludzi, tylko trzeba umieć z tego korzystać. Jedno jest pewne, świat IT jest bogatszy o kilka lat doświadczeń ludzi z całego świata i wyciąga z tych doświadczeń wiele wniosków. Jak ze wszystkim tak i z wyborem sposobu zarządzania projektem należy zachować zdrowy rozsądek. Nie należy pchać na siłę metodyk zwinnych tam, gdzie procedury, przepisy i dokumentacja odgrywają istotną rolę.
Skoro Agile jest taki zły to, czemu ludzie go używają?
Bo wcale zły nie jest. Powiedziałabym, że jest narzędziem, którego trzeba nauczyć się używać. I jak każde narzędzie, odpowiednio wykorzystane może przynieść wiele korzyści. Zwinne sposoby wytwarzania oprogramowania są idealne, by szybko zobaczyć czy koncepcja produktu się sprawdza. Można w krótkim czasie osiągnąć „coś” co może być wartością dla klienta i generować zyski. Na podstawie informacji zwrotnych można planować dalszy rozwój naszego produktu.
Agile daje elastyczność, której brakuje w tradycyjnych metodykach wytwórczych. W dzisiejszych czasach świat pędzi tak szybko, że w wielu branżach taka elastyczność i możliwość bieżącego korygowania zakresu to ogromna zaleta.
Agile może przynieść wiele korzyści, jeśli tylko zostanie odpowiednio wdrożony. Warto zainwestować czas i pieniądze w dobór właściwych ludzi i przeszkolenie zespołu. Ważne, żeby wszyscy rozumieli, jaki jest cel projektu oraz żeby nadchodząca zmiana była dobrze zakomunikowana w organizacji.
Ludzie muszą mieć czas i odpowiednią motywację do uczestniczenia w projekcie. Jeśli ktoś w projekcie będzie widział dla siebie zagrożenie może go nawet (mniej lub bardziej świadomie) sabotować. Najważniejsze jest to, żeby ludzie zaangażowani w projekt byli odpowiednio zmotywowani, mieli wystarczającą moc decyzyjną i żeby interesy wszystkich były możliwie zbieżne.
Jestem Magda, ta z narudo.pl – entuzjastka technologii, project manager i analityk
IT. Wspieram przedsiębiorców i twórców internetowych w skutecznym wykorzystywaniu narzędzi online i sztucznej inteligencji oraz organizacji i planowaniu. Wierzę w optymalizację pracy i efektywne zarządzanie, jestem gotowa podzielić się swoim doświadczeniem i wiedzą abyśmy mogli pracować mądrzej, nie ciężej.
Dowiedz się więcej:
• https://agileforce.pl/blog/ – blog ludzi, którzy znają się na byciu zwinnym. Jeśli interesuje Cię temat Agile i chcesz wiedzieć więcej to serdecznie polecam tych Panów
• https://agilemanifesto.org/ – cytowany w tekście Manifest Agile
• https://itnext.io/common-agile-mistakes-36fe51b6217f – Szczere i trafne przemyślenia człowieka, który wiele lat przepracował w zespołach zwinnych na temat najpowszechniejszych błędów przy wdrożeniu Agile.
• https://medium.com/serious-scrum/what-the-scrum-guide-doesnt-say-56ef9447b961 – bardzo ciekawy artykuł obalający kilka stereotypów