Muszę przyznać, że osobiście jestem wielkim propagatorem stosowania procesów adaptowalnych (ang. adaptive processes) w kontekście wytwarzania aplikacji RIA opartych m.in. o technologię Flex. Co to jest proces adaptowalny? Aby mówić o jakimkolwiek procesie wytwórczym na pewno należy upewnić się, że rozróżniamy pojęcia „proces” i „projekt”. Czyli na początku odpowiedzmy na pytanie, co to jest projekt adaptowalny (ang. adaptive project)? Otóż, protoplastą projektów adaptowalnych są projekty fixe-price (stała cena – bardzo popularne na rynku polskim), których nazwa bierze się stąd, że ich artefaktem wstępnym jest kontrakt fixe-price, czyli taki, w którym jasno i niezmiennie w kontekście procesu produkcyjnego są zdefiniowane wymagania odnośnie projektu (przedsięwzięcia), którym mamy się zająć. Jeżeli mówimy o wymaganiach, to musimy odróżniać wymagania funkcjonalne od niefunkcjonalnych. Wymagania niefunkcjonalne, to np. budżet, harmonogram, itd… wymagania funkcjonalne, to wszystko to co opisuje nam to co mamy pokryć od strony wdrożeniowej (punkty funkcyjne, funkcjonalności itd…). Projekt adaptowalny, to projekt przed którego realizacją podpisujemy kontrakt adaptowalny (którego protoplastą jest kontrakt z otwartymi godzinami ang. open-hours contracts), czyli taki, który zezwala na rozbudowę zakresu projektu od strony wymagań funkcjonalnych w trakcie jego życia na ściśle określonych zasadach. Natomiast proces adaptowalny to sposób realizacji projektu adaptowalnego, w którym w ciągu kolejnych iteracji wymagania funkcjonalne są rozbudowywane oraz adaptowane do wymagań niefunkcjonalnych.

Każdy proces jest uporządkowanym zbiorem faz oraz artefaktów. Fazy mogą być realizowane w sposób kaskadowy (ang. waterfall model), bądź równoległy. W jednym z poprzednich postów wspominałem o metodykach lekkich jak XP (eXtreame Programming). Bardzo dobrą metodyką lekką, która sprawdza się w kontekście adaptowalnego prowadzenia przedsięwzięć RIA, jest SCRUM, jako, że jej stosowanie wymusza m.in. spotkania zespołu pomiędzy kolejnymi fazami/iteracjami procesu, które pozwalają na kontrolowane rozbudowywanie/korygowanie zakresu projektu od strony funkcjonalnej razem z klientem. Porównując chociażby Flex’a z Flash’em, należy stwierdzić, że Flex to takie małe błogosławieństwo dla stosowania procesu adaptowalnego w kontekście wytwarzania RIA (czy nawet w kontekście stosowania programowania parami (ang. pair programming) w RIA). Flex, jako technologia oraz środowisko wytwórcze, pozwala chociażby na zrównoleglenie poszczególnych faz, na dostarczanie szybkich prototypów oraz artefaktów funkcjonalnych do klienta, nie zaburzając przy tym architektury aplikacji oraz płynności samego procesu produkcyjnego. Jego zorientowanie na warstwę prezentacji wymaga chociażby zainteresowania się tematyką UCD (ang. User-Centered Design, usabilty, itd…) oraz włączenia ideii UCD choćby w szczątkowej postaci do procesu produkcyjnego.

Jak stosowanie procesu adaptowalnego, UCD oraz SCRUM, jako „jedność” wygląda w praktyce? No, na pewno wszystkiego tutaj nie opiszę (po szczegóły ad. procesów adaptowalnych zapraszam m.in. do sięgnięcia do publikacji m.in. mojego autorstwa – link tu, i tu ), jako że temat jest dosyć obszerny. Niemniej jednak chcąc wszystko przedstawić w sposób bardzo zwięzły na potrzeby tego wpisu w skrócie wygląda to tak. Zamiast WBS stosuje się FBS (ang.  Functional (czasami mówi się Features) Breakdown Structure), który jest drzewiastą reprezentacją modułów, obszarów funkcjonalnych oraz funkcjonalności projektów wraz z wagami realizacyjnymi (priorytety) określonymi przez klienta (czasami, choć rzadko przed stworzeniem FBS’a stosuje się badania fokusowe, aby „wybadać”, czego przyszli użytkownicy (z grupy docelowej) mogą pożądać w aplikacji, od strony funkcjonalności). Na bazie FBS’a tworzone są scenariusze odpowiadające realizacji danych funkcjonalności (np. w postaci diagramów aktywności UML’a) – opisy stanów oraz tranzycji (przejść) między nimi, które następnie są upraszczane (redukowane) w kontekście możliwości Flex’a. Następnym krokiem jest szukanie możliwych kolaboracji danych stanów pochodzących ze scenariuszy odrębnych funkcjonalności, tak, aby zbudować model interakcji pomiędzy odpowiednimi obszarami funkcjonalnymi projektu. Na bazie wszystkiego co powyżej, tworzy się makiety oraz prototypy, które są poddawane testom z użytkownikami (ang. user-tests). Ważne jest to, że przed kreacją makiet jasno określa się interfejsy pomiędzy warstwą prezentacji, a logiką biznesową, tak, aby faza implementacji (logiki biznesowej) mogła zacząć się równolegle z wytwarzaniem GUI. Faza wdrożenia, to iteracyjna i równoległa realizacja połączonych faz projektowania oraz implementacji, – czyli po prostu stosowanie podejścia adaptowalnego w kontekście SCRUM, które skutkuje dostarczaniem kolejnych funkcjonalności systemu przy współpracy z klientem oraz w kolejności, które określają wcześniej zdefiniowane priorytety realizacyjne. Tak to w DUŻYM skrócie wygląda.

Jakby nie było metodologie ad. projektów adaptowalnych to jak dla mnie przyszłość w realizacji złożonych projektów RIA, dodatkowo bardzo dobrze „radzą sobie” z pracą zdalną (ang. telecommuting), dlatego jestem dosyć mocno zaangażowany w ich promocję oraz precyzowanie (Adam pracujący w SAP’ie testował je od strony wdrażania aplikacji programowych, natomiast ja od strony aplikacji multimedialnych (systemów czasu rzeczywistego) – i razem stwierdzamy, że proces adaptowalny daje radę oraz przynosi wymierne rezultaty w stosunku do podejścia konwencjonalnego). Jako, że temat jest z pogranicza zarządzania projektami i technologii Flex, nie chcę już Was więcej zanudzać ;)