Często słyszę, że Agile to zwinne tworzenie projektów – w rozumieniu: ciągłe zmiany, stałe terminy, nie działające oprogramowanie, obniżanie jakości, aby tylko dowieźć. W takim przypadku Agile jest synonimem słowa “chaos”. Jeżeli tak myślisz o tych metodach – jesteś w błędzie. Niektóre projekty tworzone w „agile” wyglądają tak jak na obrazku.

Zasada Agile 

Jedną z zasad Agile jest  

Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność. 

Oznacza to, że zespół powinien w codziennej pracy skupiać się na wysokiej jakości oprogramowania. Celem jest zwiększenie zwinności i możliwości wprowadzania zmian. Dla wielu osób jest kłopotliwe zrozumienie tego paradoksu. 

Jakość 

Nacisk na jakość w codziennej pracy programisty przekłada się jasnością postępu oraz pewnością dalszego rozwoju. Ogranicza to sytuacje, kiedy dalszy rozwój oprogramowania jest niemożliwy z powodu złej architektury rozwiązania, a zmiany nie powodują powstawania nowych błędów. 

Dodatkowym argumentem jest to – że dobre oprogramowanie nie “psuje się samo”. Funkcjonalności pisane na szybko, na kolanie mają tendencję do samoczynnego psucia się, często podczas prezentacji u klienta. 

Niska jakość powoduje brakiem relacji pomiędzy tworzonym produktem projektem a twórcami – wtedy praca jest traktowana jako coś niechcianego i każdy oczekuje na zakończenie prac i podpisania protokołu odbioru. 

Możliwości zmian 

Przemyślane rozwiązania są gotowe na wprowadzanie zmian. W przypadku kodu “pokrytego” testami – jego rozwijanie nie jest ryzykowne. Jeżeli do pewnego zestawu funkcjonalności dodajemy nową czynność – automatyczne testy sprawdzają czy poprzednie przewidziane zachowanie jest dalej poprawne.  

Dobrze zaprojektowany system jest gotowy na rozwój – w takich przypadkach, wykonawcy czekają na możliwość rozwoju, a pierwszy etap projektu jest dla nich tylko milestonem. Każdy inżynier, który tworzy dobre rozwiązanie techniczne – czeka, aby je móc udoskonalić poprzez wdrażanie nowych funkcjonalności. 

Jakość a zmiany 

Powyższe argumenty są dowodem, że wysoka jakość oprogramowania przekłada się jednoznacznie na możliwości jego zmiany i adaptacji. Poprawnie zastosowane zasady Agile powinny umożliwić osobom tworzącym oprogramowanie na pisanie poprawnych technicznie rozwiązań a nie tworzenie skrótów.  

W przypadku dobrego oprogramowania – zmiany są traktowane jako rozwój – poprzez emiryzm – czyli informację zwrotną od klienta. Zmiana przestaje być traktowana jako coś złego – tylko jako czynnik pozwalający stworzyć lepsze rozwiązanie. 

Podsumowanie 

Agile zawiera 12 zasad pracy. Są to proste zasady, łatwe do zrozumienia i wytłumaczenia. Lecz wiele firm w dalszym ciągu uparcie stoi przy swoim i tworzy tylko im znane procesy tworzenia oprogramowania – oparte na chaosie i niewiedzy. Dlatego też bądźmy ostrożni mówiąc że pracujemy w metodyce Agile, bo może się okazać że jest to metodyka “edżilisz”.