Temat: Dlaczego tak rzadko używa się UML w projektach IT?

To tytuł dość burzliwego wątku na LinkedIn, opinie tam bywały tak skrajne, że pomyślałem, że tu i Was podpuszczę do takiej dyskusji.

Do mnie najbardziej dociera to tłumaczenie, potwierdza to moja praktyka w 100%, nie tylko inżynierska ale także np. fotograficzna: "Bo większość ludzi bardzo dobrze odczytuje obrazy ale bardzo mało ludzi potrafi je efektywnie tworzyć" (Van Luu w dyskusji na grupie UML Lovers/LinkedIn)

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Ja mam jedno spostrzeżenie dotyczące naszej Polskiej rzeczywistości. Pracowałem w kilku firmach i generalnie podejście do UML, testów jednostkowych i innych dobrych praktyk jest takie, że "nie ma na to czasu". Przynajmniej w przypadku aplikacji webowych dominujący paradygmat zarządzania projektem to "najpierw koduj potem martw się". Później oczywiście wychodzą różne kwiatki ale nikt z tego nie wyciąga wniosków i tak koło się kręci.

Pewnie w korporacjach używa się UML, bo jest to część dokumentacji projektów. Natomiast w mniejszych firmach, dominują luźne specyfikacje, do tego zwykle nie w formie pisanej a mówionej...

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Witam

Wchodząc na ten temat miałem już gotową odpowiedź. Okazało się, że pokrywa się z opinią Jarka.

Z moich obserwacji wynika, że faktycznie niemal każdy przeczyta diagram UML. Duży problem jest z rysowaniem. Podczas tworzenia diagramów (korzystając z dowolnego narzędzia) posiadasz masę opcji. Nagle okazuje się, że jest więcej rodzajów linii, kilka rodzajów grotów, różne sposoby łączenia elementów itp.

Bardzo często ludzie rozumieją diagramy "z kontekstu". Podam banalny przykład posługując się najprostszym językiem: jaki grot ma strzałka w linii przedstawiającej dziedziczenie. Czytając diagram często nie zwracamy na to uwagę. Ale tworząc go, bardzo szybko pojawiają się obawy: czy dobrze to robię, czy nie popełniłem gdzieś błędu.

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Wojciech Soczyński:
Ja mam jedno spostrzeżenie dotyczące naszej Polskiej rzeczywistości. Pracowałem w kilku firmach i generalnie podejście do UML, testów jednostkowych i innych dobrych praktyk jest takie, że "nie ma na to czasu". Przynajmniej w przypadku aplikacji webowych dominujący paradygmat zarządzania projektem to "najpierw koduj potem martw się". Później oczywiście wychodzą różne kwiatki ale nikt z tego nie wyciąga wniosków i tak koło się kręci.

paradoks ten tłumaczy chyba wypowiedź pewnego mojego niedoszłego partnera, przekazałem im kiedyś dokumentację z zapytaniem o cenę wykonania, usłyszałem: "fajna dokumentacja, gdybyśmy takie robili projekty trwały by pewnie o połowę krócej jednak klienci nie chcą płacić za opracowywanie takich dokumentów, płaca za nasz produkt i płaca jak projekt się przedłuża więc nie musimy aż tak dobrze dokumentować."

Pewnie w korporacjach używa się UML, bo jest to część dokumentacji projektów. Natomiast w mniejszych firmach, dominują luźne specyfikacje, do tego zwykle nie w formie pisanej a mówionej...

Widzę dwa powody:

Wydaje mi się, że niestety małe firmy programistyczne, pracują pod dyktat swoich zleceniodawców. Nie wszystkie na szczęście. To zjawisko podobne jak w małych warsztatach: przyjeżdża klient i mówi "Proszę mi wymienić sprzęgło bo mi coś trzeszczy jak zmieniam biegi". Mechanik robi co każą, za tydzień ten sam klient podjeżdża i mówi "Nadal strasznie trzeszczy", na co mechanik "Ale Pan prosił by wymienić sprzęgło wiec wymieniłem", może teraz wymienimy rozrząd?.

Drugi powód to brak wiary wielu firm w skuteczność projektowania, trzeci to po prostu brak brak specjalisty z powodów jak w pierwszym poście (nie mają analityka) i zwykła niechęć do oddania tej roboty komuś.

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Dawid P.:
Z moich obserwacji wynika, że faktycznie niemal każdy przeczyta diagram UML. Duży problem jest z rysowaniem.

Swego czasu usłyszałem ciekawe porównanie: do czytania wierszy Mickiewicza trzeba się tylko nauczyć czytać, do pisania wierszy trzeba być Mickiewiczem".

Mnie zastanawia zawsze: skoro powszechnie wiadomo, że projekty nieudokumentowane są kosztowniejsze to dlaczego sami wykonawcy nadal ich nie dokumentują?Jarek Żeliński edytował(a) ten post dnia 12.01.11 o godzinie 12:30

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Mnie zastanawia zawsze: skoro powszechnie wiadomo, że projekty nieudokumentowane są kosztowniejsze to dlaczego sami wykonawcy nadal ich nie dokumentują?

Bo najczęściej coś trzeba zrobić "na wczoraj" a dokumentację dorobi się....potem ?Anna Pryjomska edytował(a) ten post dnia 12.01.11 o godzinie 12:34

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Jarek Żeliński:

Wojciech Soczyński:
Ja mam jedno spostrzeżenie dotyczące naszej Polskiej rzeczywistości. Pracowałem w kilku firmach i generalnie podejście do UML, testów jednostkowych i innych dobrych praktyk jest takie, że "nie ma na to czasu". Przynajmniej w przypadku aplikacji webowych dominujący paradygmat zarządzania projektem to "najpierw koduj potem martw się". Później oczywiście wychodzą różne kwiatki ale nikt z tego nie wyciąga wniosków i tak koło się kręci.

paradoks ten tłumaczy chyba wypowiedź pewnego mojego niedoszłego partnera, przekazałem im kiedyś dokumentację z zapytaniem o cenę wykonania, usłyszałem: "fajna dokumentacja, gdybyśmy takie robili projekty trwały by pewnie o połowę krócej jednak klienci nie chcą płacić za opracowywanie takich dokumentów, płaca za nasz produkt i płaca jak projekt się przedłuża więc nie musimy aż tak dobrze dokumentować."

Pewnie w korporacjach używa się UML, bo jest to część dokumentacji projektów. Natomiast w mniejszych firmach, dominują luźne specyfikacje, do tego zwykle nie w formie pisanej a mówionej...

Widzę dwa powody:

Wydaje mi się, że niestety małe firmy programistyczne, pracują pod dyktat swoich zleceniodawców. Nie wszystkie na szczęście. To zjawisko podobne jak w małych warsztatach: przyjeżdża klient i mówi "Proszę mi wymienić sprzęgło bo mi coś trzeszczy jak zmieniam biegi". Mechanik robi co każą, za tydzień ten sam klient podjeżdża i mówi "Nadal strasznie trzeszczy", na co mechanik "Ale Pan prosił by wymienić sprzęgło wiec wymieniłem", może teraz wymienimy rozrząd?.

Drugi powód to brak wiary wielu firm w skuteczność projektowania, trzeci to po prostu brak brak specjalisty z powodów jak w pierwszym poście (nie mają analityka) i zwykła niechęć do oddania tej roboty komuś.

Ja widzę jeszcze jeden powód, małe firmy programistyczne są małe(o ile już mają kilka lat) bo ich szefowie są krótkowzroczni i np dlatego nie używają tego typu narzędzi. Robią wszystko na wczoraj, byle zadowolić się krótkookresowym zyskiem, natomiast nie myślą co będzie za kilka dni, tygodni, miesięcy. Szefowie dużych firm już przerobili takie rzeczy i dlatego ich firmy są duże ;).

Zauważam, też jeszcze jedną prawidłowość, nawet gdy robi się dokumentację to nijak ma się ona do późniejszego wykonania. Jak już jest jakaś specyfikacja wymagań to zwykle jest to pisany dokument, który inaczej interpretuje klient a inaczej wykonawca. Co więcej programiści wykonawcy też interpretują go różnie ;P, a tu wystarczyłby UML.

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Ja mam inne doświadczenia. W mojej firmie używamy UML intensywnie. Nie istnieje ani jeden stworzony przez nas projekt, który nie posiada przynajmniej wysokopoziomowej analitycznej dokumentacji stworzonej z wykorzystaniem UML. Tak jest dużo lepiej i taniej testować pewne koncepcje i rozwiązania. Zmniejsza to ilość iteracji na etapie implementacji nawet 2-3 krotnie.
Pracowałem natomiast kilka razy dla dużych firm - w żadnej nie spotkałem UML-a - ba jakiejkolwiek formalnej notacji. Wydaje mi się, że wynika to z tego, że w dużych firmach metody prowadzenia projektów, wytwarzania oprogramowania itp tworzyli ludzie, którzy UML nie znają. To ludzie którzy tworzyli systemy strukturalnie - systemy duże i bardzo duże i robili to bez UML a swoje koncepcje przedstawiali na niedefiniowalnych schematach blokowych własnej produkcji metodą kartki i ołówka.
A młodszy staff nie ma możliwości przebicia się z nowymi tematami, bo "bieżączka" zabija takie projekty.

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Jarek Żeliński:
Mnie zastanawia zawsze: skoro powszechnie wiadomo, że projekty nieudokumentowane są kosztowniejsze to dlaczego sami wykonawcy nadal ich nie dokumentują?

Jest wiele sytuacji, gdzie można zapytać "dlaczego tego nie robicie, skoro powszechnie wiadomo, że to naraża na problemy"? I równie częsta jest odpowiedź: "Bo nie widzimy takiej potrzeby, nigdy nie naraziło nas to na problemy na tyle duże, by się tym przejmować, a funkcjonujemy na rynku nie pierwszy rok. Swoje robimy, zarabiamy, więcej i tak nie przerobimy. Jeśli zajdzie potrzeba, wdrożymy zmiany".

A na stwierdzenie "Ale moglibyście zarobić więcej" często pada odpowiedź "Przecież wiemy. Nie mamy na razie potrzeby stawiać z tego tytułu na głowie dotychczasowego modelu i tempa pracy".

Pamiętajmy o łacińskiej sentencji, która bardzo często trafnie opisuje rzeczywistość: Ten uczynił, komu to przyniosło korzyść.Adrian Olszewski edytował(a) ten post dnia 12.01.11 o godzinie 13:42

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Wojciech Soczyński:
Ja widzę jeszcze jeden powód, małe firmy programistyczne są małe(o ile już mają kilka lat) bo ich szefowie są krótkowzroczni i np dlatego nie używają tego typu narzędzi. Robią wszystko na wczoraj, byle zadowolić się krótkookresowym zyskiem, natomiast nie myślą co będzie za kilka dni, tygodni, miesięcy. Szefowie dużych firm już przerobili takie rzeczy i dlatego ich firmy są duże ;).

Moja rozmowa z przed dwóch lat z prezesem takiej właśnie małej firmy programistycznej:
- ile Pan Panie Jarku zapłacił za ten system CASE do modelowania i dokuemntowania?
- jakieś 400 USD
- oj, to dużo.... u mnie się to nie sprawdzi
(a właśnie kończył projekt za 210 tys. zł)

Zauważam, też jeszcze jedną prawidłowość, nawet gdy robi się dokumentację to nijak ma się ona do późniejszego wykonania. Jak już jest jakaś specyfikacja wymagań to zwykle jest to pisany dokument, który inaczej interpretuje klient a inaczej wykonawca. Co więcej programiści wykonawcy też interpretują go różnie ;P, a tu wystarczyłby UML.

Pewien architekt programista nie takiej małej firmy na innym forum napisał mi: my dokumentację analityków olewamy jak tylko okazuje się, że nam przeszkadza, klient o tym nawet nie wie bo i tak kodu nie sprawdzi...... (znaczy się nie pozwala na uproszczenia).Jarek Żeliński edytował(a) ten post dnia 12.01.11 o godzinie 14:21

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Ech, to podejście do klienta ("byle faktura była opłacona") :D :)

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Adrian Olszewski:
Jest wiele sytuacji, gdzie można zapytać "dlaczego tego nie robicie, skoro powszechnie wiadomo, że to naraża na problemy"? I równie częsta jest odpowiedź: "Bo nie widzimy takiej potrzeby, nigdy nie naraziło nas to na problemy na tyle duże, by się tym przejmować, a funkcjonujemy na rynku nie pierwszy rok. Swoje robimy, zarabiamy, więcej i tak nie przerobimy. Jeśli zajdzie potrzeba, wdrożymy zmiany".

A na stwierdzenie "Ale moglibyście zarobić więcej" często pada odpowiedź "Przecież wiemy. Nie mamy na razie potrzeby stawiać z tego tytułu na głowie dotychczasowego modelu i tempa pracy".

ale czy to nie przypomina argumentu: "po co mi lepszy silnik, który mniej pali, skoro jeżdżę tym co mam, paki dużo ale klienci płacą..."

Ja myślę, że jak powoli rozejdzie się, że projekt można taniej i definitywnie skończą się projekty "czas i materiał" to niektóre betonowe zarządy zmienią podejście.

Symptomatyczne jest podejście wielu menedżerów i właścicieli firm IT. Jeden w przerwie konferencji zapytał mnie kiedyś wprost: "po co Pan takie rzeczy opowiada, nie lepiej jak prac za każdy protokół wykonanych prac????? "

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Adrian Olszewski:
Ech, to podejście do klienta ("byle faktura była opłacona") :D :)

ale to chyba raczej metoda spalonej ziemi....

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Mateusz Kurleto:
Ja mam inne doświadczenia. W mojej firmie używamy UML intensywnie. Nie istnieje ani jeden stworzony przez nas projekt, który nie posiada przynajmniej wysokopoziomowej analitycznej dokumentacji stworzonej z wykorzystaniem UML. Tak jest dużo lepiej i taniej testować pewne koncepcje i rozwiązania. Zmniejsza to ilość iteracji na etapie implementacji nawet 2-3 krotnie.

Tylko widzisz Mateusz, Ty zrobiłeś po mnie projekt, który inne konkurencyjne
firmy oceniały na dwa razy dłużej i trzy raz drożej... po za drobnymi poprawkami oddałeś go od razu OK niemalże w wersji 1.0 :),Jarek Żeliński edytował(a) ten post dnia 12.01.11 o godzinie 14:26

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Jarek Żeliński:
ale czy to nie przypomina argumentu: "po co mi lepszy silnik, który mniej pali, skoro jeżdżę tym co mam, paki dużo ale klienci płacą..."

Wszystko rozbija się o kontekst...

Czasem ten silnik, który się ma, pali tyle, że jest OK. Są samochody, które mają 75KM i 350KM. Czasem ma się samochód, który spala 12/100, a mógłby 9/100, ale nie stanowi to wielkiego obciążenia domowego budżetu, a inne zalety auta rekompensują spalanie. Zawsze można lepiej, zawsze można więcej, ale nie zawsze trzeba :)

Pytanie raczej dotyczy sytuacji, gdy faktycznie trzeba było, a nie - można było. I myślę, że dotyczy to konkretnego projektu. To jak z programowaniem - czasem programik można nastukać w VBA w Excelu (i zaprzęganie do tego "best practices" i "top tools" byłoby nie tylko przerostem formy nad treścią, ale i właśnie naciąganiem na zbędne koszty) i naprawdę wystarczy, a czasem trzeba stawiać hurtownię danych i zatrudniać "finalistów olimpiad programistycznych" (taki skrót myślowy).

Problem pojawia się wtedy, jak się naciąga klientów na koszta, których można było uniknąć przez stosowanie właściwego podejścia do problemu,a klient się na to godzi, bo się nie orientuje.

Symptomatyczne jest podejście wielu menedżerów i właścicieli firm IT. Jeden w przerwie konferencji zapytał mnie kiedyś wprost: "po co Pan takie rzeczy opowiada, nie lepiej jak prac za każdy protokół wykonanych prac????? "

A, tam, gdzie rządzi manager-od-słupków, który nie był nigdy "technicznym", za to często bywał na tzw. "szkoleniach" typu "wydaj-kasę-za-gadanie", to choćby Pan z siebie wyszedł..... :)

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Adrian Olszewski:
A, tam, gdzie rządzi manager-od-słupków, który nie był nigdy "technicznym", za to często bywał na tzw. "szkoleniach" typu "wydaj-kasę-za-gadanie", to choćby Pan z siebie wyszedł..... :)

to tylko potwierdza tezę, że najczęściej u takich "menedżerów" interes klienta nigdy nie będzie interesem dostawcy..

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Jarek Żeliński:

Mateusz Kurleto:
Ja mam inne doświadczenia. W mojej firmie używamy UML intensywnie. Nie istnieje ani jeden stworzony przez nas projekt, który nie posiada przynajmniej wysokopoziomowej analitycznej dokumentacji stworzonej z wykorzystaniem UML. Tak jest dużo lepiej i taniej testować pewne koncepcje i rozwiązania. Zmniejsza to ilość iteracji na etapie implementacji nawet 2-3 krotnie.

Tylko widzisz Mateusz, Ty zrobiłeś po mnie projekt, który inne konkurencyjne
firmy oceniały na dwa razy dłużej i trzy raz drożej... po za drobnymi poprawkami oddałeś go od razu OK niemalże w wersji 1.0 :),

Dobre wymagania z których myśmy zrobili sobie projekt i na nim testowali zgodność z wymaganiami, a dopiero z naszego projektu robiona była implementacja.
Może nie mamy na każdą rolę osobnej osoby w firmie, ale przy projektach pracuje i analityk biznesowy i architekt i projektant doskonale znający technologię wytwarzania i nasze zasoby do Re-Use.
Ja na przykład jeżeli projekt ma sensowny budżet w ogóle nie mówię o kosztach inżynierii wymagań. Zakładam, że są.
Szacuję nakłady na wytwarzanie oprogramowania metodą Use-Case Points i mam historię z porównaniem szacunek - rzeczywistość. W projektach robionych na bazie porządnie opracowanych wymagań - czyli tak jak co do ogółu zgadzamy się, że winny być robione - mam oszacowania z dokładnością do 10%, bez nich do 30%, w dodatku czas poświęcony na implementację pojedyńczego UCP w przypadku dobrze określonych wymagań nawet zakładając ich zmienność spada o ok 30%.
Analiza opłacalności jest prosta. Koszty projektu wykonywanego z dobrej analizy są od ok 20 do 40% niższe. A tylko tyle dlatego, że my sami prototypujemy modele w UML i intefejsy a nie całe aplikacje.
W kwestii olewania analizy przy implementacji - czekam na rynek audytów po-wdrożeniowych aż zacznie rosnąć. Mam już dobrą kancelarię do współpracy, będziemy żyć lepiej niż branżą windykacyjna:PMateusz Kurleto edytował(a) ten post dnia 12.01.11 o godzinie 15:46

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Mateusz Kurleto:
W kwestii olewania analizy przy implementacji - czekam na rynek audytów po-wdrożeniowych aż zacznie rosnąć. Mam już dobrą kancelarię do współpracy, będziemy żyć lepiej niż branżą windykacyjna:P

ja zmałpowałem z budowlanki zapis w umowie: nadzór autorski na projektem realizowanym na bazie mojej dokumentacji :))), czego troszkę dotknąłeś ;)

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Moim zdaniem jest to problem związany z tym że uml to analiza. Analiza to próba porządkowania, która często pokazuje braki (sprzeczne wymagania, nie wystarczająca wiedza, niedopowiedzenia itp.). Po co komu takie "PROBLEMY" na początku projektu? Przecież klient oczekuje produktu!!! Poza tym za projekt zabraliśmy później więc nie bardzo wypada pójść do klienta i mówić, że czegoś jeszcze potrzebujemy.
Podsumowując, nie jest problem UML'a a podejścia (oczywiście to tylko moje zdanie ;).

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Wojciech Kłujszo:
Moim zdaniem jest to problem związany z tym że uml to analiza. Analiza to próba porządkowania, która często pokazuje braki (sprzeczne wymagania, nie wystarczająca wiedza, niedopowiedzenia itp.). Po co komu takie "PROBLEMY" na początku projektu? Przecież klient oczekuje produktu!!! Poza tym za projekt zabraliśmy później więc nie bardzo wypada pójść do klienta i mówić, że czegoś jeszcze potrzebujemy.
Podsumowując, nie jest problem UML'a a podejścia (oczywiście to tylko moje zdanie ;).

Niestety muszę potwierdzić, zbyt dobra dokumentacja jest szkodliwa do wielu dostawców, cytat z artykułu: "Dla dostawców powstaje tu kluczowe ryzyko: ich produkt może, w części lub całości, nie spełniać wymagań określonych przez model firmy i specyfikację wymagań. Może się okazać się, że zupełnie nie nadaje się on dla tej konkretnej firmy."

Dotyczy to także oprogramowania dedykowanego bo dostawcy korzystają z różnych gotowców i nie raz wciskają je niestety jako "ich produkt developerski"...

dla zainteresowanych cały artykuł o analiza przedwdrożeniowych: http://it-consulting.pl/autoinstalator/wordpress/index...