Wróćmy do (bycia) agile

2026-07-17

Każdy programista, tester czy menadżer projektu musiał kiedyś usłyszeć termin Agile i myślę, że wszyscy możemy się zgodzić, że jest to dziś jeden z najpopularniejszych sposobów tworzenia oprogramowania. W rzeczywistości jest on tak popularny i skomercjalizowany, że łatwiej znaleźć płatne certyfikaty i kursy niż dowiedzieć się czym właściwie jest Agile, a raczej czym było, a raczej czym miało być.

Ale zanim pójdziemy dalej, wyjaśnijmy najpierw jedną rzecz. Agile to nie Scrum. Wiele osób nadal myli te dwa pojęcia, ale prawda jest taka, że dziś są one co najwyżej dalekimi krewnymi - w rzeczywistości słowo agile w ogóle nie pojawia się w oficjalnym Scrum Guide (sprawdźcie sami).

Krótka historia

W latach 90. zarządzanie projektami informatycznymi znajdowało się w kryzysie, ponieważ stosowane procesy nie pozwalały reagować na zmiany w odpowiednio krótkim czasie. Istnieją historie o tym, jak błędna interpretacja pracy Winstona Royce'a z 1970 roku stała się fundamentem zarządzania projektami w modelu Waterfall, gdzie należało podążać za procesem:

zbieranie wymagań - projektowanie rozwiązania - implementacja - testowanie - wdrożenie

Sama publikacja w rzeczywistości krytykowała właśnie takie podejście.

W 2001 roku grupa programistów, która chciała zmienić sposób, w jaki projekty były zarządzane przez menadżeró, postanowiła wspólnie opracować zasady, które miały zmniejszyć rosnącą przepaść pomiędzy menadżerami a programistami - czego efektem było opublikowanie słynnego Agile Manifesto.

Główne założenia były (i miejmy nadzieję nadal są) następujące:

należy tworzyć elastyczne, wysokiej jakości oprogramowanie, którego nie będziemy bali się zmieniać w dowolnym momencie,
ponieważ będzie ono dostarczane w małych, działających iteracjach, aby jak najwcześniej uzyskać informację zwrotną,
co jest możliwe tylko wtedy, gdy ludzie biznesu ściśle współpracują z programistami.
Programiści powinni budować zaufanie,
ponieważ tylko wtedy otrzymają przestrzeń i swobodę do efektywnej pracy.

Gdzie jesteśmy dzisiaj?

Dziś Agile (niestety) nie jest już metodologią - jest produktem, i jak każdy produkt ma swoje potrzeby komercyjne, które niestety przesłoniły większość jego pierwotnych celów. Jest w tym pewna ironia, ponieważ współcześni menadżerowie uczą programistów jak być agile, podczas gdy metodologia ta została wymyślona przez samych programistów.

Spójrzcie na Scrum dzisiaj. Na samym scrum.org dostępnych (na czas pisania tego artukułu) jest 6 płatnych certyfikatów oraz mnóstwo innych kursów, które twierdzą, że uczą pracy w agile. Z tymi twierdzeniami są dwa problemy:

po pierwsze - agile nigdy nie miało być metodologią zarządzania projektami - był to sposób tworzenia oprogramowania, stąd nazwa - "Agile Software Development", a nie "Agile Project Management" - wydaje się niestety, że programiści niemal całkowicie stracili zainteresowanie tym tematem, a dziś przestrzeń ta została zdominowana przez menadżerów projektów.
po drugie - nie da się nauczyć kogoś tworzenia zwinnego oprogramowania z dnia na dzień.. - potrzeba do tego lat doświadczeń, zarówno sukcesów jak i porażek, połączonych z odpowiednim mentoringiem - nie ma tu drogi na skróty.

Czy powinniśmy się poddać?

Tak i nie.

Tak - Agile zaczęło żyć własnym życiem - innym niż wielu ludzi się spodziewało - i niewiele da się z tym zrobić, poza zaakceptowaniem tego. I nie - idea tworzenia wysokiej jakości oprogramowania nie została utracona. Myślę, że wszyscy: programiści i managerowie powinniśmy ponownie wrócić do tych 12 podstawowych zasad, które nadal są niezwykle aktualne w kontekście tworzenia oprogramowania. Odłóżmy na chwilę na bok sprinty, daily i scrum masterów - i zobaczmy czy rzeczywiście realizujemy podstawową zasadę dostarczania działającego, wysokiej jakości oprogramowania w powtarzalnych iteracjach. Jeśli nie - zastanówmy się jak możemy do tego dojść. Nie wymaga to ogromnych ilości kursów i certyfikatów - można i warto robić to krok po kroku, obserwując co działa, a co nie - w przeciwnym razie Agile stanie się niczym więcej niż narzędziem do nadzorowania projektów waterfall.. - produktem dla menadżerów, a nie metodologią tworzenia oprogramowania.

Jasna strona

Odkładając moją krytykę na bok - naprawdę uważam, że jest w tym wszystkim również jasna strona. Rosnąca presja na bycie Agile zmusza zarządzających przynajmniej do rozbijania 'wodospadów' na serię mniejszych 'kaskad'. Coraz więcej menadżerów projektów nie podąża też już ślepo za scrumem (ani żadną inną metodologią) - i zaczyna zastanawiać się, czy rzeczywiście służy ona swojemu pierwotnemu celowi, jakim jest maksymalizacja wartości dostarczanej klientom.

Dalsza lektura

Osobom zainteresowanym tematem gorąco polecam zapoznanie się z jedną z poniższych pozycji: