Znowu o tym, tak: o analizie, projektowaniu i … ryzyku. Czy analiza jest konieczna? Nie! To czemu służy? By prawdopodobieństwo tego, że uda się stworzyć i wdrożyć właściwe oprogramowanie było jak największe. Ale o co chodzi? Ano nie zawsze jest tak, że to prawdopodobieństwo jest wystarczająco duże! Ale po kolei.
Wprowadzenie
Obecnie na rynku coraz bardziej dominują tak zwane obiektowe metody analizy, projektowania i programowania. W czym problem? Jedyną namacalną rzeczą jest kod i od programowania (kodowania) nie ma ucieczki: kod musi powstać by powstało oprogramowanie. Pozostaje analiza i projektowanie – to można pominąć, można od razu kodować niczego nie analizując ani nie projektując.
Myślenie zamawiającego: Te dwa etapy, analiza i projektowanie, to dodatkowy koszt: może da się go uniknąć.
Myślenie programisty: Istniejący projekt to wiązanie mi rąk, mojej kreatywności i rozwoju: może uda się od razu zacząć kodować.
Nie raz programista, w sumie także wykonawca, dodaje sobie powyższe myślenie klienta: uniknę kosztu analizy i projektowania.
Obaj mają ten sam cel! Pominąć analizę i projektowanie!
A teraz po kolei i od końca. Posłużymy się definicjami a potem je jakoś razem pokleimy. Mimo, że podchodzę z dużą rezerwą do WIKI, posłużę się tymi stronami, gdyż są w większości redagowane przez ludzi związanych z informatyką, nie raz właśnie przez programistów programistów.
Programowanie obiektowe
Na początek definicja:
Programowanie obiektowe (ang. object-oriented programming) ? paradygmat programowania, w którym programy definiuje się za pomocą obiektów ? elementów łączących stan (czyli dane, nazywane najczęściej polami) i zachowanie (czyli procedury, tu: metody). Obiektowy program komputerowy wyrażony jest jako zbiór takich obiektów, komunikujących się pomiędzy sobą w celu wykonywania zadań.
Podejście to różni się od tradycyjnego programowania proceduralnego, gdzie dane i procedury nie są ze sobą bezpośrednio związane. Programowanie obiektowe ma ułatwić pisanie, konserwację i wielokrotne użycie programów lub ich fragmentów. (źr. WIKI)
Jak widać, mamy nowe narzędzie dla programistów, kolejna edycja strukturalizacji kodu. czasem spotykam się u programistów z definicją: programowanie obiektowe to układanie kodu w podprogramy łączące dane i operacje na nich. Tak więc tylko technologia. Drugi akapit tylko to podkreśla: tu tylko technologia.
Powstaje oprogramowanie.
Projektowanie obiektowe
I tu problem:
Przepraszamy, ale nie ma jeszcze artykułu ?Projektowanie obiektowe? w Wikipedii. (dziś jest 24 Maj 2011, znowu sprawdzam i nadal nie ma a jest 07 luty 2019).
Nie ma takiej definicji w polskim WIKI. Czyżby „nasi” nie projektowali?
Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. (źr, http://en.wikipedia.org/wiki/Object-oriented_design)
Uff, jednak projektują. Tak więc projektowanie obiektowe to zorientowany obiektowo (paradygmat obiektowy) proces rozwiązywania problemu poprzez projektowanie oprogramowania jako systemu komunikujących się obiektów. Tak wiec można przed rozpoczęciem kodowania, zaplanować to co stanie zakodowane. Gdzie indziej tak robią.
Powstaje projekt oprogramowania (przemyślany!).
[niestety, wbrew temu co piszą programiści, paradygmat obiektowy to nie łączenie danych i funkcji w obiekty, a budowanie systemu jako zestawu współpracujących obiektów reagujących w określony sposób na określone bodźce, obiekty są definiowane właściwościami jakimi są ich atrybuty i operacje, cechują się całkowitą hermetyzacją, czyni nie ujawniają swoich właściwości na zewnątrz.]
Analiza obiektowa
Kolejne podejście do Wikipedii:
Przepraszamy, ale nie ma jeszcze artykułu ?Analiza obiektowa? w Wikipedii. (dziś jest 24 Maj 2011, sprawdzam 07 luty 2019, nadal nie ma)
Mam pecha, nasi nie analizują. Znowu spoglądamy na strony anglosaskich WIKI:
Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a conceptual model of the information that exists in the area being analyzed. Analysis models do not consider any implementation constraints that might exist, such as concurrency, distribution, persistence, or how the system is to be built. Implementation constraints are dealt during object-oriented design (OOD). Analysis is done before the Design. (źr. http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design)
W dużym skrócie: analiza obiektowa (analiza zorientowana obiektowo) to opracowanie modelu pojęciowego informacji, opisującego badaną domenę (czyli analizowany obszar dziedzinowy, np. konkretna organizacja, firma naszego klienta). Kolejny etap to projektowanie obiektowe. Model analityczny nie powinien zawierać ograniczeń technologicznych (implementacyjnych), te ograniczenia powinny być brane pod uwagę dopiero na etapie projektowania (to praca programistów). I na koniec tragedia: analiza powinna być wykonana przed rozpoczęciem projektowania!
Powstaje obiektowy model elementów organizacji zamawiającego (polecam artykuł o Domain Driven Design).
Druga strona barykady: Analiza procesowa
Tradycyjnie idziemy do WIKI:
Przepraszamy, ale nie ma jeszcze artykułu ?Analiza procesowa? w Wikipedii. (24 Maj 2011)
No cóż, szukamy dalej:
Process analysis presents a chronological sequence of steps that explain how something is done, how something happens, or how readers can do something. (źr. http://www.tcc.edu/students/resources/writcent/handouts/writing/process.htm).
Coś mamy: analiza procesowa prezentuje w postaci chronologicznej sekwencji kroków, to jak coś powstaje, co się wydarza lub jak można coś zrobić. Piękna definicja. Ta prezentacja to, w kontekście biznesowym, model (mapa) procesów biznesowych.
Mamy wiec uporządkowaną wiedzę o firmie (organizacji) zamawiającego oprogramowanie. Tu także powstaje opis tego po co i gdzie tego oprogramowania chcemy używać: model procesowy.
Tak zwane niedopasowanie oporu
Tak jest nazywana w literaturze różnica pomiędzy paradygmatem procesowym a obiektowym. Paradygmat procesowy operuje takimi pojęciami jak: proces, wejście procesu, wyjście procesu, zdarzenie, wykonawca procesu (zasoby), czynność (lub ich sekwencja). Paradygmat obiektowy to wspomniane obiekty czyli struktury łączące dane i metody ich przetwarzania. W czym problem? W przejściu z modelu procesowego na obiektowy. Czy to łatwe? Nie. Jak to zrobić? Hm… usiąść i popracować nad tym.
Należy przeprowadzić analizę obiektową i wykonać model obiektowy. Czego? Kodu? Nie! Organizacji zamawiającego!
W latach 60-tych (tak!) powstały metody obiektowe analizy i projektowania jako pomysł na modelowanie „świata” tak jak jest postrzegany: w postaci obiektów mających jakąś wiedzę i jakieś umiejętności. To analiza obiektowa (sama w sobie nie ma ona nic wspólnego z programowaniem!).
Skoro wiele problemów programistycznych dotyczy świata rzeczywistego, powstał pomysł stworzenia języka (ów) programowania „pasującego” do produktu analizy obiektowej: modelu obiektowego: powstał obiektowy język programowania Small Talk.
Dzisiaj mamy sytuację, w której programiści używają obiektowych narzędzi programistycznych i niestety postrzegają je tylko jako nowe metody łączenia funkcji i danych.
A teraz to wszystko narysuję
Zebrałem wszystko powyższej i mamy:
U góry firma (organizacja klienta), by zrozumieć ją, prowadzimy analizę procesową. To analiza ukierunkowana na zarządzanie czyli kto, co i po robi. Jak odkryjemy, że coś warto usprawnić, robimy to.
Wiedząc, że metody obiektowe są skuteczniejsze w projektach biznesowych inżynierii oprogramowania (no coś należy uznać), opracowujemy (przechodzimy na) model obiektowy tej organizacji.
Innymi słowy, model procesów służy nam do zrozumienia tego jak działa organizacja, bo wartość dodana powstaje jako produkt procesu (biznesowego). Opracowanie narzędzia, jakim jest oprogramowanie, wymaga opracowania określonej konstrukcji systemu, a ten jako taki jest obiektowy.
Jeżeli model procesowy organizacji pokazuje jak się ona zachowuje, to model obiektowy pokazuje czym ona jest.
W procesie analizy obiektowej powstaje model obiektowy badanej organizacji. Tu ma miejsce transformacja paradygmatu procesowego na obiektowy. To najtrudniejsza część całego projektu, tu powstaje największe ryzyko, zła analiza obiektowa skutkuje jeszcze gorszym oprogramowaniem. Z reguły model obiektowy jest tworzony nie dla całej organizacji a dla jej części (oprogramowanie to jedynie narzędzie wspierające ludzi a nie cała firma).
Mając obiektowy model wybranego obszaru organizacji i cel projektu (koniecznie) tworzymy projekt przyszłego oprogramowania. Tu mała uwaga: oprogramowanie to dwa aspekty: jego funkcjonalność oraz techniczne parametry takie jak bezpieczeństwo, wydajność i dostępność. Funkcjonalność wynika wprost z produktu analizy obiektowej, parametry techniczne to poza biznesowe elementy, których projektantami są inżynierowie i programiści.
Mając projekt, siadamy w końcu i kodujemy. Powstało oprogramowanie, które wspiera w ustalonym obszarze organizację zamawiającego: oprogramowanie to narzędzie. Na każdym etapie powyższego procesu powinno się dokonać oceny jakości produktu. Należy sprawdzić (upewnić się), że modele są prawdziwe, i że ich implementacja doprowadzi do powstania oczekiwanego oprogramowania. Jak? Testując je. Jak? Opisałem to już 🙂 w poprzednich artykułach.
Diagram powyższy wyróżnia dwa obszary: żółty, który wskazuje na kompetencje Analityka Biznesowego oraz fioletowy, wskazujący na obszar kompetencyjny Dewelopera (wykonawcy, dostawcy oprogramowania).
Opracowanie modelu biznesowego (procesowy i obiektowy) wymaga bardzo dużej wiedzy z zakresu zarządzania i marketingu. Wykonanie implementacji wymaga oczywiście dużej wiedzy i doświadczenia w zakresie inżynierii oprogramowania. Są to niestety dwa zupełnie odrębne obszary wiedzy i połączenie ich w jednej osobie jest niezwykle rzadkie. Ale nawet jeśli znajdziemy taka osobę, etapy te powinny zostać rozdzielone z innego powodu: wykonawca w biznesie nie powinien sam sobie stawiać wymagań! Rodzi to ogromne ryzyko nadużyć. (więcej o podziale na role w projekcie)
Komunikacja: powszechnie uznaną metodą komunikacji w takich projektach jest właśnie tworzenie modeli, sformalizowanych diagramów obrazujących produkty poszczególnych etapów analiz i projektowania. O notacjach (standardach tworzenia diagramów) w innych postach (są to głownie BPMN i UML). Warto tu tylko przytoczyć stare porzekadło: rysunek wart tysiąca słów. Kod jest zaś na samym końcu ostatecznym produktem.
Agile
Najpierw przytoczę tak zwany Manifest Agile:
Manifest Zwinnego Tworzenia Oprogramowania
Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywamy lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkładamy:
Ludzie i interakcje ponad procesy i narzędzia.
Działające oprogramowanie ponad obszerną dokumentację.
Współpraca z klientem ponad formalne ustalenia.
Reagowanie na zmiany ponad podążanie za planem.
Doceniamy to, co wymieniono po prawej stronie,
jednak bardziej cenimy to, co po lewej.
Cóż, zastąpienie procesu analizy i projektowania werbalną komunikacją to droga na skróty: czerwona strzałka. Czy to zła droga? Droga na skróty to wspomniane na początku ryzyko, ogromne bo statystyki wskazują stale, że ok. 70 – 80% projektów programistycznych ma poważne kłopoty. Statystyki te są takie same od lat. Dlaczego? Skoro od razu kodujemy to pominęliśmy pośrednie sprawdzenia i weryfikacje.
Od lat znany jest powyższy proces i mimo to zawsze jest te 80% klientów i ich dostawców, którzy dogadują się, że analiza i projektowania żadnemu z nich nie służy… tak jak to napisano na początku.
Po co to napisałem? By każdy z Państwa sam, świadomie, oceniał ryzyko swoich projektów. Rezygnacja z analizy i projektowania to podjęcie pewnego ryzyka. Niestety rezygnacja z analizy i projektowania ze strony dewelopera to czasem dodatkowo skutek przyznania, że analiza i projektowanie leży poza kompetencjami programistów (Ci obiektowo kodują) wiec wybierana jest droga na skróty.
A Agile? Mam dziwne wrażenie, że to z jednej strony łapanie brzytwy przez tonącego, ratunek, głos programistów pozbawionych analityka i projektanta, a z drugiej metodyka pozbycia się roli nie pasującej od „paradygmatu” programisty, który „bada i rozwija się poprzez stałe ćwiczenie się w swoim fachu”, szkoda, że nie raz na cudzej skórze.
Pominięcie jednak analizy i projektowania prowadzi do programów gdzie paradygmat obiektowy, kończy się na tym, że owe „struktury łączące dane i operacje na nich” powstają jako sztuczne byty, nie mające nic wspólnego z rzeczywistością, a co najwyżej z wygodą kodującego programisty. Tak właśnie powstają bardzo często bardzo złe programy: nierozwojowe, nieżyciowe, nienaturalne w pracy.
I nie chodzi o to by koniecznie zatrudniać analityka, chodzi o to by rzetelnie wykonać analizę i projekt zanim rozpoczniemy kodowanie.
„Szkoda, że nie raz na cudzej skórze”… hm,… A na czyjej skórze chciałbyś się uczyć? Na swojej? Gdyby tak podejść do sprawy to wszyscy pracowaliby w jednoosobowych projektach open-source, które nikomu nie służą a jak wiadomo tak nie jest. Poza tym dochodzi do tego wszystkiego wstrętna i pokrętna polityka, która niejednokrotnie rozwala cały proces nieważne czy agile czy waterfall czy cos innego jeszcze pomiędzy.
Ja się uczę na swojej skórze i na swój koszt bo to, uczciwe. Ok. 50% mojego czasu w miesiącu poświęcam, poza papierami firmowymi, na „projektowanie na sucho” i pisanie doktoratu. Znam wielu programistów, którzy robią podobnie, zresztą projekty open-source właśnie taki mają cel: uczyć się bez szkód dla innych: uczciwie. Współpracuje z programistami, którym było by wstyd obiecać klientowi coś czego jeszcze nie robili. Co do polityki w tej czy inne firmie to jest stare korporacyjne powiedzenie: „nie akceptujesz i wychodzisz albo akceptujesz i zostajesz”.
Po przeczytaniu tego wpisu zastanawiam się, czy nie powinno się jakoś karać rozprzestrzeniania FUDu…
To co piszesz jest grubo nieprawdziwe, albo bazuje na niezrozumieniu paru spraw. Po kolei:
1) Zdajesz się nie rozumieć obiektowości i związanego z nią procesu programistycznego. Nie winię Cię – zdaje się, że po prostu się tym na codzień nie zajmujesz, dziwię się tylko, że poruszasz ten temat. Co więcej Twoje tłumaczenia są delikatnie manipulacyjne (np. „Anaysis is done before…” nie oznacza „Analiza powinna być wykonana…”) Co więcej wzięcie pierwszego akapitu z wikipedii wyrywa tekst z kontekstu. Np. nie wziąłeś już pod uwagę następującego (kluczowego dla zwinnych metodyk) zdania (z artykułu o projektowaniu): „Both analysis and design can be performed incrementally, and the artifacts can be continuously grown instead of completely developed in one shot.” Hm – to zdanie zaprzecza Twojemu diagramowi…
Dobrze, że nawiązałeś do DDD, bo to podejście bardzo silnie zaprzecza fazowemu podejściu do tworzenia oprogramowania. Z resztą Eric Evans (autor DDD) pochodzi bezpośrednio ze zwinnych środowisk (konkretnie XP). Zachęcam do przeczytania jego książki, a zobaczysz jak wymagania i model koncepcyjny wyłaniają się W TRAKCIE programowania.
2. Nawiązanie do zwinnych metodyk wskazuje niestety na pewne niedoczytanie źródeł. Nigdzie nie jest napisane, że 80% projektów się nie udaje ze względu na brak analizy (albo ja nie znam takich opracowań). Jest za to napisane, że zwinne metodyki zmniejszają ryzyko (http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS)
3. Teraz konkrety dot. agile.
3a. W zwinnych metodykach nie jest tak, że nie ma analizy. Jest i to zwykle dużo dokładniejsza niż w klasycznym fazowym podejściu, bo dzieje się CIĄGLE, przez cały czas trwania projektu. I oczywiście, że jest ona w większości przed programowaniem danej funkcjonalności (spotkanie planningowe, spotkanie backlog grooming, a nawet ad-hoc rozmowy przy kawie przenoszące się na whiteboard), a tylko w części w trakcie programowania (dopytujemy w trakcie programowania – wykrywamy dodatkowe przypadki, po pokazaniu klientowi odpowiedniego kawałka UI, itp).
3b. W zwinnych metodykach nie jest tak, że nie ma projektowania. Jest i to zwykle dużo dokładniejsze niż w klasycznym fazowym podejściu, bo dzieje się CIĄGLE, przez cały czas trwania projektu. Każda nowa funkcjonalność jest opracowywana zaraz przed rozpoczęciem programowania pod względem jej umieszczenia w systemie (architektura) oraz jej wewn. projektu (design). Oczywiście szczegóły w rodzaju wzorców projektowych powstają/wyłaniają się w trakcie developmentu, ale dla trudniejszych przypadków duża część pracy odbywa się na papierze i whiteboardzie. Tak więc projektujemy zarówno przed developmentem jak i w trakcie. Tyle, że znów: iteracyjnie/inkrementalnie i per-feature.
4. Stawianie pozycji analityka jako przeciwieństwo agile jest nie fair. Analityk może (a nawet musi) mieć swoje miejsce w zwinnie prowadzonym projekcie (i nazywa się np. product owner albo customer w zależności od metodyki), tyle że lepiej żeby nie był analitykiem z zawodu, tylko ekspertem danego biznesu. Dlatego w naszych projektach analitykiem jest np. specjalista od roamingu czy logistyk. I pracuje iteracyjnie dostarczając i pogłębiając nam wymagania. I nie nazywamy go analityk, ale to pewnie tylko kwestia nazewnictwa.
Podsumowując w zwinnych metodykach nie chodzi o to, żeby „rzetelnie wykonać analizę i projekt zanim rozpoczniemy kodowanie” tylko maksymalizować prawdopodobieństwo sukcesu przez zbliżenie i maksymalizację efektywnej komunikacji między biznesem, architekturą i developmentem, by maksymalizować przynoszoną wartość.
Polecam artykuł, który jakiś czas temu napisałem:
pozdrawiam
Paweł
Na początek zaznaczę, że każdy ma prawo do swojego zdania, i Ty i ja.
Ad.1. Obiektowość to nie tylko obiektowy kompilator ale także analiza i modelowanie, pragnę przypomnieć, że języki programowania obiektowe powstały w odpowiedzi na obiektowy paradygmat analizy i projektowania a nie odwrotnie, są implementacją obiektowości.
Analiza i projektowanie (owe wspomniane „analysis and design”) obiektowe nie mają nic wspólnego z pisaniem kodu i faktycznie jest iteracyjne, kod ten jest wtórny do projektu: to implementacja wyników projektowania obiektowego.
DDD to styl projektowania a nie programowania, to drugie to jest implementacja projektu (powtarzam się). (DDD Evansa jest na mojej półce, nie ma tam nic – nie znalazłem – o kodowaniu bez poprzedzającego go, iteracyjnego, projektowania).
2. W kwestii zastosowań zwinnych metodyk polecam http://it-consulting.pl/autoinstalator/wordpress/index.php/2011/03/22/co-wybrac-czyli-cykl-zycia-projektu-tworzenia-oprogramowania/, podsumowanie wielu źródeł o programowaniu i metodach.
ad.3. Nie piszę o tym, że w zwinnych metodykach nie ma analizy a o tym, że jest ona „rozpoznaniem bojem” a to właśnie krytykuję…
ad.4.Chodzi mi o to, że „rozpoznanie bojem” na papierze (analiza i modele) jest skuteczniejsze i tańsza niż od razu z pomocą zespołu koderów i kodowania. Fazowość postrzegam jako oddzielenie szukania rozwiązania od jego implementacji.
Dlaczego o tym w ogóle piszę? Bo porównanie ofert wygląda tak (jeden z wielu moich projektów):
Wariant 1.: Zwinne metodyki itp.: oferty na bazie opisu przyszłego użytkownika oscylują w granicach 450 – 700 tys.
wariant 2.: analiza i projektowanie, potem implementacja: oferty na bazie wcześniej projektu UML mają już wartość 170 – 200 tys., poprzedzający koszt analizy i projektu w tym projekcie, ok. 30 tys. Każdy potrafi liczyć. Projekt zamknięty, wykonany w terminie i w budżecie: implementacja kwartał, oddana w wersji pierwszej do użytku. łączny koszt to 200 tys. zamiast 450tys. (?700?). Tak to wygląda. To moje doświadczenia.
Dla mnie obiektywnym miernikiem są zakończone i rozliczone projekty oraz pierwotne oferty jako porównanie.
Może do zobaczenia na Confiturze 11 Czerwca :), nie ma co się emocjonować.
Jak mam rozumieć „zabronić” w sensie jakichkolwiek wypowiedzi? Cenzura niewygodnych tez? Polecam także to:
oraz to:
http://msdn.microsoft.com/en-us/library/dd409423(v=VS.100).aspx
To zacznę od tego, że z tym zakazywaniem to oczywiście żart. Natomiast uważam (po przeczytaniu paru Twoich wpisów tu i na GL), że porównujesz to co znasz (co ja nazywam teoriami i praktykami z lat 80 – 90tych) z tym o czym chyba tylko czytałeś (agile, DDD, itp). Przykłady? Np. we wpisie o metodykach piszesz, że Scrum jest ściśle programistyczny, co wyraźnie wskazuje, że mylisz go z XP. Scrum to framework niezależny (w założeniach) od typu projektu – czy to informatyczny, logistyczny, administracyjny, czy jakikolwiek inny.
Nie próbuję Ci odebrać zdania, tylko zachęcam do poznania w praktyce (najlepiej dobrej…) tego o czym piszesz.
A teraz komentarz do komentarza do komentarza:
Ad Ad 1. Obecne projektowanie/programowanie obiektowe wcale nie ma wiele wspólnego z analizą obiektową. Szczególnie w projektach biznesowych, gdzie 90% kodu to infrastruktura, ujarzmienie technologii i GUI a nie logika biznesowa. Co więcej narzędzia do analizy obiektowej (use case’y, przepływy, sekwencje itp) rzadko dobrze się mapują na programowanie obiektowe, za to świetnie na proceduralne, stąd trudno o dobrze obiektowy kod w takich projektach (no dobra – nie koniecznie taki jest główny powód, ale to jeden z nich).
A co do DDD, to na raz i masz rację i nie. Masz na płaszczyźnie lingwistycznej – w końcu Design to nie programowanie. Nie masz za to w warstwie znaczeniowej, bo pewnie nie wiesz, że Evans był związany z XP bardzo mocno i dla niego projektowanie i programowanie (jak dla wszystkich XPowców) to nierozdzielne aktywności. Dlatego w książce pisze o tym, że ma ze sobą eksperta, z którym gadając pisze kod. Pisze go najchętniej w DSLu, żeby ekspert zrozumiał i mógł ew. zgłosić poprawki. Tak więc na raz projektuje (zgłębiając swój model koncepcyjny i domenę) i programuje, bo powstaje z tego „rich domain model” używany potem w aplikacji. Powstaje/prezycuje się też ubiquitous language, co jest już zupełnie analityczną rzeczą.
Ad Ad 2. Przejrzałem wpis i faktycznie ciekawy, choć nie bez uwag 😉 Model wodospadowy w takiej formie jak go narysowałeś nie istnieje i nie istniał nigdy (Winston Royce miał na myśli coś innego, co fajnie pokazane jest tu: http://www.youtube.com/watch?v=X1c2 – sP3o0). Scrum to (jak już pisałem) niezależna od kodowania metodyka (a nie metodologia, która po Polsku jest nauką o metodykach), w której często stosuje się praktyki XP. Dlatego nazywana jest czasem XP nie tylko dla orłów. Do tego zwinne metodyki stosuje się nie tylko w małych projektach i to ze znaczym sukcesem. Np. w mojej firmie nasz główny projekt trwa już ponad 2 lata, a mamy zagwarantowane jeszcze do końca roku. Zespół jest paronastoosobowy. W samej javie jest teraz coś pod 200k linii kodu. I uwierz mi, to co wyanalizowali na początku ma się nijak do tego, czego chcą teraz. Bo nie tylko zmieniły się ich oczekiwania, ich klientów, technologie, to jeszcze wiele rzeczy okazało się dopiero jak dało się w nie kliknąć.
Ale zgadzam się w 100% z tym, że XP (i w ogóle agile) wymaga b. dużej odpowiedzialności i świadomości zespołu. Stąd rola coach’a/scrum mastera, który ma dbać o proces i zespół.
Rozróżnienie podejścia z prototypami, prototypami odrzucanymi od innych metodyk jest wg mnie błędem, bo to ortogonalna do metodyki technika. Stosuje się je i w wodospadach i w agile’u. Z resztą w agile’u bardzo często (bo idealnie wpasowuje się w iteracyjność i częsty kontakt z klientem), więc wpisywanie dla nich innych wartości w tabelce porównawczej jest błędem. Tak – wg mnie oczywiście 😉
Ad Ad 3. No właśnie problem jest taki, że nie bardzo się da rozpoznać bez boju. Tzn czasem się da więcej, czasem mniej, ale nigdy 100%. Zawsze coś rozpoznasz dopiero w boju – i to w cale nie tak mało. Dlatego nie jestem za atakowaniem z kodem dziedziny od pierwszego dnia, za to spędzanie 25% czasu projektu na analizie też nie jest wg mnie dobrym rozwiązaniem. Komentarz do bloga to za krótka forma, żeby pisać dlaczego (głównie psychologia się tu kłania – drogi na skróty, zmiana wymagań, liczba ogniw w łańcuchu komunikacji, itp).
Ad Ad 4. Każdy programista Ci powie, że modele przygotowane w UMLu można w większości o kant D rozbić. Do tego ich tworzenie jest niesamowicie kosztowne, a utrzymanie aktualnych jeszcze bardziej. Zwiększają więc one tylko koszty wcale nie zmniejszając ryzyka. Pracowałem jako architekt przez parę lat, przy naprawdę dużych systemach i uwierz – kod ma się nijak do tego co architekci / designerzy UMLowi produkują. Z resztą nie może być inaczej – żaden mniej złożony system nie może kontrolować bardziej złożonego. A architektura czy analiza jest z natury rzeczy mniej złożona od programowania. Operuje w końcu na abstrakcjach, uogólnieniach i założeniach a nie na faktach.
Ale i tak zgodnie z Twoimi przemyśleniami uważam, że wielu problemów programistycznych można by uniknąć gdyby były lepiej przemyślane przed zgłoszeniem zespołowi (a więc zanalizowane). Dlatego nie uciekam od analizy – nawet szczegółowej – ale wybiórczej, tzn. realizowanej w odpowiednich szczegółach tam gdzie ma to zastosowanie.
Porównanie ofert o którym piszesz nie dowodzi NICZEGO W OGÓLE. Kwoty w ofertach zwykle wystawia się na podstawie zgrubnych, niepełnych, często sprzecznych wymagań, w oparciu o czynniki ryzyka, grube oszacowania i ssanie z palca. Do tego dochodzi polityka i kolesiostwo. W Twoim przypadku goście agile’owi pewnie nie chcieli ryzykować, więc walnęli „z góry” – z resztą chętnie bym się dowiedział jak liczyli. Goście od UML’a (a Ci agile’owcy nie mieli tego UML’a?) za to pewnie chcieli po prostu zrobić projekt, licząc, że jeśli coś się pojawi ryzykownego to się chwyci klienta na CRy. A może nie – a może po prostu oni do tego usiedli i policzyli, a agile’owcy wyssali z palca licząc na brak konkurencji? Kto wie…
Tak czy siak, mogę Ci powiedzieć, że my liczymy na podst. zapytania ofertowego tak:
1. robimy z wymagań coś a’la user story
2. porównujemy do aktualnie robionego projektu (rozmiary story)
3. szacujemy względem aktualnego
4. przeliczamy względem aktualnego (prędkości zespołu)
Więc staramy się nie wysysać z palca, tylko bazować na statystykach. Do tego nigdy nie robi tego 1na osoba, tylko zawsze przynajmniej 2 – 3, żeby dyskutowały w trakcie wyceniania.
Do confitury!
„Obecne projektowanie/programowanie obiektowe wcale nie ma wiele wspólnego z analizą obiektową. Szczególnie w projektach biznesowych, gdzie 90% kodu to infrastruktura, ujarzmienie technologii i GUI a nie logika biznesowa”
Zgadzam się, że 90% to infrastruktura i nie raz to potwierdzałem, jednak w 100% tam gdzie byłem świadkiem kłopotów z odbiorem oprogramowania problem nie tkwił w infrastrukturze a w regułach biznesowych, to że wg. Ciebie są one nie ważne potwierdza tylko ten problem… Otóż to co system ma robić dla użytkownika to w 100% analiza i projektowanie, tu obiektowe.
Jeżeli uważasz, że „problem jest taki, że nie bardzo się da rozpoznać bez boju.” to Twoje zdanie i masz prawo je mieć. Po raz kolejny przytoczę: „to że nie widziałeś nigdy czarnego łabędzie nie stanowi żanego dowodu na jego nieistnienie”.
„Każdy programista Ci powie, że modele przygotowane w UMLu można w większości o kant D rozbić.”, uścislijmy: nie każdy i być może te które widziałes lub te których nie potrafiłeś przeczytać, nie wiem, pokaż takie przykłady to będę miał swoje zdanie… jak na razie ci programiści z którymi ja wspólpracuję w 100% korzystają z modeli UML i to dzięki ich umiejętnościom miewam proporcje 200 tys. vs. 700tys. u konkurentów.
„do tego ich tworzenie jest niesamowicie kosztowne”, wybacz ale to już jest bełkot…ja też takie tworze je wiem ile kosztują.
„kod ma się nijak do tego co architekci / designerzy UMLowi produkują”, współczuje kompetencja zespołu, kluczową miara zespołu analityków i projektantów jest to jak się ma produkt końcowy do projektu. Jeżeli nijak się nie ma to…
„porównanie ofert o którym piszesz nie dowodzi NICZEGO W OGÓLE.”, dowodzi prostej rzeczy: istotnie się różnią.
„my liczymy na podst. zapytania ofertowego”, które jest czym? Projektem? Opisem? Życzeniem? Jeżeli ktoś potrafi złożyć ofertę nie wiedząc co ma zrobić (a co najwyżej, do czego to posłuży) to ja podziwiam, w szczególności narzut na tę niewiedzę.
Do konfitury… mamy na prawdę bardzo odmienne doświadczenia i jak to mówią, rynek to oceni nie my, kończę ten spór…
Najpierw się przyczepię:
„Mając obiektowy model organizacji i cel projektu (koniecznie) tworzymy projekt przyszłego oprogramowania. Tu mała uwaga: oprogramowanie to dwa aspekty: jego funkcjonalność oraz techniczne parametry takie jak bezpieczeństwo, wydajność i dostępność. Funkcjonalność wynika wprost z produktu analizy obiektowej, parametry techniczne to poza biznesowe elementy, których projektantami są inżynierowie i programiści.”
1) techniczne parametry takie jak(…) – to są pozafunkcjonalne wymagania zwane także ograniczeniami a nie żadne techniczne aspekty, wymaganie na maksymalny czas odpowiedzi, poziomy pewności algorytmów decyzyjnych, czy ilość przetwarzanych danych, albo informacje o planowanym obciążeniu – to też wymagania pozafunkcjonalne i nie mają żadnych technicznych aspektów:P
2) te wymagania (pozafunkcjonalne) wcale nie wynikają z pracy inżynierów i programistów, one jak najbardziej wynikają z analizy biznesowej; to biznes musi wyznaczyć pewne granice w ramach których oprogramowanie ma być realizowane – wymagania na wydajność, pojemność, etc. wynikają wprost z analizy biznesowej przykład wymagania biznesu „system ma być bezpieczny”-bzdura (co to znaczy bezpieczny?) „system ma korzystać z protokołu SSL”-mniejsza bzdura(jakiego? i czemu właśnie tego?) „system ma przesyłąć dane szyfrowanym łączem, uniemożliwiającym podsłuchanie i odszyfrowanie przesyłanych komunikatów w czasie <1 dnia przez komputer osobisty”-dobre wymaganie, które projektant zamieni na – kożystamy z takich to a takich sposobów szyfrowania łącza, takich to a takich funkcji hashujących hasła, stosujemy min. 1024 bitowe klucze etc.
A co do Waszej dyskusji:
1) Jarku, daj sobie spokój z tym notorycznym jeżdżeniu po Agile jako idei. Już tak wiele razy przyznałeś mi rację, gdy tłumaczyłem, że to dobre narzędzie w obszarze jego użytkowania, a dobre praktyki Agile wcale nie pomijają analizy i projektowania. Nie spłodzę tak zgrabnego tekstu (a przynajmniej nie sam) na ten temat, ale naprawdę Twoja antypatia wynika z efektu krzywego zwierciadła.
Czytasz o Agile i obserwujesz projekty, mieniące się Agile – choć tak naprawdę z dobrymi praktykami nie mają one nic wspólnego. Ludzie programują na pałę i im się wydaje, że jak szacowali grając w poker’a to są Agile. Nie są, choć tak mówią – to nie jest Agile. Potępiaj kiepskie wykonanie, a nie naprawdę solidne narzędzie projektowe:P Jak mnie sprowokujesz to w końcu zrobimy razem projekt Agile, żeby Ci udowodnić, że to wielkie dobro, jak się umie tego używać.
Wydaje mi się, że wiele nieporozumień, w takich ja ta wymiana poglądów, jest wynikiem swobody używania pojęć „ogólnie postrzeganych jako znane”. Prawdę mówiąc, nie mam nic przeciwko jakimkolwiek programistom, jednak trudno mi zaakceptować pewne praktyki. Wydaje mi się, że wystarczy np. zrezygnować ze słowa Agile a zacząć pisać o konkretnym przypadku i konkretnej pracy a problem zniknie. Ja kilka lat temu używałem pojęcia „zwinna analiza i projektowanie” na zmianę z Agile Analysis, mając na myśli po prostu adaptacyjny sposób dobierania zakresu projektu i sposobu jego prowadzenia. Po kilku „zarzutach”, teraz uważam słusznych, zrezygnowałem. Dlaczego? Bo to co robiłem nie miało nic wspólnego z owym manifestem agile. Osobiście, jako zwolennik podnoszenia jakości komunikacji – precyzowania używanych pojęć – uważam, że jak długo słowo Agile ma tyle definicji ilu jest ludzi go używających, tak długo jego używanie będzie się wiązało z takimi nieporozumieniami. Tak więc nie jeżdżę po Agile a po tym, że to słowo nic nie znaczy (poza tłumaczeniem: zwinność).
Ad.1. Widzisz tu mamy kolejne nieporozumienie ;). Krąży wiele definicji pojęć „wymagania funkcjonalne i poza funkcjonalne”, nie raz pojawiają się także inne. Dla mnie aspektem technicznym jest to, że „spodziewamy się 2 milionów dokumentów w repozytorium”, bo z tym musi sobie poradzić dostawca „technologii”, także z algorytmami wyszukiwania. Wymaganiem funkcjonalnym będzie to, jakie metadane będą opisywały te dokumenty, poza funkcjonalnym to, że czas wyszukiwania dokumentu nie powinien przekroczyć 5 minut. Tym ostatnim zajmą się już (tak sądzę) inżynierowie a nie analityk (lub stwierdzą, że nie da sie tego osiągnąć).
Ad.2. Masz rację, wymagania poza-funckjonalne musi ktoś określić, biznes czy analityk biznesowy. Twój przykład z SSL jest bardzo dobry, ja także uważam, że „poziom bezpieczeństwa” to wymaganie (ograniczenie) a ów SSL to implementacja. Pierwsze pisze analityk drugie „wymyśla” inżynier odpowiedzialny na projekt implementacji. Jak widać, bałagan pojęciowy jest i mamy nieporozumienia. Co do stwierdzenia „system ma być bezpieczny” ono samo z siebie jest niemierzalne, racja. Wypadało by napisać „jak bardzo bezpieczny” i określić miarę. Jednak miejmy świadomość, że np. ustawodawca posłużył się pojęciem „bezpieczny podpis elektroniczny”. Co to znaczy? Nic, chyba że uznamy, że „bezpieczny podpis elektroniczny” to taki, przy którym zastosowano konkretną, opisaną w innych dokumentach ustawodawcy technologię. Tak więc czasami „wypada” posłużyć się „ogólnie przyjęta wiedzą” a dla precyzji wpisać ów SSL jako „przykład pojmowania” tego poziomu bezpieczeństwa.
Dlatego ja, by uniknąć nieporozumień, nie używam słów „Agile”, „zwinne metody” itp. Po protu należy napisać co i jak się robi (zrobi). Niestety wielu dostawców „systemów” nie potrafi (nie chce?) z góry napisać co i jak zrobią i z tym „walczę” a nie z dobrymi praktykami, które nie raz sam stosuję. Ilu programistów (firm) tworzy dokument „hermetyzacja”, który Ty stosujesz? Ilu programistów (firm) potrafi z góry zadeklarować do dostarczą? Moje „ataki” dotyczą bałaganu pojęciowego w ofertach i protokołach przekazania. Zbyt wiele programów, za które wystawiono fakturę a które do niczego nie służyły, widziałem. To nie ja wymyśliłem, że firma programistyczna ma mieć dobrego prawnika a nie dobrego programistę. Mam także świadomość, że wiele firm programistycznych (nie wszystkie) atakuje mnie (i nie tylko mnie) bo przy zbyt dobrze (co by to nie miało znaczyć) określonych wymaganiach, ich projekty są możliwe do rozliczenia a tego wielu z nich nie lubi.
Na koniec: jak ktoś pisze, że planowanie i projektowanie należy wytępić, będzie moim „wrogiem”. Czym jest opracowanie wymagań i zaprojektowanie logiki systemu jak nie planowaniem i projektowaniem? Przytaczanie przykładów wyjątkowo złej jakości dokumentów analityków (a prawda jest, że produkują takie nawet zacne giełdowe spółki informatyczne!), to nie argument by z analiz (analityków) zrezygnować a argument za tym by pilnować lepiej ich jakości. Idąc tym tropem, po tym co nie raz widziałem, powinienem głosić tezę by zarzucić w ogóle informatykę i zwolnić wszystkich programistów – to nie ja wymyśliłem pojęcie „kryzys oprogramowania”… ale to głupie więc tak nie powiem.
1. Bądźmy precyzyjni w manifeście Agile nie przypadkowo użyto słowa ponad (eng. over) a nie zamiast (eng. instead).
2. Manifest agile jest napisany z punktu widzenia dostawcy oprogramowania
Jako programista/projektant ceniam to tak że pisanie na podstawie kiepskiego projektu jest nieprzyjemne , różnica tylko taka że jeśli projekt jest własny zaczyna przeszkadzać dopiero po pewnym czasie .
Witam
1. czyli ograniczenie czasu (a podobno zawsze go za mało w projektach) zaowocuje rezygnacją z projektowania/dokumentowania, moim zdaniem uczciwsze jest powiedzenie klientowi, że na coś jest po protu za mało czasu…
2. zgadzam się w 100%, ale czy to usprawiedliwia dostawcę?
Prawdą jest, że pisanie czegokolwiek na bazie kiepskiego projektu jest frustrujące, dlatego nie raz słyszę narzekania (słuszne) także na analityków-projektantów…;)
Dzisiaj jest 7 luty 2019, nic się nie zmieniło… kilka drobnych poprawek w artykule… „Pan Lipiński” (patrz powyższa dyskusja) nadal dominuje u developerów.…