Jako dziecko byłem szczęśliwym posiadaczem klocków lego. Jakie to wyróżnienie, wiedzą wszyscy którzy pamiętają jeszcze sklepy Pewexu. Kiedy miałem wolną chwilę (w dzieciństwie ma się ich sporo) brałem się za budowanie. Oczywiście najpierw potrzebny był pomysł co to będzie. W moim przypadku najczęściej oznaczało to statek kosmiczny. Następnie ile jest czasu do kolacji i jak dużo mam klocków, aby określić jak wielki statek może być. Zaczynałem pracę od kadłuba, a gdy był już gotowy, kolejno dodawałem nowe elementy: sterówkę, silniki, lasery i wszystko to co mi przyszło do głowy. Dzięki temu co chwila miałem gotowy statek, którym mogłem się pobawić. Co więcej, w każdej chwili mogłem przebudować istniejące już elementy, dodając, odejmując lub wymieniając klocki w miarę potrzeby. To naprawdę była dobra zabawa.
Z podobnym podejściem zabrałem się za pisanie moich pierwszych programów. Najpierw tworzyłem coś co działa chociażby w najprostszy sposób, a potem dzielnie to rozbudowywałem dodając kolejne elementy. Dopiero na studiach dowiedziałem się (a potem wiedza ta została we mnie utrwalona), że moje podejście jest „niewłaściwe” i do tworzenia oprogramowania należy zabrać się jak do budowy domu. Czyli najpierw bardzo dokładnie planujemy wszystkie szczegóły, tak aby nie było nawet możliwości popełnienia błędu, a potem budujemy. Oczywiście przy stopniu skomplikowania projektów informatycznych nie jest możliwe przewidzenie wszystkiego. Tym samym błędy i tak były popełniane, a wykrywane były nierzadko przy końcowej integracji lub implementacji u klienta. I choć klient dwa lata temu podpisał się pod dwustustronnicowym dokumentem z wymaganiami, to produkt nie do końca spełniał jego oczekiwania, które dodatkowo uległy zmianie pod wpływem wydarzeń na rynku.
Będąc pod wrażeniem efektów tego podejścia zacząłem się zaprzyjaźniać z ideą metodyk Zwinnych (Agile). Okazało się, że grupa heretyków zasugerowała podejście dziwnie zbliżone do mojej zabawy z Lego. Otóż twierdzili oni, że oprogramowanie powinno się tworzyć przyrostowo, funkcjonalność po funkcjonalności, dając klientowi możliwość otrzymania prostego produktu wcześniej, używania jego kolejnych wersji, oraz zmiany zdania na temat potrzebnych funkcjonalności (lub też zaprzestania rozwijania produktu, jeżeli wszystkie oczekiwania zostały spełnione. Co więcej ludzie Ci głosili, że kod jest łatwo zmieniać (jak Lego, nie jak połączone zaprawą cegły) więc w każdej chwili można coś podmienić, usunąć albo dodać. Ponieważ jest tyle niewiadomych, lepiej jest planować precyzyjnie krótkoterminowo, zaś plany długoterminowe powinny być bardziej ogólne. Natomiast plany te powinny być jak najczęściej aktualizowane w zależności od możliwości technologicznych, sytuacji na rynku czy oczekiwań klienta. Hm, tworzenie oprogramowania też może być dobrą zabawą.
Uwaga 1: Nie twierdzę tutaj, że Agile zawsze działa. Twierdze natomiast, że działa częściej niż Waterfall (czyli podejście kaskadowe). No i daje więcej przyjemności.
Uwaga 2: W budownictwie też można zauważyć podejście iteracyjne. Wystarczy przypomnieć sobie powiedzenie „Pierwszy dom budujesz dla wroga, drugi dla przyjaciela a trzeci dla siebie”.
