Być jak jaszczurka

Zwinność to nie cecha metod i narzędzi, lecz organizacji.

Zwinność to nie cecha metod i narzędzi, lecz organizacji.

Nie ma chyba bardziej odmienianego przez przypadki słowa niż "zwinność". Odpowiednik angielskiego agile przez środowisko związane z rozwojem aplikacji traktowany jest jako nowa "srebrna kula". Od czasu, gdy w kurorcie narciarskim w amerykańskim stanie Utah zdefiniowany został tzw. agile manifesto, a Kent Beck opublikował książkę na temat extreme programming, "zwinność" postrzegana jest jako antidotum na tradycyjne bolączki inżynierii oprogramowania: długi cykl od pomysłu do rozwiązania, chybione lub niekompletne wymagania, złą jakość produktu końcowego i kłopoty ze współpracą pomiędzy zamawiającym a wykonawcą.

Mało kto zdaje sobie sprawę, że od zwinności w rozumieniu technologii do zwinności, która przynosi konkretną korzyść biznesową jest długa druga. Agility to nie tylko programowanie, ale przede wszystkim zarządzanie. To zarządzanie organizacją IT w taki sposób, by mogła szybko, elastycznie i inteligentnie odpowiadać na potrzebę biznesową.

Zwinność jako sposób wytwarzania systemów

Najbardziej znana twarz zwinności to ta związana z rozwojem aplikacji. Dość popularne - także w Polsce - są elementy extreme programming (XP), najczęściej określane jako:

• ścisła interakcja z użytkownikiem,


• iteracyjny rozwój aplikacji,


• maksymalna dekompozycja,


• budowanie testu zanim budowana jest aplikacja/komponent,


• programowanie w parach.

Z ducha XP wyrastają inne "zwinne" metody, nastawione bardziej na projekt niż produkt software'owy. Do najbardziej znanych należą Agile Project Management (APM) i Scrum. Obie koncentrują się na podobnych wartościach:

• samoorganizującym się zespole,


• przyrostowym definiowaniu funkcjonalności,


• bardzo mocnym zaangażowaniu użytkownika,


• odejściem od kaskadowego cyklu na rzecz iteracyjnego i adaptacyjnego,
• wymienności ról w zespole.

Patrząc z perspektywy budowania produktu i prowadzenia projektów według zasad agile, widać, że jest to po prostu alternatywny pomysł, konstruowany w dużej mierze jako antyteza tradycyjnego podejścia do budowy systemów i prowadzenia przedsięwzięć informatycznych. Realizm, który przejawiają zarówno twórcy agile manifesto, jak i entuzjaści "zwinnych metod" (np. akceptowanie faktu, że zmiany w założeniach są naturalne) wynika nieomal w całości z praktycznych spostrzeżeń w rzeczywistych projektach prowadzonych w przedsiębiorstwie.

Pierwszy poziom "zwinności" to "zwinność metody" - rozumiana jako stosowania paradygmatu agile w programowaniu i zarządzaniu projektem.

Zwinność jako grupa technologii

Długa i usiana przeszkodami jest droga od oprogramowania do rozwiązania użytecznego biznesowo. System to nie tylko kod wynikowy wytworzony tą czy inną metodą, ale zdolność wsparcia potrzeby biznesowej środkami technologicznymi.

Te same zasady, które leżą u podstaw zwinnego rozwoju systemów, można zastosować do innych elementów rozwiązania informatycznego: a więc serwerów, platform systemowych i aplikacyjnych, sieci lokalnych i rozległych, samych aplikacji. Tak rozumiana zwinność to korzystanie z technologii, które dają zdolność błyskawicznej, choć niekoniecznie pełnej i dokładnej odpowiedzi na wymagania użytkownika - nawet jeśli te ostatnie wyrażone są w sposób niepełny lub niepewny.

Typowym przykładem rozwiązania technologicznego, które znakomicie wpisuje się w zasady agile, jest wirtualizacja serwerów. W normalnym, kaskadowo prowadzonym projekcie, na podstawie wymagań biznesowych oraz architektury logicznej powstaje projekt techniczny systemu, a w jego składzie - sprzęt, na którym dana aplikacja będzie działać. Proces zakupu serwera trwa od kilku tygodni do kilku miesięcy, w zależności od jego klasy. Wirtualizacja umożliwia powołanie takiego serwera w ciągu pojedynczych godzin, ewentualnie dni, i przekazanie go do eksploatacji. Jeśli system się sprawdzi - można z czasem wymienić go na maszynę fizyczną; jeśli nie - zwolnione "moce" można będzie przeznaczyć do innych zadań.

Inny przykład to tworzenie systemów opartych o komponenty. Dobudowanie jakiejś funkcjonalności do aplikacji to najczęściej podmiana jednego komponentu albo napisanie nowego. Wykonanie go jest względnie szybkie, przetestowanie proste, a ryzyko wdrożenia i nakłady z tym związane - ograniczone. Dzięki technologiom komponentowym budowa nowych aplikacji albo rozbudowa istniejących nie musi podlegać sztywnemu, kaskadowemu cyklowi rozwoju.

Ale technologia to dopiero drugi z elementów. Trzeci to zdolność organizacji skorzystania z niej; całe "zaplecze", które sprawia, że to, co technicznie wykonalne, staje się realne.