Szesnaście lat temu, w 1994 roku, konserwatywny przecież Departament Obrony USA zmienił swoje standardy inżynierii oprogramowania. Zaczęto wtedy stosować tak zwany Standard 498, który jest ewolucyjny. Departament Stanu oficjalnie wyrzekł się stosowania metod kaskadowych w projektach. To jest przykładem, jak w końcu, po wielu latach doświadczeń, przekonano się, że metody ewolucyjne sprawdzają się tam, gdzie metody kaskadowe zawodzą.

Co charakteryzuje metody ewolucyjne?

Metody ewolucyjne polegają na tym, że każdy projekt dzieli się na mniejsze projekty. Może ich być wiele, nawet pięćdziesiąt! Chodzi o to, aby każdy kolejny cykl dostarczał interesariuszom projektu jakąś nową wartość. Dzięki temu można także już w trakcie projektu, a nie dopiero tuż przed jego zakończeniem, zorientować się, czy zastosowane technologie sprawdzają się, czy dobrze rozumiemy potrzeby użytkowników. Dzięki podejściu ewolucyjnemu kierownictwo projektu, jego sponsorzy otrzymują na bieżąco informację, czy wszystko dobrze idzie.

Czym różnią się metody ewolucyjne od metod zwinnych?

Pojęcie "metody ewolucyjne" jest szersze. Zawierają się w nich metody zwinne, ale nie tylko. Metody ewolucyjne pojawiły się dużo wcześniej, pod innymi nazwami, takimi jak: cleanroom software engineering, codzienne budowanie, metody przyrostowe, prototypowanie. Każda z nich jest w jakimś stopniu metodą ewolucyjną.

Na ile metody ewolucyjne - niezależnie od nazwy - są dziś rozpowszechnione?

Widziałem wyniki badań, według których około 30% organizacji posługuje się metodami ewolucyjnymi. To mnie dziwi.

Dlaczego? Jak, Pana zdaniem, wygląda to naprawdę?

W rzeczywistości odsetek firm stosujących metody ewolucyjne wynosi 1-5%. Wielu ludzi jest zdania, że skoro co tydzień dostarczają nowy kod, to pracują ewolucyjnie. Ale jeśli nie tworzą co tydzień nowej wartości dla rzeczywistych użytkowników oraz innych interesariuszy, to nie jest to metoda ewolucyjna.

A programowanie ekstremalne czy metody zwinne, w których bezpośrednio współpracuje się z klientem?

Programowanie ekstremalne nie zakłada tworzenia całościowych wymagań, więc trudno określić, na ile kolejne, bardzo często budowane wersje programu tworzą kolejny poziom wartości dla klienta. Z kolei najbardziej popularna metodyka zwinna, Agile Scrum, nie określa jasno relacji między nadrzędnymi wymaganiami a zadaniami dla poszczególnych przebiegów. Nie mówię, że to są złe metodyki, ale nie wystarczy pracować zgodnie z nimi, aby móc mówić o metodzie ewolucyjnej.

Czy są sytuacje, kiedy metody ewolucyjne nie są odpowiednie?

Moim zdaniem, nie - a wiele się nad tym zastanawiałem. Metodami ewolucyjnymi posługuję się od 1960 roku. Wielokrotnie natrafiałem na opór, spotykałem się z osobami mówiącymi, że ich projektu nie da się zrealizować w sposób ewolucyjny, bowiem nie da się go podzielić na tak małe kawałki. W rzeczywistości trudność polega na tym, że nie umie się tego zrobić. W tej dziedzinie wielu ludziom brakuje odpowiedniego wykształcenia.