Agile Manifesto (Manifest Agile) to skrócona nazwa deklaracji stworzonej przez siedemnastu zwolenników i praktyków różnych sposobów wytwarzania oprogramowania, innych niż te oparte na kaskadowym modelu. Pełna, oryginalna nazwa to Manifesto for agile software development, w przetłumaczeniu na polski Manifest zwinnego wytwarzania oprogramowania. Deklaracja została stworzona już ponad 20 lat temu, bo w 2001 roku, a wciąż jest jak najbardziej aktualna. Uncle Bob (Robert C. Martin), jeden z twórców, wspomina w podcaście Marcina Gila, nagranym w 2020, Better Software Design, że mimo upływu lat nic w manifeście by nie zmienił. Co spowodowało fenomen, krótkiej, czteropunktowej deklaracji? Jak doszło do jej stworzenia? Jak ją rozumieć i co w niej jest najważniejsze? Sprawdźcie moje przemyślenia poniżej!
Krótka historia Agile Manifesto
Wszystko się zaczęło od spotkania w lutym 2001 w Snowbird, w resorcie narciarskim. Spotkanie miało na celu wspólny odpoczynek, jazdę na nartach, i znalezienie wspólnej wartości łączącej lekkie metody wytwarzania oprogramowania. Wśród nich można wymienić: Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming. Siedemnastu przedstawicieli, twórców i zwolenników powyższych rozwiązań nazywało się wówczas The Agile Alliance.
Jak doszło do spotkania?
Na początku 2000 roku w Oregonie, podczas spotkania zwolenników Extreme Programming, organizowanego przez Kent’a Beck wybrzmiał po raz pierwszy pomysł, żeby odróżnić lekkie metody od tych tradycyjnych, Waterfallowych. Nazwanie wspomnianych wyżej, innowacyjnych metod za pomocą słowa “Light”, spowodowało szereg artykułów, takich jak: “Light methodologies, such as Extreme Programming, Adaptive Software Development, Crystal, and SCRUM“. W następstwie, we wrześniu 2000, Bob Martin wysłał następującą wiadomość:
“I’d like to convene a small (two day) conference in the January to February 2001 timeframe here in Chicago. The purpose of this conference is to get all the lightweight method leaders in one room. All of you are invited; and I’d be interested to know who else I should approach.” .
Od niej rozpoczeły się dyskusję dotyczące spotkania, tego gdzie mogłoby się odbyć i kto powinien w nim uczestniczyć.
Czy wszyscy byli zgodni co do treści manifestu?
Manifest został podpisany przez wszystkich uczestników wyjazdu. Jedynie Martin Fowler miał lekkie zastrzeżenia co do nazwy “agile”. Bał się, że może to być nazwa ciężka do poprawnego wymówienia przez amerykanów. Wszyscy jednak opuścili ośrodek z przekonaniem i nadzieją, że zaproponowane zasady pomogą innym realizować projekty w bardziej agile’owy (czyli zwinny) sposób. Taki cel im przyświecał twórcom podczas tworzenia Agile Manifesto.
Agile Manifesto
Jak wspomniałam wyżej, Agile Manifesto to cztery proste zasady, które zebrałam na poniższym diagramie:
Celowo na środku schematu znajduje się znak zapytania. Dlaczego? Żeby uzmysłowić wszystkim czytelnikom ważność słowa, które znajduje się w centrum. To słowo to “ponad”. Co więc oznaczają powyższe zasady? Że wszystkie elementy wymienione po lewej powinny być traktowane z wyższym priorytetem niż te po prawej. Nie oznacza to jednak, że nie są ważne! Nic bardziej mylnego. Często słyszy się, że w Agile Manifesto działające oprogramowanie ma większą wartość niż dokumentacja – co oczywiście jest prawdą. Później jednak zespoły buntują się przeciwko tworzeniu dokumentacji, bo przecież “wg manifestu ona nie jest ważna”. A to już jest błędne myślenie, które może nas zaprowadzić w prawdziwe tarapaty. Omówmy szerzej poszczególne zasady.
Ludzie i interakcje ponad procesy i narzędzia
Jak już wiemy, obie wartości wymienione w pierwszej zasadzie Agile Manifesto są ważne. Autorzy chcieli tą zasadą podkreślić to, że skuteczna i efektywna współpraca może mieć miejsce wtedy kiedy skupiamy się na interakcjach z innymi, na komunikacji. Co dadzą nam nawet najlepsze narzędzia świata, kiedy nie będziemy ze sobą rozmawiać i współpracować? Jak będziemy dostosowywać produkt do potrzeb naszych użytkowników, jeżeli nie będziemy się z nimi kontaktować? Będzie to szalenie trudne. Dlatego, aby tworzyć produkty, z których ludzie chcą korzystać, musimy ze sobą współpracować. A narzędzie oraz procesy mają nas w tym wspierać.
Działające oprogramowanie ponad szczegółową dokumentację
Dokumentacja tworzona z głową, na bieżąco, ma dużą wartość dodaną dla budowanego projektu. Nie chodzi oczywiście o tworzenie ton instrukcji, do których być może nigdy nikt nie zajrzy, ale o budowanie bazy wiedzy, która pomoże nam rozwijać i ulepszać produkt. Nie stoi to okoniem do wytwarzania działającego oprogramowania, a wręcz może być jego świetnych uzupełnieniem. Działający produkt jest jednak ważniejszy niż sama szeroko rozpisana dokumentacja. Dlaczego? Odpowiedź jest prosta :). Co da nam sterta papieru czy plików w sieci, jeżeli nie będziemy mieli działającego produktu, na których potencjalnie możemy zarabiać? Niewiele. Dlatego w hierarchii zawsze należy stawiać wyżej prace programistyczne i realizację produktu, niż tworzenie obszernej biblioteki dotyczącej technicznych aspektów.
Współpraca z klientem ponad negocjacje umów
Znam osoby, które mówią, że ten punkt ich nie dotyczy. Słyszałam parę razy: “my pracujemy nad produktem, a nie negocjujemy kontrakty, szef się tym zajmuje”. Faktycznie, może podział obowiązków w organizacji nie zakłada żeby programiści, architekci czy designerzy negocjowali umowy z klientem, jednak współpraca z klientem jest tu sednem całej zasady. Znajomość kontraktu przez wszystkie osoby zajmujące się wytwarzaniem danego produktu może zwiększyć wspólne zrozumienie, np. terminów, budżetu, itp. Dzięki takiej wiedzy będziemy mogli jeszcze efektywniej współpracować z klientem informując go o potencjalnych opóźnieniach. Ważni są ludzie i interakcje, a klient też jest przecież człowiekiem. Komunikujmy się więc szczerze, budujemy zaufanie, dzięki temu będziemy mogli tworzyć produkty, które nie tylko spełniają biznesowe założenia ale są też dobrej jakości.
Reagowanie na zmiany ponad realizację założonego planu
Czytając ten punkt zawsze mam uśmiech na twarzy :). Przypominam sobie wtedy jak nie raz słyszałam od zespołów: “ustaliliśmy zakres całego Sprintu, a Product Owner nie chce realizować tego zadania tylko inne” albo “ten ticket zakładał realizację tego w inny sposób, dlaczego nagle mamy to zmieniać”. A no właśnie dlatego, że chodzi o to, żeby reagować na zmiany. Oczywiście im lepiej znamy pracę do wykonania, tym skuteczniej jesteśmy w stanie ją oszacować i zrealizować. Im mniej niepewności, niedomówień i zmian w trakcie pracy, tym jesteśmy w stanie ją szybciej dostarczyć. Jednak po co wdrażać funkcjonalność, która nagle, z powodów biznesowych, przestaje być wartościowa dla naszego produktu? Albo, po co na ślepo realizować założony plan, skoro w fazie przemyśleń i refinement’ów nie zauważyliśmy jednego istotnego elementu w całej układance funkcjonalności? Warto wtedy szybko zakomunikować owe spostrzeżenia do PO, tak żeby ten mógł podjąć odpowiednie decyzje i zareagować na zmiany.
Która zasada Agile Manifesto jest najważniejsza?
Żadna. Każdy z punktów jest tak samo istotny. Najważniejsze jednak, żeby działać zgodnie ze wszystkimi zasadami manifestu, a nie podchodzić do niego wybiórczo. Warto zgłębić Dwanaście zasad zwinnego wytwarzania oprogramowania aby dogłębniej zrozumieć co kryje się w podwalinach Agile Manifesto. Współpraca w zespole, z klientem, działający produkt i odpowiednie reagowanie na zmiany to z pewnością kwintesencja podejścia Agile do wytwarzania oprogramowania. Jednak, po drugiej stronie, stoją nie mniej ważne aspekty: procesy i narzędzia, dokumentacja, uczciwy kontrakt oraz podążanie za ustalonym planem. Warto o tym pamiętać i świadomie realizować wszystkie założenia. Fenomenem Agile Manifesto jest z pewnością jego prosta, cztery proste zasady, które niosą za sobą tak wiele.
Sprawdź nasze ostatnie wpisy:
