U nas mówi się, że ktoś chce być bardziej papieski od papieża...

O właśnie. Problem w tym, że w firmach tych, pomimo zbliżenia się do teoretycznej doskonałości, pojawiły się poważne problemy. Dotyczyły one w szczególności rozwoju aplikacji e-biznesowych.

W takich projektach ostateczny rezultat może być trudny do sprecyzowania na początku. Znana jest jedynie ogólna misja. Zakreśla ona granice, zamiast wytyczać punkt docelowy. Można zapomnieć o przewidywalności. Potrzeba ewolucyjnej drogi pełnej prób, błędów i nauki, żeby osiągnąć pożądany rezultat. Przy tego rodzaju aplikacjach tradycyjne metody wytwarzania oprogramowania zwyczajnie zawodzą. Problem leży w samej nieadekwatności tych metod, nie zaś nieumiejętności ich poprawnego wykorzystania.

Nagłówki w gazetach pełne są okrzyków, że teraz, w dobie Internetu, biznes już nie będzie taki sam jak przedtem. To dlaczego w XXI wieku stosowane do tej pory praktyki wytwarzania oprogramowania nie miałyby ulec daleko idącym przeobrażeniom? Informatycy tak się zachowują, jakby wierzyli, że wszyscy się zmienią, z wyjątkiem nich samych i tego, co robią.

Rozumiem, że do tradycyjnych rozwiązań najbardziej przywiązany jest świat naukowo-akade- micki. Jak szybko zatem rośnie popularność idei technik adaptacyjnych?

Książki poświęcone technikom programowania ekstremalnego rozeszły się w setkach tysięcy egzemplarzy! Zainteresowanie alternatywnymi metodami rośnie lawinowo. Widać to chociażby w branżowych mediach. Do programów nauczania wprowadzają je już pierwsze uczelnie kształcące informatyków. Interesujące badania na temat tych metod opublikowała ostatnio Harvard Business School. Grupa specjalistów skupionych wokół Cutter Consortium - w tym Ed Yourdon, Tom Lister czy Tom DeMarco - skłania się ku poglądowi, że czas powszechnego stosowania metod adaptacyjnych nadejdzie już za dwa lata.

Metody adaptacyjne są jak najdalsze od biurokracji. Nikt jej nie lubi, ale przecież bez niej szybko utoniemy w bałaganie i improwizacji. Jak realizować projekt bez dokładnego planu i monitoringu jego przestrzegania?

Rezultatami pracy zespołu nie powinny być kolejne "odfajkowane" punkty harmonogramu, lecz funkcje systemu, które odpowiadają użytkownikowi. Wszystkie powstające w trakcie realizacji projektu dokumenty mają znaczenie drugorzędne. A tak często jest odwrotnie: procedury postępowania i dokumenty stają się jego faktycznym celem. Nie mówię, że np. trzeba zarzucić etap planowania. Planowanie jest niezbędne, ale plan już nie jest...

Zawsze się mówi, że kod trzeba dokumentować. Że kod nie udokumentowany jest niewiele wart.

Trzeba dokumentować, ale tylko to, co najważniejsze. Opasłej dokumentacji i tak nikt nigdy nie przeczyta. Być może potrzeba tylko tyle dokumentacji, żeby było wiadomo, co się buduje i jakie są obecnie zdefiniowane potrzeby użytkownika.

Najważniejsza wiedza i tak ukryta jest w głowach informatyków. Przy realizacji projektu najważniejsze są zespół i interakcja pomiędzy jego członkami. Na temat specyfikacji krąży powiedzenie, że w 50% są kompletne i w 10% prawdziwe...