Co doradziłby Pan organizacjom, które chciałyby spróbować podejścia ewolucyjnego?

Zaletą podejścia ewolucyjnego jest to, że na jego wyniki nie trzeba czekać długo. Już po tygodniu widać, czy robimy coś dobrze, czy nie.

Podstawowa trudność dotyczy oceny wartości dla udziałowców. Jeśli na przykład nadrzędnym celem projektu jest obniżenie kosztów określonego działania klienta, to nie jest dostarczaniem wartości produkowanie kodu realizującego kolejne punkty funkcyjne lub kolejne przypadki użycia, o ile ich dostarczenie nie powoduje rzeczywistego obniżenia kosztów. Pod tym kątem w pierwszym rzędzie trzeba oceniać wartość poszczególnych funkcji oprogramowania.

Czy mógłby Pan podać przykłady sukcesu metod ewolucyjnych?

Doświadczenie nauczyło mnie, że w ciągu godziny potrafię znaleźć sposób, jak podzielić dowolnej wielkości projekt na fragmenty nie większe niż 2% całości. Udało mi się to osiągnąć w ogromnym projekcie amerykańskiego Departamentu Obrony, tworzącym oprogramowanie do zarządzania personelem tej zatrudniającej ponad 2 mln osób organizacji. W Hewlett-Packard ta metoda pracy stosowana jest od 20 lat, nikomu nawet do głowy nie przychodzi, by podważać zasadę cotygodniowych dostaw nowych wersji.

Dzięki metodom ewolucyjnym działania organizacji stają się bardziej elastyczne, pracownicy zadowoleni, a klienci usatysfakcjonowani. Microsoft jest także wielkim użytkownikiem tej metody, choć nigdy nie nazywał jej ewolucyjną, posługując się własnymi nazwami. Zostało to opisane m.in. w książce dr. Michaela Cusumano z MIT pt. "Microsoft Secrets". W tym czasie Microsoft był moim klientem. Kiedy współpracowałem z ich dyrektorem testów, powiedział kiedyś: "Tom, ewolucyjne dostawy to nasz sposób życia tutaj, w Microsoft", choć, jak już wspomniałem, stosowano tam zupełnie inne nazwy.

Microsoft wykorzystuje podejście ewolucyjne na trzech poziomach. Mają swoje codzienne budowanie, swoje kamienie milowe co 6 tygodni i wreszcie swoje uwolnienia, sterowane kryteriami marketingowymi. Tak naprawdę Microsoft jest jednym z wielkich użytkowników metod ewolucyjnych.

Inny przykład to trwający ponad 4 lata projekt zrealizowany przez IBM Federal Systems Division (Wydział Projektów Federalnych IBM), kierowany przez prof. Harlana Millsa. Co miesiąc - to prawie dokładnie 2% z 4 lat - robiono kolejną przetestowaną dostawę. Ten i inne projekty prowadzone przez dział Millsa zrealizowano w terminie i bez przekroczenia budżetu. Wśród nich znalazło się oprogramowanie - jego naziemna część - do promu kosmicznego NASA, którego pracochłonność wyniosła 10 000 osobolat! Jeszcze w latach 80. ubiegłego stulecia Harlan Mills udowodnił, że podejście ewolucyjne działa w projektach Marynarki Wojennej USA, Departamentu Obrony i w NASA.

Przy okazji odkryliśmy wtedy, że w podobny sposób NASA tworzyło tę część oprogramowania promu, która wraz z nim leciała w przestrzeń (na pokładzie promu kosmicznego znajdują się cztery komputery, niezależnie wykonujące to samo oprogramowanie, oraz piąty, rezerwowy, wykonujący tylko procedury wejścia na orbitę i lądowania). Co nas jeszcze bardziej zaskoczyło, to fakt, że naukowcy zajmujący się techniką rakietową i lotów kosmicznych pracowali w sposób ewolucyjny już od końca II wojny światowej, podczas gdy znaczna część ludzkości aż do dzisiaj tkwi w przestarzałym modelu kaskadowym! Projekt dąży do celu tak samo jak samonaprowadzająca się rakieta - dokonując, gdy trzeba, nieznacznych poprawek kursu. W granicach 2% zawsze można zmienić kierunek; umożliwia to adaptację do zmian wymagań w trakcie projektu, co dziś jest koniecznością biznesową. Tę zasadę znano i stosowano już o wiele lat wcześniej, niż powstał Manifest Agile.