Metodyki z nurtu Agile nazywane są ostatnio nowoczesnym podejściem do programowania. Zdobywają one coraz większą popularność dzięki swojej skuteczności i przestępności dla klienta. W tym artykule chciałbym zastanowić się, czy podejście Agile jest tym oczekiwanym, „prawie idealnym”, sposobem na wytwarzanie oprogramowania.
Lekkie podejście do programowania
W odległej historii branży IT, projektanci oprogramowania zmęczeni wymogami popularnych wówczas metodyk prowadzenia projektów programistycznych, postanowili pozbyć się ciążącego balastu przeszłości. Doszli do wniosku, że wytwarzanie oprogramowania powinno przebiegać szybciej, płynniej, efektywniej, że powinno być bardziej otwarte na klienta i, co za tym idzie, na zmianę jego oczekiwań. Słowem: nowa metodyka powinna w optymalny sposób zmierzać do usatysfakcjonowania sponsora projektu, użytkownika i programistów. Efektem tych przemyśleć był Manifest Agile.
W metodykach z nurtu Agile (np.: eXtreme Programming, Scrum) oprogramowanie tworzy się przyrostowo. W krótkich iteracjach implementuje się kolejne funkcjonalności systemu. Użytkownik, przynajmniej w założeniu, jest cały czas dostępny i może podjąć wiążące decyzje dotyczące kierunku rozwoju projektu.
Lekkie metodyki są ściśle zorientowane na jak najlepszą komunikację w zespole (przypominam, że zespół stanowią programiści wraz z klientem). Poleganie na relacja pociąga za sobą rezygnację z formalizmu. Ogranicza się tworzenie produktów ubocznych tak bardzo jak jest to możliwe bez szkody dla projektu. Mówiąc o produktach ubocznych mam na myśli: dokumentację projektu, podręczniki użytkownika, biblioteki programistyczne, itp.
Granice Agile
Na podstawie tego, co zostało już wyżej napisane rodzi się pytanie: czy Agile jest ukoronowaniem ewolucji inżynierii oprogramowania? Moim zdaniem jest etapem pośrednim. Zniechęcenie tradycyjnymi metodykami spowodowało „huraoptymistyczny” odwrót w stronę metodyk lekkich. Mniej dokumentacji, mniej wymagań formalnych, mniej pracy – być może myśleli programiści. Takie rozumowanie nie jest zgodne z prawdą. Programowanie w Agile jest równie (jeśli nie bardziej) wymagające co programowanie w metodykach tradycyjnych. Narzuca ono na członków zespołu dość dużą dyscyplinę. Dzięki krótkim iteracjom, które absolutnie muszą zakończyć się konkretnym (czytaj: widocznym dla użytkownika) efektem nie ma miejsca na zajmowanie się mało istotnymi, lecz interesującymi, miejscami w systemie. Postępy pracy monitorowane są z dokładnością do jednego osobodnia.
Wyobraźmy sobie system zarządzania siecią elektrowni stworzony przez zespół pracujący według wytycznych Agile. System taki można nazwać dużym systemem informatycznym. Z pewnością będzie on rozwijany i modyfikowany przez lata. Co najważniejsze, ze względu na problematykę, wymaga dokładnej specyfikacji. Tego typu systemy są poza zasięgiem zainteresowania lekkich metodyk. Przedsięwzięcia informatyczne wspomnianego kalibru wymagają takiej metodyki prowadzenia projektu, która precyzyjnie definiuje każdy element procesu wytwarzania oprogramowania (np. metodyka RUP). Stosowanie twardej metodyki jest konieczne ze względu na skalę i potencjalny czas trwania projektu. Ma ona za zadanie zapewnić bezpieczeństwo przedsięwzięcia oraz osiągnięcie postawionych celów.
Podsumowując zakres stosowalności metodyk Agile można powiedzieć, że świetnie nadają się do realizowania małych i średnich projektów programistycznych o relatywnie krótkim czasie wykonania, np.: serwisy internetowe lub oprogramowanie dedykowane specyficznym potrzebom klientów. Nie bez znaczenia dla skuteczności metodyki jest ilość osób biorących udział w pracach. Powyżej 12 osób Agile przestaje być lekką metodyką, a staje się metodyką chaotyczną.
Metodyka „Adaptable Process”
Obszar dużych i długotrwałych projektów programistycznych jeszcze nie został zdominowany przez nurt Agile. Sądzę, że nie stanie się to aż do chwili, gdy zwinna metodyka zapewni wysoki poziom kontroli prac nad projektem w każdym momencie jego trwania, przy jednoczesnym zachowaniu lekkości. Taką metodykę można by oprzeć z jednej strony na jednej z implementacji Agile, z drugiej na twardej metodyce o ściśle zdefiniowanym procesie realizowania projektu. Na własny użytek nazwałem taką metodykę Adaptable Process. Wyobrażam ją sobie jako proces, który może być dopasowywany do zmieniających się wymagań klienta. Można pokusić się o wskazanie kryteriów, które powinna spełniać metodyka Adaptable Process, np.:
Posiada zdefiniowany proces wytwarzania oprogramowania. Każdy element procesu ma określone kryteria wejścia i wyjścia.
Umożliwia szybką reakcję na zmianę oczekiwań klienta.
Pozwala utrzymać wysoki poziom kontroli prac nad projektem – w każdym momencie (nawet po zakończeniu projektu) wiadomo z jakiego powodu podjęte zostały określone decyzje w projekcie.
Angażuje do pracy klienta/użytkownika.
Angażuje programistę do prac projektowych – nie wydziela osobnych ról: projektanta i programisty.
Definiuje standardy pracy programisty np. jakość kodu, pokrycie kodu testami, technika programowania.
Umożliwia zespołowi pracę w rozsądnym tempie i przez rozsądną ilość godzin w tygodniu...
Jeśli chodzi o inżynierię oprogramowania, z pewnością jeszcze długo nie zostanie wypowiedziane ostatnie słowo. Nowe wyzwania, które przed nią staną, sprowokują specjalistów do stworzenia nowych kreatywnych podejść. Dzięki temu następuje rozwój i możliwe coraz lepsze spełnianie oczekiwań klientów.
Artykuł ukazał się w kwietniowym numerze czasopisma DDI, http://ddinformatyku.pl
