Bardzo często spotykam się z projektami, w których użytkownicy narzekają na dostawcę oprogramowania, uważają że program nie całkiem spełnia ich oczekiwania (wymagania podpisali… ale to nie rozwiązuje tego problemu). Problem polega na często spotykanym podejściu: analiza wymagań tylko w postaci wywiadów i w konsekwencji niepełne zrozumienie specyfiki biznesowej oraz fakt, że developer ma skłonności do uproszczeń i “normalizacji”. Innym, moim zdaniem jeszcze gorszym podejściem, jest rozpoczęcie kodowania jeszcze w trakcie trwania wywiadów i tworzenie oprogramowania metodą codziennych, lub co tygodniowych spotkań z użytkownikiem opisującym kolejne aspekty systemu. Zbyt późne odkrywanie (a nie raz nawet niedostrzeganie tego), tego że pewne rzeczy są ‘tymi samymi rzeczami” ale w innych kontekstach, prowadzi do bardzo wielu problemów z implementacją. Ale po kolei.
Wymaganie: system ma pozwalać na wystawianie faktur VAT
Wyobraźmy sobie pozornie prosty problem: oprogramowanie CRM zawierające między innymi funkcjonalność fakturowania. Z reguły z wywiadów (analiza) dowiemy się, że w kilku miejscach różne osoby wystawiają faktury. Wzór faktury będzie załącznikiem, z kilku tak zwanych “user story” zostanie opracowany jeden (normalizacja user story) przypadek użycia “Wystawienie faktury VAT”, jego implementacja z reguły jest kompilacją treści kilku wywiadów (user story). Kilka różnych osób (role) dostanie prototyp do oceny, każdy zgłosi inne zmiany i oczekiwania, powoli powstaje bardzo złożony scenariusz przypadku użycia obłożony warunkowymi ścieżkami scenariusza realizacji tego przypadku użycia. Nie raz można spotkać bardzo skomplikowany “model procesu” wystawiania faktury z wieloma warunkami… Diagram przypadków użycia jednak, po czymś w rodzaju normalizacji, najczęściej przedstawiał by jedno wymaganie – wystawianie faktur VAT – i wyglądał by tak:
Analiza biznesowa krok po kroku
Model procesów biznesowych
Pierwszym krokiem powinna być jednak analiza polegająca na opracowaniu modeli procesów biznesowych. Celem tego modelowania jest wykrycie, udokumentowanie i zrozumienie każdego kontekstu wystawienia faktury, weryfikacja treści wywiadów (ludzie mają naturalne tendencje do pomijania rzeczy oczywistych i uwypuklania swojej roli w procesie) oraz upewnienia się, że znamy wszystkie sytuacje, w których wystawiana jest faktura VAT. Dlatego niezależnie od zakresu projektu warto zawsze opracować model procesów biznesowych całej organizacji.
Tu mała uwaga, model procesu to nie algorytm pracy a model obrazujący czynności i ich cele.Samo wystawianie faktur może mieć różne konteksty, może to robić więcej niż jedna osoba, a sposób w jaki to robi zależy od kompetencji tej osoby. W opisywanym przypadku mamy dwa takie konteksty. Faktura VAT za usługę wystawiana przez osobę o wysokich kwalifikacjach:
oraz faktura VAT za towar z magazynu wystawiana przez osobę nie mającą wiedzy lub uprawnień pozwalających na samodzielne wystawienie Faktury VAT – dla takiej osoby powstała dokładna procedura:
Jak widać diagramy nie są jest zbyt skomplikowane i takie powinny być. Model procesów biznesowych nie powinien zawierać w sobie wiedzy z innych obszarów takich jak : procedury, uprawnienia, umiejętności. Proces biznesowy ma ścisłą definicję (czynność lub czynności przekształcające stan wejścia w produkt procesu). Jak widać powyżej, czynności procesu są kojarzone z procedurami (tu komentarz) i rolami (tor ma modelu procesów). W powyższych przykładach procedury jawnie umieszczono na diagramie (to jedna z możliwych konwencji). W pierwszym przypadku procedura jest trywialna, wpisałem ją tylko dla zobrazowania jej prostoty co wynika z faktu, że kierownik projektu (PM) to osoba o wysokich kompetencjach, od której wymagamy (CV, rekrutacja) wiedzy o tym jak wystawiać faktury VAT. Informacja taka powinna być w dokumentacji skojarzona z rolą PM.
Na diagramach oznaczono czynności związane z fakturowaniem jako <<przypadek użycia>> (przyjęta tu konwencja, nie jest to element notacji BPMN, w której wykonano te diagramy).
Jak widać mamy więc dwa zupełnie różne konteksty wystawiania faktur w tej firmie. Oba są istotne i było by dużym błędem tworzenie dla nich jednego uniwersalnego scenariusza.
Model przypadków użycia
Jak poradzić sobie z fakturowaniem na dwa sposoby? Błędem było by proste uznanie, że mamy dwa przypadki użycia:
Powyższe sugeruje wykonanie dwóch implementacji, zapewne z powieleniem części kodu. Pojawienie się kolejnego nowego kontekstu, to tu kolejny przypadek użycia, będzie to wymagało dopisania kolejnego kodu. Powyższy diagram to nie najlepszy pomysł. Więc jak?
Tu pojawia się rola modelu dziedziny jako elementu dokumentacji wymagań. Nazywa się to czasem “wymagania dziedzinowe” w analizie biznesowej czyli zrozumienia i udokumentowanie biznesowych aspektów narzędzia (a nim jest zamawiane oprogramowanie), na które wymagania mają zostać wyspecyfikowanie.
Moim zdaniem model przypadków użycia, jako tak zwana czarna skrzynka, nie rozwiązuje żadnego problemu poza oczywiście wyspecyfikowaniem wymagań funkcjonalnych (co jest bardzo ważne!).
Dobry projekt będzie zawierał jednak, moim zdaniem, jeden przypadek użycia ale także konteksty ról. Nieco nadmiarowy diagram przypadków użycia z kontekstami:
Powyższy diagram modeluje “pomysł” z kontekstami. Oprogramowanie ma jeden przypadek użycia (system ma być prosty i łatwy w użyciu!). Diagram przedstawia dwóch aktorów (dwie role), jeden przypadek użycia (w projektach wole osobiście pojęcie “usługa systemu”, które jest łatwiejsze w komunikacji z użytkownikiem), oraz jego dwie specjalizacje po jednej dla każdego aktora (aktor jest połączony z właściwym przypadkiem użycia związkiem użycia). Powyższy diagram byłby trudny do zrozumienia przez Zamawiającego nie znającego dobrze notacji UML, różowe elementy umieściłem nadmiarowo dla zilustrowania tego artykułu). W dokumentacji dla klienta elementów oznaczonych na różowo nie umieszczam.
Nadal jest to jednak czarna skrzynka, która nie determinuje logiki biznesowej systemu. Czy powinna? Myślę, że tak, gdyż wyznaję zasadę, że rolą developera jest implementacja a nie modelowanie logiki organizacji , której nie zna. Zostawiając developera tylko z powyższym diagramem, bardzo ryzykujemy, że wykona co prawda oprogramowanie “w stanie na dzisiaj”, ale jego rozwój, wynikający z logiki biznesowej organizacji (np. planowanego jej rozwoju) może być trudny, kosztowny a nawet czasem niemożliwy.
Model dziedziny systemu
Dlatego jednak tworzymy model dziedziny systemu, nie narzucając (tu zgadzam się z programistami) metod rozwiązywania problemów implementacji (czyli na tym etapie nie praktyki DDD a raczej model analityczny BCE).
Nie umieszczamy więc na diagramie przypadków użycia kontekstów (powyżej przypadki użycia oznaczone kolorem różowym) a tworzymy model wewnętrznej logiki zawierającej informację o tych kontekstach. Model ten powinien być tak opracowany, by możliwe było łatwe dodawanie nowych kontekstów, bo to wynika ze specyfiki biznesu. Dodatkowo elementem biznesowym jest także to, że Zamawiający na dziś oczekuje możliwości pracy z pomocą komputera i tabletu, nie wyklucza w przyszłości innych urządzeń końcowych. Wymaganie to nie powinno prowadzić do powielenia przypadków użycia, nie powinno także komplikować elementów typowo dziedzinowych np. zarządzania kontekstami przypadku użycia.
Proponowany tu model dziedziny to kompletna logika dziedzinowa (komponent Model wzorca MVC, diagram klas w konwencji BCE/ICONIX)):
Powyższy model zawiera dwa dedykowane elementy, każdy dla konkretnego urządzenia końcowego, bez ingerencji w sam mechanizm fakturowania (klasa WystawienieFakturyVAT). To wzorzec architektoniczny MVVM. Klasa ta (jedna dla przypadku użycia!) zawiera odpowiednie scenariusze dla każdego kontekstu (klasy skomponowane o nazwach takich jak aktorzy, tu np. wzorzec projektowy strategia). Faktury VAT są zarządzane przez repozytorium faktur.
Model sterowania interakcją
Uzupełnieniem powyższego, diagram przypadków użycia i model dziedziny, powinien być model scenariusza realizacji przypadku użycia – diagram sekwencji (którego już tu nie prezentuję, był nie raz opisywany) oraz diagram sterowania interakcją (nie jest to diagram aktywności!):
Powyższy diagram pokazuje, kolejne ekrany (ich makiety powinna zawierać dokumentacja wymagań). Mam nadzieję, że nie powyższego szczegółowo wyjaśniać.
Na zakończenie
Powyższe to kompletne wymagania dla developera, które nie narzucają implementacji a jedynie oczekiwaną logikę tworzonego oprogramowania. Jeżeli w wymaganiach dodamy, że elementy Entities (tu “kapelusik” FakturyVAT) mają być rozdzielne, a w wypadku wątpliwości (niestety) narzucamy [[wzorzec active records]] (czasem [[wzorzec active table]]), to zabezpieczamy się przed bardzo częstą i szkodliwą praktyką wielu developerów, polegającą na projektowaniu repozytorium w postaci jednej dużej relacyjnej bazy danych dla całego systemu i stosowaniu bardzo złożonego mapowania ORM (mapowanie obiektowo-relacyjne), które w zasadzie zabije wszystkie korzyści z obiektowej ([[paradygmat OOAD]]) hermetyzacji (utrzymanie pełnej niezależności wszystkich elementów architektury). Drugim tego efektem jest z reguły drastyczny spadek wydajności z powodu bardzo wielu skomplikowanych zapytań do bazy danych.
Tak więc, warto prowadzić analizę rzetelnie, bez nadmiaru “zwinności” i z pełnym zrozumieniem problemu. Pochopne decyzje, rozpoczynanie implementacji bez posiadania projektu całości, to najczęstsze przyczyny nieudanych projektów, projektów trwających i kosztujących znacznie więcej niż planowano…
Bo najważniejsi w analizie, Panie, są Aktorzy…
@”rozpoczynanie implementacji bez posiadania projektu całości”
Często dochodzę do wniosku, że podejście opisane powyższym zdaniem bardzo często szybciej i taniej prowadzi do zadowolenia klienta i dostawcy – tak mi wychodzi z projektów 🙂
Odnosząc się do przykładu: dostarczenie aplikacji do fakturowania w 50% (a może i 80% :)) spełniającej oczekiwania klienta w <20% czasu (budżetu) wraz z promesą na ulepszanie w ramach budżetu to bardzo często droga do sukcesu.
Kluczem są:
1. lekkie i wydajne narzędzia programistyczne, np. języki skryptowe lub też języki specjalizowane
2. komunikacja w zespole; współpraca ekspertów (analityków) z programistami wychodząca poza formalne dokumentacje.
3. koncentracja zespołu – możliwa dzięki krótszej "taśmie produkcyjnej" i szybszym czasom dostarczania poszczególnych funkcjonalności
Owszem ?rozpoczynanie implementacji bez posiadania projektu całości? nie raz sprawdza się i tak jest.
Jednak nie raz mam możliwość widzieć ten sam projekt realizowany “dwiema metodami” (jestem często angażowany do projektów nieudanych by zacząć jeszcze raz to samo). Z moich obserwacji i wyliczeń wynika, że projekty “zwinne” zaczynają mieć kłopoty gdy wartość pracy przekracza 75/100 tys. zł. Drugi przypadek, to projekty, w których logika systemu nie była znana i zrozumiana w momencie rozpoczęcia i jej złożoność zaskoczyła wszystkich.
Warto tu dodać, że owe mityczne 80% funkcjonalności dostarczone w 20% czasu to najczęściej proste, z minimalną logiką, CRUD’y. Schody zaczynają się gdy trzeba zaimplementować skomplikowaną logikę. Nie jest problemem implementacja usługi wystawienie faktury, schody się zaczynają, gdy np. cennik produktów przestaje być zbiorem wartości wpisywanych “z palca” a zaczyna być pewna logika promocji, kosztów, cen bazowych i limitów kupującego… wtedy zwinne metody najczęściej się kończą…
80/20 nie wynika z łatwości implementacji – bo CRUDy są przeważnie dostępne “z pudełka” i implementacja to 90% budżetu – i to nie były projekty trudne, niebezpieczne itp.
Wydaje mi się, że bardzo często problemem nie jest sam poziom komplikacji tylko JAKOŚĆ ekspertów i ewentualne sposoby na podniesienie tej jakości: np. analiza, dokumentowanie lub lepsza komunikacja.
W projektach, w których brałem udział bardzo często na wielkość budżetu projektu miała znacznie większy wpływ ilość zainteresowanych osób (proporcjonalnie) ze strony klienta niż poziom komplikacji problemu 🙂
“W projektach, w których brałem udział bardzo często na wielkość budżetu projektu miała znacznie większy wpływ ilość zainteresowanych osób.” Jak budżet zależy od liczby zainteresowanych osób??? Co do “Jakości ekspertów” po stronie Klienta to ona NIGDY nie będzie lepsza bo to nie analitycy… Moim zdaniem to kolejny MIT AGILE: Użytkownik specyfikuje (artykułuje, potrafi to zrobić) wymagania.
Wynika to głównie ze zwiększonego nakładu na komunikację: szczegółowe dokumentowanie i wyjaśnianie dokumentacji, spotkania, mailowanie, konsultowanie, czym więcej “głów” tym więcej “genialnych pomysłów” zmieniających koncepcję itd.
Same spotkania kilku/kilkunasto-osobowe mogą pożerać budżet w tempie sprinterskim 🙂
Zbyt duże zespoły ekspertów i decydentów “rozmywają” kompetencje i odpowiedzialność.
To kolejne potwierdzenie tezy, że sesje JAD, permanentne spotkania z przyszłymi użytkownikami itp. podnoszą koszty i wprowadzają chaos… Zacytuje pewnego programistę z pewnego forum: “Przerabiałem _zręczne_ metodologie. Staram się od nich trzymać jak najdalej, wprowadzają tylko chaos i irytują. Muszę wiedzieć co ma być na końcu.”
Upraszcza Pan: to nie jest potwierdzenie tej tezy 🙂
JAD to co innego niż nadmiar ekspertów/decydentów po stronie klienta.
Ja znam programistów o całkowicie odmiennych poglądach 🙂
To nie uproszczenie a fakty… ja zmieniłem poglądy po tym, jak zacząłem te same projekty realizować w dwóch “metodykach”: zwinnych i formalnych. Od pewnego poziomu wielkości projekty zwinne zawsze dawały znacznie gorsze wyniki i faktycznie jednym z kluczowych powodów tych porażek był czas zjadany na spotkania z użytkownikami, permanentne zmiany wymagań i brak odpowiedzialności za wymagania czyli zupełny brak panowania nad zakresem projektu. To tylko statystyki a nie widzimisię…
Znam wielu programistów, którzy po pracy w projektach bardziej sformalizowanych (ale nie ciężkimi metodykami) odeszli od “zamiłowania” do Agile, tych co zmienili się w odwrotna stronę ja osobiście nie znam. Po drugie projekty “fixed price” bardzo uczą pokory “zwinne zespoły”.
Agile nie oznacza braku “panowania nad projektem”. Agile nie oznacza częstych spotkań z klientem, permanentnych zmian i braku odpowiedzialności. Problemy, które Pan opisał nie są związane z metodyką, tylko się zdarzają na każdym projekcie niezależnie od metodyki – spotyka się je często w projektach prowadzonym wg metodyk “tradycyjnych”. Niezależnie od metodyki jeśli klient zmienia wymagania to budżet się rozjeżdża, a czy np. do zmiany potrzeba stosu kwitów i spotkań komitetu sterującego czy też wystarczy mail to insza inszość 🙂
Paradoksalnie więcej kontrolowania nie oznacza większej kontroli nad projektem 🙂
Co do programistów, to każdy jest inny. Widocznie polubili papierki zamiast programowania :). Ale na serio: stosowanie Agile bardzo mocno zależy od narzędzi programistycznych, które się stosuje. Narzędzia muszą wspierać Agile – głównie chodzi o prototypowanie i szybkość zmian. Przy narzędziach – nazwijmy je “wolnymi” – Agile może się nie sprawdzić, bo “zwinność” jest zabijana “ociężałością” np. języka programowania i zamiast zysków jest strata i zniechęcenie. Drugi problem to mieszanie ról na projekcie. Agile nie oznacza likwidacji roli analityka, a to często się zdarza. Mówiąc wprost, sporo świetnych programistów, niezbyt lubi gadać z klientami – nie wszyscy też mają ku temu predyspozycje.
Agile różni się bardzo od innych metodyk, ponieważ nie daje dokładnego przepisu na działanie, a zakłada, że stosujący tę metodykę będą się zwinnie adaptować w zależności od potrzeb – BTW: jak dla mnie SCRUM obrósł w tłuszcz i przestał być Agile 🙂
Fakt Agile nie “trzyma klienta za jaja” kwitami zakłada podejście win-win (chyba już nie trendy :)) – takie podejście uważam za bardziej efektywne, bo i tak w ostatecznym rozrachunku obie strony dążą do porozumienia.
Ja patrzę na projekty przez pryzmat efektywności wyrażonej w budżecie i czasie (zadowolenie dostawcy) oraz zadowoleniu klienta z produktu. A ten współczynnik jest w projektach Agile, których brałem udział znacznie wyższy niż np. prowadzonych metodykach tradycyjnych.
Podejście win-win jest jak najbardziej słuszne (u mnie nadal ;)). Ogólnie idea Agile sama w sobie nie jest zła, ona jest po prostu zbyt optymistyczna i ufna w założeniach (zaryzykuje nawet słowo; utopijna): klient w spójny, kompletny i zrozumiały dla nas sposób, powie co potrzebuje, my go dobrze zrozumiemy i stworzymy oprogramowanie, które mu pomoże.
Problem w tym, że ryzyko w tak prowadzonym projekcie jest bardzo duże… (statystyki!). Te minimum dokumentów to nawet nie tyle dokumenty jako d…pochrony a przemyślane i zweryfikowane projekty. Programiści, którzy przeszli na “ciemna stronę mocy water-fall” to efekt tego, że praca z klientem, który jednak nie potrafi “w spójny, kompletny i zrozumiały dla nas sposób powie co potrzebuje” jest po prostu frustrująca… (wspomniany nadmiar pracochłonności z winy klienta)….
Ja nie mam nic przeciwko Agile, ja jedynie widzę, że to w 75% przypadkach nie działa… :(, oczywiście mowa o projektach powyżej pewnej skali (budżety ponad 75/100 tys. zł)
“…klient w spójny kompletny i zrozumiały dla nas sposób, powie co potrzebuje, my go dobrze zrozumiemy i stworzymy oprogramowanie, które mu pomoże.”
Jest właśnie odwrotnie 🙂 Główną intencją Agile jest, że klient nie wie czego chce, nie jest wstanie pracować na abstrakcji (dokumentacji), nie rozumie notacji, że biznes szybko się zmienia itd.
Mam wrażenie, że obaj mówimy o całkowicie INNYCH Agile 🙂
Agile to nie “wolna amerykanka”,ale narzuca myślenie, jest bardziej skoncentrowany na celu (win-win) niż metodyki tradycyjne.
“Główną intencją Agile jest, że klient nie wie czego chce,”, więc jak te wymagania “odkryć”?
Ha, tu jest pies pogrzebany ! 🙂
Są dwie szkoły: jedna mówi, pytaj i pisz, a druga pytaj i działaj.
Ile kosztuje i trwa działanie a ile pisanie?
Paradoksalnie rozpoczęcie od działania kosztuje przeciętnie 2x mniej 🙂
Odpowiadając zacytuję Edwarda Yourdona z jego książki o analizie obiektowej: “przy budowie budy dla psa tak, przy budowie małego domu z reguły już nie, przy budowie wieżowca jest to tragedia”. Proszę to traktować jedynie jako wymianę wiedzy, ja mam kontakt z kilkoma różnymi projektami rocznie czyli zespołami, metodami pracy itp…. mam porównanie…. wypada mi zgodzić się z Yourdonem….
Przy okazji gorąco polecam ksiązkie http://komputeks.pl/marsz-ku-klesce-poradnik-dla-projektanta-systemow-wydanie-ii-p-2816.html
i ten artykuł:
http://it-consulting.pl/autoinstalator/wordpress/2011/10/10/slabosci-tradycyjnych-metod-wytwarzania-it-czy-na-pewno-slabosci/
Budowanie budynków i aplikacji jest podobne… tylko w podobnym słownictwie 🙂 poza tym różni się kolosalnie. Czy mogę w budynku w kilka sekund zmienić miejsce okna, drzwi, czy przesunąć ściany? Czy budując wieżowiec mogę jednocześnie skopiować go w inne miejsce? Czy mogę wrócić do poprzedniej wersji z repozytorium?
Wręcz “karalne” porównanie i uproszczenie 🙂
Potem następuje łatwe przeniesienie tego myślenia do np. “stanu surowego”, co wychodzi przy pokazywaniu prototypu. Pojawiają “złe” myśli w głowie klienta: czemu ja tak dużo płacę, jeśli to w dzień/dwa jest gotowe (stan surowy i to zamknięty) 🙂
I zaczyna się “prostowanie myślenia”, że to tylko prototyp/wydmuszka, że trzeba dopisać kod pod spodem, że obsługę błędów i odporność na “użytkownika” zaimplementować, że optymalizować trzeba itd. A wszystko wynika z prostego porównania do budownictwa 😀
Budynki i oprogramowanie nie różnią się – są dziedzinami inżynierii, to że coś można w kilka sekund zmienić to tylko efekt technologii, podobnie jak kiedyś w starym programatorze pralki nie dało się szybko zmienić nic a teraz programator to programowany procesor i można go zmienić w sekundę, ale problem jakości prania pozostaje taki sam…
Co do płacenia “dużo”… jeżeli ktoś nie potrafi przed rozpoczęciem pracy jej wycenić i opisać tego co dostarczy, to znaczy że rozpoczynając pracę nie ma pojęcia za co się łapie… Statystyki projektów (tych większych oczywiście) są bezlitosne: projekty bez analizy wymagań i opracowania projektu całości kosztują więcej (śr. 60%) i trwają dłużej (śr. o 200%)…
Proponuje zakończyć dialog, tak na prawdę nie mają znaczenia “zwinne argumenty”, znaczenie mają konkretne projekty i sytuacje gdy angażowani są na życzenie klientów analitycy i projektanci… a zapewniam, że ich – klientów – celem nie jest trwonienie pieniędzy a coś wręcz odwrotnego. Drugi paradoks: wielu developerów mozolnie “sprzedaje” swoje zwinne metody pracy właśnie argumentami w rodzaju będzie szybciej i taniej. Pracy analityka, podobno “zbędnego kosztu w projekcie” nikt nie sprzedaje, doświadczeni klienci sami przychodzą z “zamówieniem”: tym razem chcemy mieć przed podpisaniem umowy z programistami opis tego co mają dostarczyć. I proszę ich przekonywać a nie mnie, bo ja tak na prawdę realizuje prośby klientów, niczego im nie wmuszam.
Ciekawe tylko czemu projekty informatyczne prowadzone tradycyjnie (przed pojawieniem się Agile) miały taką niską skuteczność? 🙂
Zatem zamykamy.
ich skuteczność wcale nie wzrosła od 30 lat :), EOT