Od czasu do czasu wpadają mi do skrzynki email “niuslettery”, które gdzieś tam czasem zamawiam, głównie z powodów poznawczych. Oto jeden z nich…

Nie jest tajemnicą, że na rynku mamy różne metody pracy i wszystkie mają swoich zwolenników i przeciwników czy może raczej krytyków. Tym razem przedmiotem “badania” był sposób opisania problemu i wnioski jakie autor wyciągnął.

Wprowadzenie

Zaczęło się od opisania cech zewnętrznych dokumentacji:

Projekt rzeczywiście robił wrażenie: gruby z zewnątrz, a w środku wszystko szczegółowo rozrysowane. Nawet rozłożenie płytek w łazienkach zostało precyzyjnie zaplanowane tak, że odniosłem wrażenie, iż sam bym sobie wykończył to mieszkanie, posługując się rzeczonym projektem.[…]

Okazało się, że Wykonawca pracując na bazie tego dokumentu, odkrył w toku realizacji projektu, że nie udało się wpasować zakupionych płytek…

Wnikliwa analiza w składzie: ja, ekipa i architekt zaowocowała oczywistą odpowiedzią – do projektu wkradł się błąd. Płytki drewniane miały wysokość nie 30cm lecz 31,5cm ! […]

Analityk w zespole, analityk jako PO, analityk jako Proxy PO…itd. Każda z tych konfiguracji ma sens. Tyle, że analityku! Twoim celem nie jest wysmażenie BPMNów, UMLi, czy cholera wie czego tam jeszcze. Twoim celem jest dostarczenie tego, czego chce klient. Wespół z innymi wykonawcami na przykład z zespołem deweloperskim. Nie bez powodu na rynku pojawiły się biura architektoniczne mające własne ekipy.

I tu zaczyna się problem z tym tekstem. Teza, że źródłem problemu jest “wysmażenie BPMNów, UMLi, czy cholera wie czego tam jeszcze” jest tak samo “oczywista” jak to, że złe zdjęcia z wesela są konsekwencją używania zbyt dobrego aparatu fotograficznego. Po drugie może i faktycznie “na rynku pojawiły się biura architektoniczne mające własne ekipy” ale po pierwsze prawo budowlane tego zabrania i Prawo Zamówień Publicznych także. A powód jest bardzo prosty: zmowa projektanta i wykonawcy to brak niezależnego nadzoru na realizacją. Po trzecie nie jestem przekonany, czy “celem jest dostarczenie tego, czego chce klient” bo jeżeli będzie chciał oprogramowania do łamania prawa podatkowego to co? Po czwarte: to wykonawca ma dostarczyć to co chce zamawiający, który najpierw powinien (sam lub z pomocą specjalisty) wyartykułować w jednoznaczny sposób to czego chce…

Zauważ, że w opisanym przykładzie nie można mieć żalu ani do architektów, ani do ekipy. Problem leżał w tym, że setup organizacyjny pracy był niewłaściwy. Architekci poprzez zakontraktowanie PROJEKTU mieli inny cel niż ekipa. […]

Ale jakiego PROJEKTU? Po drugie “ekipa” ZAWSZE ma inny cel: jest nim zysk na produkcie jaki dostarcza a nie niszczenie sobie marży realizowaniem zachcianek “usera” na swój koszt .. no chyba, że to projekt agile realizowany w trybie “czas i materiał”…

No

Projekt wykonawczy – bo o tym mowa – został wyceniony przez architektów na 6,1k. OK, pomyślałem, jeśli ma być dobrze i full profeska, to niech będzie. […]

I tu jest odpowiedź: jakim cudem i po co, na etapie planowania i przed wyborem wykonawcy ktokolwiek robi detaliczny projekt wykonawczy? Ten projekt (dokumentację) robi dopiero Wykonawca! Planowanie jakichkolwiek detali technicznych przed wyborem wykonawcy (a tym samym technologii wykonania) jest bardzo kiepskim pomysłem, raz że kosztownym, a dwa bardzo ryzykowanym (co autor tylko potwierdził).

A co na to rynek

Chociaż sam prowadziłem wiele szkoleń z UML, jestem raczej niechętny tego rodzaju formalnym notacjom. Ich intencja jest szczytna, ale prowokują one sytuacje, w których to chęć stworzenia poprawnego modelu zastępuje cele klienta. O wiele bardziej przemawiają do mnie nieformalne notacje “free form diagrams” prezentowane chociażby przez Simona Browna w “Software Architecture for Developers”.

Tu mam mega pytanie: jakiej jakości były to szkolenia, jeżeli prowadził je człowiek, który jawnie deklaruje że nie lubi, nie wie po co się używa, i nie potrafi używać notacji UML/BPMN (gdyby potrafił, nie napisał by, że służy do tworzenia detalicznych projektów wykonawczych na początkowym etapie tworzenia oprogramowania, polecam specyfikację MDA na stronie OMG.org, organizacji standaryzującej między innymi notację UML i BPMN ).

O tym, że, mało który deweloper używa UMLa zgodnie ze specyfikacją, nawet nie wspominam. [1]

To ostatnie zdanie to już chyba tylko spekulacje albo wąskie doświadczenie autora, ale skoro sam nie potrafi to na jakiej podstawie i jak ocenił innych? Otóż każdy developer programujący z użyciem obiektowych języków programowania bezbłędnie czyta modele UML z prostego powodu: obiektowe języki programowania operują tymi samymi pojęciami co notacja UML w obszarze opisu architektury czyli pojęciami: klasa, komponent, operacja, metody, atrybuty, wywołanie operacji, sekwencje wywołań, interfejsy. Do tego dochodzą obiektowe wzorce projektowe powszechnie implementowane w bibliotekach języków programowania (frameworkach).

Owszem wielu programistów (developerzy) raczej nie garnie się do samodzielnego tworzenia tych modeli, ale powód jest prosty: bo to ani nie jego rola ani specjalność, ma implementować projekt a nie projektować.

Mam wrażenie, że autor starał się zdyskredytować sformalizowane metody analizy i projektowania ale w moich oczach zdyskredytował się sam… Twierdzenie, że do wytworzenia oprogramowania wystarczy dobra wola developera i cel nazwany przez zamawiającego jest bardzo odważna…

Twierdzenie, że wystarczą wyłącznie proste, poglądowe rysunki wykonane rękami wykonawcy, być może dotyczy prostych portali internetowych, ale takie podejście do średniego nawet projektu biznesowego z rozbudowaną logika biznesową, raczej skończy się sporem w sądzie… Metody, które mogą być skuteczne przy remoncie łazienki, zastosowane do budowy biurowca w centrum miasta, prędzej zaprowadzą projekt do prokuratury i sądu niż do na podium po medal za efektywność…

Tak więc: mało, który developer używa UML to fakt, ale jak dostanie to czyta… To, że wielu z nich używa UML niezgodnie ze specyfikacją jest niestety prawdą, i być może jest to konsekwencją szkoleń, na których przekazuje się treści takie jak wyżej cytowane 🙁 …

Co do projektów z użyciem BPMN/UML pozwolę sobie tu przywołać moją dokumentację jaką opracowałem dla Kancelarii Senatu, powstała w ciągu miesiąca rękami jednej osoby (mojej), odbyły się tylko dwa krótkie spotkania z przyszłymi użytkownikami w celu uzgodnienia komunikacji w projekcie. OPZ powstał w zasadzie w całości na podstawie dokumentów otrzymanych od pracowników Kancelarii, oferenci przeczytali, nie mieli pytań i złożyli oferty. Projekt jest realizowany zgodnie z harmonogramem: OPZpublikacja.

Myślę, że każdy czytelnik, na bazie swoich doświadczeń, sam ostatecznie oceni cytowany artykuł…

Cytaty pochodzą z artykułu: https://www.michalbartyzel.pl/co-z-tym-analitykiem/

The Lost Art of Software Design ? Simon Brown ? YOW! 2019

[2019] “zwykłe szkice wystarczą, po co wchodzić w jakieś formalizmy”… czyżby? Polecam poniższy referat: