W maju tego roku miałem referat na konferencji dotyczącej systemów ERP. Jego tytuł to “Modele wdrażania i zarządzania projektami ERP”. Był to najwyżej oceniony przez publiczność, referat. Tezą przewodnią referatu było stwierdzenie, że:
Kluczowe tezy
?Powodem wielu porażek i nieudanych projektów wdrożeniowych jest:
?zbyt wiele nacisków dostawcy na kompromisy podczas wdrażania gotowego, parametryzowanego oprogramowania w postaci jednego zintegrowanego pakietu: oprogramowanie staje mało przydatne
?zbyt wiele nacisków kupującego na dopasowanie (kastomizację): znacznie rosną koszty i odsuwa się termin jego wdrożenia a nadal nie ma gwarancji powodzenia.
?Wiele specyfikacji jakie obserwuję to lista setek pozycji, opisujących jak ma ?ten program działać?, typowe efekty:
?Lista cech dużego systemu ERP to ponad 6000 pozycji
?Optymistycznie patrząc można liczyć na zgodność własnej takiej listy z gotowym produktem na rynku w 80%
?Pozostaje więc 20% cech brakujących, to jest 1200 cech
?Jedna nowa funkcjonalność to optymistycznie licząc dwa dni pracy konsultanta i programisty, przy koszcie 1200zł/dzień wychodzi 2,88 mln.
?Kupując oprogramowanie gotowe nie projektujemy go, a specyfikujemy to, do czego będzie używane: wskazujemy które procesy system ma obsłużyć i jakiego produktu procesu oczekujemy.
?Kluczowe wydaje się wydzielenie tych procesów, które są najistotniejsze dla firmy a ich wparcia nie oferuje gotowe oprogramowanie, pozostaje rezygnacja lub umiejętne zaprojektowanie ich jako aplikacji dedykowanej.
Wymagania na złożone systemy, zdefiniowane jako zestaw testów są znacznie efektywniejsze i bezpieczniejsze, niż detaliczna specyfikacja prostych funkcji. Tworzenie testów wymaga jednak określenia biznesowego celu wdrożenia i zrozumienia tego jak organizacja funkcjonuje (opracowanie modeli).
Praktyka pokazuje, że koszt analizy i opracowania takich testów jest znacznie niższy niż nieplanowany dodatkowy koszt projektów opartych na detalicznych specyfikacjach wymagań (średnie przekroczenie budżetu, spowodowane złą specyfikacją wymagań, to ponad 60%).
Kompletna prezentacja użyta podczas tego referatu: Modele wdrażania i zarządzania projektami ERP
Bardzo mi się podoba takie podejście, jest takie zdroworozsądkowe. Ciekawa jestem, na ile udaje się to zaobserwować i stosować w życiu.
To zależy, czy klient – a są z reguły jednak konformistami – wytrzyma napór “otoczenia”. Metoda się sprawdza…
Jest jeszcze jedna zasadnicza wada listy wymaganych cech. Bardzo łatwo pominąć albo nie doprecyzować. Jako przykład podam “obsługę plików w formacie XYZ”. Dostarczone narzędzie może faktycznie obsługiwać takie pliki, ale tylko jednokierunkowo (tylko import albo eksport), a my potrzebujemy pełnej obsługi.
Specyfikacja jako testy ilościowe i jakościowe jest znacznie wygodniejsza dla wszystkich, ale faktycznie wymaga konkretnej koncepcji działania, a nie podejścia “dawajcie wszystko, może się kiedyś przydać”.
Bardzo mi się podoba podeście poprzez pisanie testów do wyboru systemu. Świetna koncepcja.
Stosujemy ją na co dzień w programowaniu – nazywa się TDD (Test-driven development) i jest elementem strategii Agile przy budowaniu projektów.
I mogę potwierdzić, że sprawdza się – trochę “boli” na początku 🙂
Nie wiem od kiedy to TDD to Agile ale niech tam :). TDD jako metoda definiowania wymagań ma także pewną wadę: nic nie mówi o tym jak je spełnić. W przypadku “szukania” gotowego oprogramowania do wykorzystania ma moim zdaniem głęboki sens, jednak jako wymaganie dla aplikacji dedykowanej nie zawsze: proszę sobie wyobrazić, że daję kilka (a nawet kilkaset) przykładowych wyników systemu scoringowego, na bazie których zamawiam napisanie systemu scoringowego. Obawiam się, że “odtworzenie” (w końcu trzeba zaprogramować metodę podajWynikScoringu(a,b,c,d,e) będzie raczej mało prawdopodobne. TDD to testy, jednak wszelkie nietrywialne metody trzeba jeszcze udokumentować, bez tego sam test jest niczym. “Inżynieria wsteczna” wzorów matematycznych itp. to wielkie wyzwanie, dlatego nie należy zapominać o wymaganiach dziedzinowych (jawnie podana na tacy logika działania jako wymaganie). W przeciwnym wypadku nie raz developer staje przed wyzwaniem rozgryzania zasad gry w brydża na podstawie kilkunastu zapisanych partii, życzę powodzenia ;).
Tak więc testy na pewno mają sens jako dowód spełnienia wymagania, jednak jako jedyna dokumentacja wymagań, w przypadku tworzenia oprogramowania dedykowanego, nie raz same testy to stanowczo za mało.
TDD to nie Agile, ale jeden z jej elementów/technik: http://www.agiledata.org/essays/tdd.html
Zgadzam się, że testy mogą nic nie mówić jak spełnić wymagania. Testy na te same wymagania można napisać różnie. Wszystko zależy od tego co chce się testować – co chce się mieć pod kontrolą.
Testy nie służą do inżynierni wstecznej, ani “rozgryzania” tylko do weryfikacji.
Trudność w zrozumieniu TDD polega na tym, że jest w tej metodzie sporo elementów motywacyjnych i podnoszących jakość projektów poprzez rozwijanie ludzi prowadzących projekt (np. DRY-Don’t Repeat Yourself, elementy Kaizen).
Tak zgadzam się, same testy to za mało. Ale nadal to świetna koncepcja – pozostaje kwestia realizacji 🙂
To prawda, na pewno stosowanie testów jest o niebo lepsze niż próba opisanie wymagania samymi cechami bez testów. Pisanie testów generalnie zmusza do zrozumienia celu jaki się osiągnąć, pisanie (projektowanie) implementacji to rozwiązywanie problemu ale test to kierunek i światełko w tunelu. Na poziomie wymagań biznesowych pozwala eliminować wszelkie nadmiarowe wymagania i nie pominąć tych istotnych. Ta cecha metody powoduje, że w projektach “politycznych” jest to metoda ‘groźna’ 🙂
Jedna uwaga: link http://www.agiledata.org/essays/tdd.html pokazuje niestety bardzo złą metodę rozwiązywania problemów “metodą prób i błędów”. Ten diaggram może nie mieć końca (nie licząc końca budżetu lub czasu).
To, że proces jest nieskończony jest zamierzone – na tym opiera się Agile, na ciągłym doskonaleniu. Oczywiście niektóre projekty (a może i większość) powinny się kończyć, ale warunki końca można wyznaczyć.
To nie jest “metoda prób i błędów” to jest metoda walidacji testu, tzn. upewnienia się, że test na pewno sprawdza występowanie konkretnego błędu. Oczywiście należy zastanowić się jak zaimplementować takie działanie dla specyfikacji wymagań. Takie podejście w niektórych metodykach (także Agile) jest też nazywane faza Learning & Conclusions, czyli uczenia się i poprawiania swojego działa na przyszłość – bardzo dobra technika zwłaszcza w instytucjach często zamawiających usługi, czy oprogramowanie.
Niewątpliwie doskonalenie samego procesu wytwórczego ma ma sens, ale wymagania to są “konkrety”. Projekt się kończy w momencie gdy produkt spełnia wymagania (przechodzi testy), wymagań jest nie raz wiele więc można je pogrupować i oddawać produkt “modułami”, ale te najpierw trzeba zaprojektować. Ja też uważam, że projekty powinny się (kiedyś) kończyć 😉 i najlepiej by data końca także była elementem planowania.