Temat: A ja się dziwię programistom, przepraszam Was...

Etap 1: Analiza
...
Etap 2: Projekt GUI
Zadaniem projektant GUI jest stworzenie widoków(przepływów) do realizacji funkcjonalności biznesowej. Dokumentacja od analityka dostarcza mu wszystkich potrzebnych informacji czyli listę przypadków użycia (publiczne metody z klas) i parametry jakie użytkownik musi podać żeby je wywołać.
Efektem jego pracy jest dokument zawierający listę widoków (klasy formsów / paneli / dedykowanych kontrolek) 'podpiętych' do modelu biznesowego wraz z zdefiniowanymi przepływami.
Całość oczywiście w jakimś formalnym języku do opisu GUI :)

Na podstawie ww. dokumentu można generować warstwę View + Controler aplikacji.

Miara jakości:
- ergonomia GUI (opinia Pani Jadzi ;)
- brak błędów GUI podczas wywoływania na nich testów jednostkowych modelu.

Jak dla mnie, to tu jest podstawowy błąd :) Dlaczego GUI powstaje przed architekturą i implementacją funkcjonalności czysto biznesowych?
Czy mamy spędzić 2 miesiące na przesuwaniu loga, a potem w 2 tygodnie wydziergać całą aplikację ?

Racja. Etapy 3 i 4 mogą rozpocząć się przed zakończeniem etapu 2.
Ale tylko pod warunkiem, że analiza jest kompletna i ...najprawdopodobniej ... nie ulegnie zmianie.
Jeśli tak nie jest - projektowanie GUI jest rodzajem 'tworzenia prototypu' systemu.

... Jak już pisałem - przykład wymyśliłem 'na poczekaniu' ;)

Wedle mnie to architektura i logika determinuje GUI, a nie odwrotnie.

Według mnie to wygląda tak: Model biznesowy (UC etc..) -> GUI -> architektura / kod / implementacja.

GUI jest tylko interfejsem użytkownika do modelu biznesowego. W związku z tym, powinien zależeć tylko od 'nich'.

Ponadto Pani Jadzia powinna być decyzyjna w swoim zakresie[...]
Są też obiektywne metryki ergonomii, wynikające ze statystycznego rozkładu elementów różnych aplikacji.

Oczywiście. Istnieją metryki ergonomii, usability i inne tego typu cuda i to one powinny być, generalnie, wyznacznikiem wyglądu / zachowania GUI.

Niestety czasem tej opinii nie podziela Pani Jadzia ;)
"Klient nasz pannn..."; jeśli klient jest uparty i chce źle, to tylko lepiej dla wykonawcy - zarobi na późniejszych poprawkach ;)

Inną sprawą jest to, czy jest to skuteczny 'model procesu'...

To co tu opisujesz jest typowym podejściem wodospadowym.

Jeśli chodzi dokładnie o metodykę 'wodospadu' to muszę się nie zgodzić - metoda wodospadu to tylko nazwy etapów realizacji na którą 'wszyscy' krzyczą, że 'nie działa' ...

Ja mimo wszystko coś o 'swoich' etapach napisałem (produkty wejściowe, produkty wyjściowe, miary jakości (rodzaj testów) produktów każdego z etapów ;), .. ,
'moja metodyka' nie jest sekwencyjna :) A .. określiłem podział ról (odpowiedzialności) w zespole...

Nie jest to ani wydajne, ani produktywne.

A która metodyka aktualnie jest ? :D
Sekwencja "plan -> wykonanie -> test" jest stara jak świat i działa od początków istnienia inżynierii jako takiej; jej wydajność zależy od tego, jak się te etapy organizuje.

... Niektórzy pewnie myślą, że nie trzeba umieć sensownie zaprojektować procesu projekt->wykonanie->test, żeby móc sensownie zaprojektować proces
taki

Poza tym moim zdaniem kolejność
jest do zmiany :)

Z chęcią zapoznam się z poprawioną :)Jakub Wojt edytował(a) ten post dnia 17.08.11 o godzinie 13:25

Temat: A ja się dziwię programistom, przepraszam Was...

Jakub Wojt:
...
Ale tylko pod warunkiem, że analiza jest kompletna i ...najprawdopodobniej ... nie ulegnie zmianie.
Jeśli tak nie jest - projektowanie GUI jest rodzajem 'tworzenia prototypu' systemu.

... Jak już pisałem - przykład wymyśliłem 'na poczekaniu' ;)

Wedle mnie to architektura i logika determinuje GUI, a nie odwrotnie.

Według mnie to wygląda tak: Model biznesowy (UC etc..) -> GUI -> architektura / kod / implementacja.

GUI jest tylko interfejsem użytkownika do modelu biznesowego. W związku z tym, powinien zależeć tylko od 'nich'.

Ponadto Pani Jadzia powinna być decyzyjna w swoim zakresie[...]
Są też obiektywne metryki ergonomii, wynikające ze statystycznego rozkładu elementów różnych aplikacji.

Oczywiście. Istnieją metryki ergonomii, usability i inne tego typu cuda i to one powinny być, generalnie, wyznacznikiem wyglądu / zachowania GUI.

Niestety czasem tej opinii nie podziela Pani Jadzia ;)
"Klient nasz pannn..."; jeśli klient jest uparty i chce źle, to tylko lepiej dla wykonawcy - zarobi na późniejszych poprawkach ;)
...
Z chęcią zapoznam się z poprawioną :)

W moim przekonaniu, mówimy teraz o dwóch odmiennych, konkurujących ze sobą podejściach: wytworzenie systemu poprzez mokupy vs. modele w skali.

W pierwszym podejściu próbujemy jak najszybciej stworzyć pełnowymiarowy model systemu. Przełożę to przewrotnie do motoryzacji: stworzymy najpierw karoserię samochodu. Pani Jadzia będzie przecież patrzeć na ten samochód, wystawi go na podwórku ku uciesze własnego oka i by sąsiedzie zzielenieli z zazdrości. Pogadamy o kolorze, o wyposażeniu i o rozmiarach samochodu. Przecież chciałaby wstawić czasem samochód do garażu, a tak na marginesie, to przecież nie od dziś wiadomo, że czerwone auta jeżdżą szybciej. Co nam zostaje na koniec? Musimy wcisnąć w Ferrari o rozmiarze mini jakiś silnik i skrzynię. Trzeba gdzieś wcisnąć przewody elektryczne różnego rodzaju rurki. A bym zapomniał, wydech i tłumiki. Kurcze, jeszcze turbinę (bo silnik mały) i intercooler. Zaraz zaraz, świta mi problem Audi TT, to i spoler trzeba wstawić, ale ni może samochód wyglądać jak wiocha, to musi być hydrauliczny. Ale gdzie to wszystko wcisnąć? Może tak wydłużyć samochód o 50 cm, lub przynajmniej go poszerzyć o 25 cm? Pani Jadziu da radę? Nie? A, garaż na golfa jest? Może przerysowałem, ale spotykałem się z tym samym w SI.

W drugim podejściu zaczynamy od architektury. Jaki silnik, jaka skrzynia, jak często będziemy jeździć, gdzie będziemy jeździć itp. Jeśli przy okazji pani Jadzia powie, że chce mieć czerwony wóz --- nie ma problemu, jesteśmy bardziej tolerancyjni niż Henry Ford. Jak mamy już architekturę rozwiązań, możemy pogadać o pozostałych rzeczach. Ma być 50 cm krótszy? Możemy skrócić o 30 bez zmiany budowy podwozia? A może zamiast skracać wóz włóżmy w te same koszta czujniki parkowania, to samochód wjedzie na styk do tylnej ściany. Pani Jadzia nie zna się na budowie samochodów, inaczej sama by go zbudowała lub zaprojektowała. A może zna się na wszystkim i zrobiła by sama w czasie dwa razy krótszym i dwa razy taniej oraz dwa razy lepiej, tylko że nie ma czasu na to?

Jak to wszystko ma się do mokupów, modele w skali i SI? Podchodząc od GUI próbujemy zbudować od razu pełnowymiarowy model systemu. Podchodząc od architektury budujemy najpierw prototyp w skali. Rozmowa na początku o wyglądzie sprawia, że zapominamy co tak naprawdę chcemy, a skupiamy się na mało istotnych szczegółach. Jeśli Pani Jadzia nie ma zaufania do naszej fachowości i nie wierzy, że my jesteśmy ekspertami od interfejsu i zrobimy tak, aby było dobrze nie tylko dla niej, ale przede wszystkim dobrze dla wszystkich użytkowników SI to może mamy pierwszy symptom poważnych problemów przy odbiorze? Często skupiając się na szczegółach, zapomina się o ogóle. Wtedy piękny interfejs na 21” ekranie grafika ślicznie wszystko pakuje w jednym ekranie. Ale pracownicy (bo Pani Jadzia pewnie też ma 21” ekran) mają 17” lub 15” i pewne opcjonalne rzeczy są na drugim ekranie i połowa z nich nawet nie będzie świadoma, że jest coś więcej do wypełnienia. Dlatego Pani Jadzia powinna wysłowić co chce, zatwierdzić ogólną koncepcję i zdać się na wiedzę, doświadczenie i praktykę ekspertów w dziedzinie. Dlatego szczegółowy projekt GUI na początku jest złym rozwiązaniem.

Temat: A ja się dziwię programistom, przepraszam Was...

W moim przekonaniu, mówimy teraz o dwóch odmiennych, konkurujących ze sobą podejściach: wytworzenie systemu poprzez mokupy vs. modele w skali.

Nie zgodzę się.
Modele doświadczalne tworzy się, aby badać potencjalnie nieprzewidywalne zachowanie 'układu rzeczywistego' przed jego powstaniem.

Czego w programie nie można przewidzieć, jeśli model biznesowy jest spójny i kompletny (a jest bo w 'mojej metodyce' przeszedł formalne testy) ?
'Sprzęt' zachowuje się w sposób przewidywalny, domena (model) jest przewidywalna...

GUI w moim rozumieniu nie jest żadnym mockiem ani modelem doświadczalnym - jest po prostu prostu częścią rozwiązania (programu) odpowiedzialną za pośredniczenie między użytkownikiem a funkcjonalnością biznesową i tylko od tych dwóch elementów powinna zależeć jego forma.

Podchodząc od architektury budujemy najpierw prototyp w skali.

Logika biznesowa i GUI powinno zależeć od architektury ?
Moim zdaniem, powinno się dążyć do odwrotnej sytuacji.

Rozmowa na początku o wyglądzie sprawia, że zapominamy co tak naprawdę chcemy,

W 'mojej' metodyce, pierwszym etapem realizacji jest stworzenie formalnego opisu funkcjonalności biznesowej. GUI ma powstać na bazie tego opisu i ma służyć do wywoływania funk. biz. w nim zdefiniowanychJakub Wojt edytował(a) ten post dnia 21.08.11 o godzinie 18:06

Temat: A ja się dziwię programistom, przepraszam Was...

Jakub Wojt:

W moim przekonaniu, mówimy teraz o dwóch odmiennych, konkurujących ze sobą podejściach: wytworzenie systemu poprzez mokupy vs. modele w skali.

Nie zgodzę się.
Modele doświadczalne tworzy się, aby badać potencjalnie nieprzewidywalne zachowanie 'układu rzeczywistego' przed jego powstaniem.

Spróbuję w twoim zdaniu zmienić kilka słów:
Model systemu tworzy się, aby badać potencjalnie nieprzewidywalne zachowanie "architektury systemu" przed jej powstaniem.
Moim zdaniem brzmi sensownie i co więcej stwierdzenie nadal jest prawdziwe :)

Czego w programie nie można przewidzieć, jeśli model biznesowy jest spójny i kompletny (a jest bo w 'mojej metodyce' przeszedł formalne testy) ?
'Sprzęt' zachowuje się w sposób przewidywalny, domena (model) jest przewidywalna...

Po pierwsze nie rozumiem, w jaki sposób model biznesowy może przejść formalne testy. Moim zdaniem może przejść co najwyżej akceptację klienta. Co innego system. Zaimplementowany model można przetestować. Ale pisałeś, że GUI powstaje przed implementacją :)

Po drugie części mogą być bardzo stabilne i dobrze przetestowane. Serwer aplikacji jest ok, serwer bazodanowy jest ok, komponent "X" jest ok, klasa "Y" jest ok. Ale jak to wszystko współdziała i czy współgra? Tu jest największe wyzwanie dla architekta, testera i programisty. Dlatego architektura powinna powstać przed GUI. Architektura systemu jest tym właśnie modelem w skali.

Po trzecie model z założenia nie może być kompletny, co najwyżej spójny. To znaczy, że w naszych założeniach i w naszym modelu rzeczywistości model zachowuje się spójnie i nie wykazuje anomalii. Całej rzeczywistości jak na razie nikt nie opisał, ani w informatyce, ani w fizyce.

GUI w moim rozumieniu nie jest żadnym mockiem ani modelem doświadczalnym - jest po prostu prostu częścią rozwiązania (programu) odpowiedzialną za pośredniczenie między użytkownikiem a funkcjonalnością biznesową i tylko od tych dwóch elementów powinna zależeć jego forma.

Jak nie nazywać mockupa, nadal będzie wydmuszką bez zawartości. Projektując GUI przed architekturą stosujemy pewien chwyt marketingowy. Mówimy klientowi, że prawie wszystko już mamy zrobione, przecież mamy już ekrany, a tak na prawdę mamy nie wiele warte wytyczne, że pole tekstowe ma mieć rozmiary 23x121px i znajdować się 78px od górnej krawędzi i 234px od prawej. Ma mieć obramowanie ultramarynowe z zaokrąglonymi krawędziami, itp. To wszystko są wymagania niefunkcjonalne. Natomiast w pierwszej kolejności powinno się skupić na wymaganiach funkcjonalnych, chociażby dlatego, by móc oszacować pracochłonność przedsięwzięcia.

Podchodząc od architektury budujemy najpierw prototyp w skali.

Logika biznesowa i GUI powinno zależeć od architektury ?
Moim zdaniem, powinno się dążyć do odwrotnej sytuacji.

Czyli architektura powinna zależeć od logiki biznesu (logika biznesowa jest niepoprawnym sformułowaniem) oraz GUI. Jest to prawdziwe stwierdzenie tylko w 50%. Architektura powinna zależeć od logiki biznesu, a GUI od architektury. Powiem przewrotnie: namalujemy przepiękny webowy interfejs GUI, a potem okaże się, że mamy system zrealizować w Delphi. To dopiero będzie event. Podobno historycznie taka rzecz nawet kilka razy się zdarzyła.

Rozmowa na początku o wyglądzie sprawia, że zapominamy co tak naprawdę chcemy,

W 'mojej' metodyce, pierwszym etapem realizacji jest stworzenie formalnego opisu funkcjonalności biznesowej. GUI ma powstać na bazie tego opisu i ma służyć do wywoływania funk. biz. w nim zdefiniowanych

Chętnie poznam "twoją" metodykę. Mówię tu akurat poważnie. Czy możesz pokrótce opisać na czym ona polega lub z jakiej metodyki się wywodzi?

Temat: A ja się dziwię programistom, przepraszam Was...

Piękne rzeczy piszecie, Panowie :)
Super się czyta, macie 100% racji. Naprawdę.
To wszystko napewno zadziała w przypadku, kiedy będziemy mieli pełną profeskę po wszystkich stronach kontraktu: klient będzie dokładnie wiedział, czego chce, wyznaczy osoby odpowiedzialne, nada kompetencje, po naszej stronie poprowadzimy projekt zgodnie z zasadami, nie zważając na ŻADNE naciski ze strony handlowców ("dajcie coś wreszcie, bo w tym miesiącu musi pójść faktura"), ewentualni podwykonawcy nigdy się nie opóźniają, dają się weryfikować, audytować i robią wszystko dobrze.
Pięknie, ale takich projektów jest może 5%, z czego może 1/4 zostaje w ogóle ukończona (zmienił się prezes, mamy kryzys, zmieniły się koncepcje, osoba prowadząca projekt od strony klienta odeszła itd itp).
A jak w takim razie realizować pozostałe 95%?

Temat: A ja się dziwię programistom, przepraszam Was...

Piotr Głudkowski:
Piękne rzeczy piszecie, Panowie :)
Super się czyta, macie 100% racji. Naprawdę.
To wszystko napewno zadziała w przypadku, kiedy będziemy mieli pełną profeskę po wszystkich stronach kontraktu:

Zasadniczo będzie super, jeśli po jednej ze stron będzie wystarczająco wysoki poziom profesjonalizmu (lepiej oczywiście po stronie dostawcy). Jeśli dodamy do tego obustronne dążenie do zrealizowania projektu, może być całkiem nieźle.

klient będzie dokładnie wiedział, czego chce,

Niestety klient nigdy dokładnie nie wie. Tu działa ta reguła, że klient będzie wiedział czego chce dopiero wtedy gdy to coś zobaczy. Tak samo działa reguła, że klient od razu będzie wiedział, że na pewno nie tego chciał, ale dopiero wtedy, gdy to zobaczy :)

wyznaczy osoby odpowiedzialne,

I tu jest chyba sedno sprawy: klient, przedstawiciel użytkownika lub sponsor muszą być decyzyjni. Jeśli będą z każdą fajką latać do szefa, a on do prezesa, to zarżniemy każdy projekt i to już na wstępie. Niestety w niektórych metodykach wyjdzie to pod koniec projektu, w innych po tygodniu. Dlatego wolę te, w których tego rodzaju problemy objawiają się na początku, a nie na końcu.

nada kompetencje, po naszej stronie poprowadzimy projekt zgodnie z zasadami,

Szczerze mówiąc, to nie wyobrażam sobie projekt, prowadzony bez żadnych zasad. To tak jak wysłać żołnierzy na pole walki z poleceniem walki tak, jak każdy potrafi. Już ponad 2000 lat temu w Chinach docenili prowadzenie wojny zgodnie ze sztuką i zasadami. Zasady mieli przeróżne, np. spal wioski za sobą, to nie będziesz miał partyzantki. Także nie mam tu na myśli jedynie pięknych zasad.

W projekcie zasady też muszą być. Najbardziej luźna (w moim mniemaniu) metodyka XP narzuca 12 dobrych praktyk, których dobrze się trzymać. A bez zasad to jak by to było? Każdy robi to co chce, kiedy chce i tak jak chce? Nawet w świecie oprogramowania Open programiści na coś się zmawiają i jakieś zasady stosują.

nie zważając na ŻADNE naciski ze strony handlowców ("dajcie coś wreszcie, bo w tym miesiącu musi pójść faktura"),

Jeśli projekt poprowadzimy zgodnie z modelem spiralnym, handlowcy po miesiącu (lub nawet krócej) dostaną coś co będą mogli zweryfikować. Wtedy te dwa prawa o kliencie zadziałają o wiele wcześniej.

ewentualni podwykonawcy nigdy się nie opóźniają,

Tu wchodzi zarządzanie ryzykiem, które z kolei jest procesem ciągłym. Zarządzanie ryzykiem kosztuje, ale ryzykowne projekty bez zarządzania ryzykiem kosztują więcej. Tylko dlaczego dziwnym trafem albo organizacja ma nieograniczony apetyt na ryzyko, albo lista ryzyk powstaje na początku projektu i potem nikt tą listą nie zajmuje się?

dają się weryfikować, audytować i robią wszystko dobrze.

Jak z podwykonawcami dogadamy się tak będzie. Jeśli dyrektor finansowy nie rozumie, że tani podwykonawca, który nie daje się audytować jest bardziej ryzykowny niż trochę droższy, ale dający się audytować, to co ja mogę tu więcej dodać. Rzecz jasna można pójść w stronę tego bardziej ryzykownego, ale z pełną świadomością ryzyka.

Pięknie, ale takich projektów jest może 5%,

Proponował bym jednak projekty rozpoznawać po budżecie. W krajach zachodnich odpalenie projektu jest zdarzeniem. W Polsce często dodaje się jakiś przymiotnik typu "mini mini". Tak jakby projekt, ale mini mini projekt. Jedna osoba w jeden tydzień zrobi wszystko. Jak wrzucimy wszystkie polskie projekty w jeden worek, to nam rzeczywiście wyjdzie 5% udanych.

z czego może 1/4 zostaje w ogóle ukończona (zmienił się prezes,

Jak firma ma strategię, to zmiana prezesa nie powinna na niczym zaważyć. Jak chcemy zdobyć 25% jakiegoś segmentu, to cel wygląda tak samo po zmianie prezesa. Nadzwyczajna rewizja celi strategicznych zachodzi jedynie w nadzwyczajnych sytuacjach.

mamy kryzys,

Największym sukcesem niektórych projektów było to, że nigdy nie zostały rozpoczęte, największą porażką innych to, że zostały zakończone. Przy kryzysie sytuacja biznesowa, otoczenie i rzeczywistość się zmienia. Wtedy bezwzględnie powinna odbyć się rewizja projektów. Niektóre trzeba zamknąć, innych nie rozpoczynać, a niektóre zmodyfikować.

zmieniły się koncepcje,

Jak zmieniła się koncepcja, to projekt przestał być zasadny. Zamykamy projekt. Porażką projektową będzie utopienie kasy, aby projekt skończyć. Produkt przecież będzie bezwartościowy i na pewno nie przyniesie zakładanego zwrotu kosztów inwestycji.

osoba prowadząca projekt od strony klienta odeszła itd itp).

Jak mamy dokumentację dobrej jakości a w zespole ktokolwiek został z pierwotnej ekipy, to nie powinno to stwarzać problemu.

A jak w takim razie realizować pozostałe 95%?

W czasach kryzysu oprogramowania (które do tej pory trwa) mówiło się o 75%. Sposobów na to to jest wiele. Wszystkich tu nie opiszę, a nawet gdybym opisał, każdy projekt i tak wymaga indywidualnego podejścia, tak więc taki opis wiele nie da. Dosyć uniwersalną regułę daje Cristal. Problem w tym, że w firmie, jak już wybierze się np. PRINCE2, to wszędzie go się stosuje bez opamiętania się. To tak jak, gdy masz młotek wszystkie problemy zaczynają wyglądać jak gwoździe :)

Temat: A ja się dziwię programistom, przepraszam Was...

Alku, wiadomo to przecież.
Chciałem po prostu zwrócić uwagę, że każda metodyka sprawdza się od A do Z jedynie w kilku % projektów. Zależy to od tego wszystkiego co napisaliśmy: Ty, ja i inni.
Co więcej: w większości projektów dobór odpowiedniej metodyki ich prowadzenia znakomicie zwiększa szanse na sukces, a nietrafny wybór metodyki potrafi utopić projekt.
Nie wyobrażam sobie prowadzenia projektu systemu bankowego w metodyce zwinnej, i tak samo nie wyobrażam sobie prowadzenia projektu niewielkiego sklepu internetowego zgodnie z kanonami Prince 2.
Ty natomiast wspomniałeś, że niektóre metodyki radzą sobie lepiej z pewnymi uwarunkowaniami formalnymi, jakie możemy napotkać po stronie klienta.
Do czego dążę?
A no do tego:
1. Nie ma jednej słusznej, najlepszej metodyki prowadzenia projektów;
2. Firmy, potrafiące stosować różne metodyki i potrafiące je prawidłowo dobrać do danego projektu (praktyka!!!!) wygrywają na rynku.
Wiem, że to truizmy, ale mam wrażenie, że wiele firm, które stosują tylko jedną metodykę prowadzenia projektów, uważa tą wybraną metodykę za jedyną słuszną i najlepszą.
Nie ma tak :) Dla mnie to jest sygnał, że firma jest świeża, założona przez ludzi bez dużego doświadczenia w branży. I w większości przypadków mam rację :)Piotr Głudkowski edytował(a) ten post dnia 23.08.11 o godzinie 10:28

Temat: A ja się dziwię programistom, przepraszam Was...

I tu rzeczywiście zgadzam się z Tobą, Piotrze, że nie powinno się stosować metodyki od A do Z w 100%. Chciałem jednak zwrócić jedynie uwagę na to, że niektóre metodyki są ramami projektowymi (mam tu ma myśli RUP i Crystal). W przypadku RUP (uważaną za ciężką) można poprowadzić również projekt sklepu internetowego, ale trzeba umieć RUP do tego dostosować. Podobnie można poprowadzić Crystalem (typowo metodyka zwinna) projekt systemu bankowego, ale też trzeba umieć go do tego dostosować :) Ale to są wyjątki potwierdzające regułę: trzeba umieć dobrać zestaw narzędzi zarządczych do konkretnego projektu :)

Problem tak naprawdę jest jeszcze bardziej skomplikowany: pomimo tego, co pisałem wyżej, w sektorze budżetowym najlepiej jednak sprawdza się PRINCE2. Wynika to jeszcze z innych uwarunkowań :)

Temat: A ja się dziwię programistom, przepraszam Was...

klient będzie dokładnie wiedział, czego chce,

Niestety klient nigdy dokładnie nie wie.

zawsze walczę z tym stwierdzeniem. Dlaczego? Bo klient DOSKONALE wie czego chce. Jak ktoś idzie do salonu po brykę to mówi: 5 sek, do setki, cabrio, czerwony.

Dobry dostawca mówi: OK, Ferrari.

W IT mamy: klient mówi: "5 sek, do setki, cabrio, czerwony" a informatyk pyta "czyli co Pan chce, poruszę opisać dokładnie konstrukcję tego to my my ją wykonamy".

Z tym "walczę"....

Więc przychodzi Prezes, mówi: chcę usprawnić wystawianie faktur i produkcję i myślę, że jakieś oprogramowanie by mi w tym pomogło. A informatyk pyta tegoż prezesa: to proszę nam dokładnie opisać jakie oprogramowanie mamy wytworzyć.

Czy to nie jest głupie?

A jeszcze głupsze jest to, że nie raz:
- Prezes ma komputer bo pisze emalie i jest przekonany, że zna się na komputerach,
- informatyk wierzy, że ten Prezes, skoro zna się na komputerach, potrafi powiedzieć mu co ma napisać
- jeden i drugi uważa, że niczego nie trzeba planować bo przecież to jest proste...

bajer polega na tym, że wielu z nas tu zarabia sprzątając po tym co opisałem a "brud" do sprzątania stale powstaje nowy.....

Temat: A ja się dziwię programistom, przepraszam Was...

Piotr Głudkowski:
Wiem, że to truizmy, ale mam wrażenie, że wiele firm, które stosują tylko jedną metodykę prowadzenia projektów, uważa tą wybraną metodykę za jedyną słuszną i najlepszą.
Nie ma tak :) Dla mnie to jest sygnał, że firma jest świeża, założona przez ludzi bez dużego doświadczenia w branży. I w większości przypadków mam rację :)

powiedział bym, że metodykę należy dostosować do warunków i otoczenia projektu, żadna "jedna fajna" nie dział jako "uniwersalna wymagająca tylko dostosowania"... dlaczego? Bo każdy projekt to jakaś mieszkanka kodu który ma powstać i kodu dostępnego na rynku, który wykorzystamy. Proporcje mogą być skrajnie różne wiec mamy "nieskończenie wiele" wariantów.

Dobrą praktyka jest, na bazie posiadanej wiedzy i doświadczenia, ustalanie dla każdego projektu jakie metody pracy i jakie narzędzia zostaną wykorzystane i PO CO.

Temat: A ja się dziwię programistom, przepraszam Was...

Nie zgodzę się.
Modele doświadczalne tworzy się, aby badać potencjalnie nieprzewidywalne zachowanie 'układu rzeczywistego' przed jego powstaniem.

Spróbuję w twoim zdaniu zmienić kilka słów:
Model systemu tworzy się, aby badać potencjalnie nieprzewidywalne zachowanie "architektury systemu" przed jej powstaniem.
Moim zdaniem brzmi sensownie i co więcej stwierdzenie nadal jest prawdziwe :)

Jak architektura może się ‘zachowywać’ ?

Czego w programie nie można przewidzieć, jeśli model biznesowy jest spójny i kompletny (a jest bo w 'mojej metodyce' przeszedł formalne testy) ?
'Sprzęt' zachowuje się w sposób przewidywalny, domena (model) jest przewidywalna...

Po pierwsze nie rozumiem, w jaki sposób model biznesowy może przejść formalne testy.

http://en.wikipedia.org/wiki/Model_checking
Większość modeli może weryfikować 'maszynowo / automatycznie' pod względem spójności i kompletności.
Oczywiście tylko pod warunkiem, że istnieje jego formalna specyfikacja.

Takie testy pozwoliły by analitykowi na szybkie (tzn. kiedy system jest na etapie projektowania a nie w fazie produkcyjnej) wykrywanie błędów modelu.

Moim zdaniem może przejść co najwyżej akceptację klienta.

Mam nadzieję, że kiedyś ‘akceptacja klienta’ będzie polegać na weryfikacji modelu analityka i wywołaniu na nim testów. IMHO wszystkim zaangażowanym w projekt powinno na tym zależeć... ale to tylko tak na marginesie

Co innego system. Zaimplementowany model można przetestować. Ale pisałeś, że GUI powstaje przed implementacją :)

Analityk zapisuje model klienta w notacji 'obiektowej'.
Ponieważ notacja obiektowa jest 'formalna' nic nie stoi na przeszkodzie, żeby tak zapisany model wprowadzić do solver'a i sprawdzić jego jakość.

GUI nie jest do tego potrzebne.. architektura systemu tym bardziej.

Po drugie części mogą być bardzo stabilne i dobrze przetestowane.

Tak, ale jak już pisałem, testy sprawdzają, czy system robi to co powinien, ale nie sprawdzą tego, czy jego działanie nie jest przypadkiem ‘głupie’.

Serwer aplikacji jest ok, serwer bazodanowy jest ok, komponent "X" jest ok, klasa "Y" jest ok. Ale jak to wszystko współdziała i czy współgra?
Tu jest największe wyzwanie dla architekta, testera i programisty.

IMHO takie kwestie programista / tester powinien mieć w nosie. Zadaniem programisty jest zaimplementowanie jakiejś części (warstwy) funkcjonalności. Jeśli ta funkcjonalność przechodzi zadane testy - to na tym odpowiedzialność programisty się kończy. Jeśli kolejne warstwy kodu ' nie kleją się ' to znaczy, że architekt skopał sprawę.

A tester po prostu ... testuje. Dostaje specyfikacje, testuje, a później zwraca dokument z informacja o tym co działa a co (i 'jak') nie działa. Przynajmniej wg.mnie tylko to powinno wyglądać.

Oczywiście można uważać, że analityk powinien być 'programistą, projektantem i testerem', projektant - 'analitykiem, programistą i testerem', programista - 'analitykiem, projektantem i testerem' itd ...

Na podstawie moich doświadczeń sądzę jednak, że w takiej sytuacji (wszyscy odpowiedzialni za wszystko), żaden sensowny produkt nie powstanie.

Dlatego architektura powinna powstać przed GUI.

argumentacja mnie nie przekonała ;)
Jak już pisałem, dla mnie kolejność jest taka (jakby to ‘orginalnie’ nie brzmiało): najpierw się ustala co chce się zrobić, (funkcjonalność biznesowa + GUI) a później się to robi (architektura i implementacja).

Ale może po prostu mam za mało doświadczenia albo rozumu ;p

Architektura systemu jest tym właśnie
modelem w skali.
Po trzecie model z założenia nie może być kompletny, co najwyżej spójny. To znaczy, że w naszych
założeniach i w naszym modelu rzeczywistości model zachowuje się spójnie i nie wykazuje anomalii.
Całej rzeczywistości jak na razie nikt nie opisał, ani w informatyce, ani w fizyce.Oczywiście że może być i > nawet powinien :)

... kompletny może być, ale tylko 'w ściśle określonym kontekście'. :)

http://en.wikipedia.org/wiki/Model_theory#Axiomatizabi...

Projektując GUI przed architekturą stosujemy pewien chwyt marketingowy. Mówimy klientowi, że prawie wszystko już mamy zrobione,

W moim ‘podejściu’ GUI powstaje zaraz po analizie ponieważ zależy ono tylko od jej wyników (a przynajmniej tak mi się wydaje)

No kurcze, przecież chciałem przedstawić jakąś ‘metodykę realizacji projektu’ a nie ‘metody oszukiwania klienta’ :)

przecież mamy już ekrany, a tak na prawdę mamy nie wiele warte wytyczne, że pole tekstowe ma mieć rozmiary
23x121px i znajdować się 78px od górnej krawędzi i 234px od prawej.

Projektant ma informację o tym, co w tym polu będzie się znajdować (parametry funkcji biznesowych + definicje typów tych parametrów). Na tej podstawie będzie umiał dobrać typ i wygląd ‘pól tekstowych’.

A ponieważ zna się na ergonomii - elegancko rozmieści te pola na formularzu.

Ma mieć obramowanie ultramarynowe [..]
Natomiast w pierwszej kolejności powinno się skupić na wymaganiach funkcjonalnych, chociażby dlatego, by móc oszacować pracochłonność przedsięwzięcia.

Właśnie dlatego najpierw robi się analizę. A na jej podstawie – GUI.

Metodyka odnosi się do sposobu realizacji projektu a nie do szacowania jego kosztów.

Architektura powinna zależeć
od logiki biznesu, a GUI od architektury.
Powiem przewrotnie: namalujemy przepiękny webowy interfejs GUI, a potem okaże się, że mamy system zrealizować w Delphi. To dopiero będzie event.
Podobno historycznie taka rzecz nawet kilka razy się zdarzyła.

Dlatego właśnie napisałem, że sposób opisu GUI powinien być niezależny od technologii (dedykowany język).. A z resztą to może być zwykły HTML.

...Opisana metodyka dotyczy systemów których GUI można stworzyć w HTML.

Ostatecznie nie ma ‘najlepszych rozwiązań’, są jedynie ‘rozwiązania skuteczne’...

W 'mojej' metodyce, pierwszym etapem realizacji jest stworzenie formalnego opisu funkcjonalności biznesowej. GUI ma powstać na bazie tego opisu i ma służyć do wywoływania funk. biz. w nim zdefiniowanych

Chętnie poznam "twoją" metodykę.
Mówię tu akurat poważnie. Czy możesz pokrótce opisać na czym ona polega

Od jej opisu zaczęła się ta rozmowa :)

lub z jakiej metodyki się wywodzi?

Podobno od wodospadu :)

Temat: A ja się dziwię programistom, przepraszam Was...

Jarek Żeliński:

klient będzie dokładnie wiedział, czego chce,

Niestety klient nigdy dokładnie nie wie.

zawsze walczę z tym stwierdzeniem. Dlaczego? Bo klient DOSKONALE wie czego chce. Jak ktoś idzie do salonu po brykę to mówi: 5 sek, do setki, cabrio, czerwony.

Jeśli klient wie co chce, to z reguły chce gotowe rozwiązanie. Tak chcę Windows 7 bo tam jest Access (czerwone Ferrari) :) W przypadku typowych projektów (z wysokim poziomem innowacyjności) klient ma mglisty obraz tego co chce i jakie efekty chce osiągnąć (to już będzie naprawdę nieźle), ale często te efekty są przesłonięte zasłoną poufności strategicznego projektu. Czasami klient mniej więcej wie czego chce, ale trzeba z nim porozmawiać, tak by uporządkował myśli.

Nie zaprzeczam, że klient wie co chce. Powątpiewam, że klient zawsze dokładnie wie. Bez wspólnej rozmowy klienta z dostawcem prawie zawsze zachodzi sytuacja, że klient myśli, że nie ma co wyjaśniać bo on to wie, a dostawca myśli, że zrozumiał to co klient myśli.

Dobry dostawca mówi: OK, Ferrari.

W IT mamy: klient mówi: "5 sek, do setki, cabrio, czerwony" a informatyk pyta "czyli co Pan chce, poruszę opisać dokładnie konstrukcję tego to my my ją wykonamy".

Z tym "walczę"....

Więc przychodzi Prezes, mówi: chcę usprawnić wystawianie faktur i produkcję i myślę, że jakieś oprogramowanie by mi w tym pomogło. A informatyk pyta tegoż prezesa: to proszę nam dokładnie opisać jakie oprogramowanie mamy wytworzyć.

Czy to nie jest głupie?

Jest to głupie. Głupie jest, gdy prezes opisuje dokładną konstrukcję systemu, jak również głupie jest gdy użytkownik bardzo dokładnie opisuje działanie systemu. Głupim jest gdy informatyk opisuje wszystkie wymagania użytkownika bez jego udziału.

Dostawca i klient powinni się spotkać przed wyceną, by się zrozumieć. Wtedy są szanse na uniknięcie sytuacji, gdy od strony IT rzucamy hasło: użytkownik nie wie czego chce.

A jeszcze głupsze jest to, że nie raz:
- Prezes ma komputer bo pisze emalie i jest przekonany, że zna się na komputerach,
- informatyk wierzy, że ten Prezes, skoro zna się na komputerach, potrafi powiedzieć mu co ma napisać
- jeden i drugi uważa, że niczego nie trzeba planować bo przecież to jest proste...

Niestety taka sytuacja jest nadal dosyć powszechna. Więcej, czasem prezes sam by to wszystko zrobił, tyle że nie ma czasu. Tak więc to przestawcie tu, tamto tam, tu dodajcie taką klasę, a tam dodajcie kilka kolumn do tabeli, bo po co nam kolejna tabela.

bajer polega na tym, że wielu z nas tu zarabia sprzątając po tym co opisałem a "brud" do sprzątania stale powstaje nowy.....

I tu rzeczywiście wiele osób okazuje niepoprawny optymizm graniczący z ...(wiadomo) myśląc, że nam się uda, że my skrócimy czas projektowy, że pójdziemy na skróty, że zaoszczędzimy czas, itp. Ja zawsze powtarzam, że popełnianie podręcznikowych błędów doprowadzi do podręcznikowych skutków o podręcznikowej skali :)

Temat: A ja się dziwię programistom, przepraszam Was...

.Ten post został edytowany przez Autora dnia 09.08.16 o godzinie 21:48

Temat: A ja się dziwię programistom, przepraszam Was...

zawsze walczę z tym stwierdzeniem. Dlaczego? Bo klient DOSKONALE wie czego chce. Jak ktoś idzie do salonu po brykę to mówi: 5 sek, do setki, cabrio, czerwony.

Dobry dostawca mówi: OK, Ferrari.

Dlaczego klient nie poprosił po prostu o Ferrari ?
Ferrari są bardzo drogie... Czy dobry dostawca to osoba która sprzedaje najdroższy sprzęt bez oglądania się na prawdziwe potrzeby klienta ? :>

W IT mamy: klient mówi: "5 sek, do setki, cabrio, czerwony" a informatyk pyta "czyli co Pan chce, poruszę opisać dokładnie konstrukcję tego to my my ją wykonamy".

Kto to jest 'informatyk' ?
Czerwony traktor bez zadaszenia ale za to w karoserii SUV'a i z odpowiednim napędem (rakietowym) też może osiągnąć setkę w 5 (a nawet w mniej niż jedną) sekund(ę).... klient nie wspomniał o hamulcach.

Który sąd skarze (to tak a propos pytania 'po co jest dokumentacja') wykonawcę za sprzedaż czerwonego traktora z przyspieszeniem wystarczającym do błyskawicznego osiągnięcia pierwszej kosmicznej ? http://pl.wikipedia.org/wiki/Pr%C4%99dko%C5%9B%C4%87_k...

... efekt będzie taki, że firma zarobi (a raczej jej zarząd), sąd się nie zmęczy, a klient będzie orbitować.

Czyli tak jakby standard.

Z tym "walczę"....

Więc przychodzi Prezes, mówi: chcę usprawnić wystawianie faktur i produkcję i myślę, że jakieś oprogramowanie by mi w tym pomogło.
A informatyk pyta tegoż prezesa: to proszę nam dokładnie opisać jakie oprogramowanie mamy wytworzyć.

Żaden 'informatyk' nie zada takiego pytania.
Najczęściej 'informatycy' mówią: ok, zrobimy to. Czasem dodają: 'stosujemy metodykę agile / prince / RUP ...' no chyba, że to nie 'informatycy'.

I wszyscy są szczęśliwi do momentu kiedy trzeba zapłacić albo wdrożyć produkt.

Czy to nie jest głupie?

Jest. Ale głupio robią 'prezes' i 'informatycy' wiec mogą mieć pretensje tyko do siebie.

A jeszcze głupsze jest to, że nie raz:
- Prezes ma komputer bo pisze emalie i jest przekonany, że zna się na komputerach,
- informatyk wierzy, że ten Prezes, skoro zna się na komputerach, potrafi powiedzieć mu co ma napisać
- jeden i drugi uważa, że niczego nie trzeba planować bo przecież to jest proste...

'informatyk' zakłada że szef ma plan, a szef zakłada, że informatyk wie lepiej od niego co trzeba robić, bo przecież 'informatyzuje'; a teraz komputery są inteligentne.

bajer polega na tym, że wielu z nas tu zarabia sprzątając po tym co opisałem a "brud" do sprzątania stale powstaje nowy...

z tym 'zarabianiem' to bym polemizował...
Zarobił ktoś, kto sprzedał ferrari.Jakub Wojt edytował(a) ten post dnia 23.08.11 o godzinie 19:57

Temat: A ja się dziwię programistom, przepraszam Was...

Paweł Włodarski:
Nie zaplątałeś się trochę w tej metaforze ;)? Zgaduję,

nie zgaduj tylko czytaj bo robisz własnie to co większość kiepskich programistów: "wiedzą lepiej"...

wtedy ta zupełnie fikcyjna i nieocenzurowana rozmowa mogłaby wyglądać tak:

Klient mówi: "jakaś bryka coby wyrwać blachary w Mielnie"
Dobry dostawca mówi: OK, Ferrari z bajerami na lans.

mierzysz swoją miarką (kolejna choroba kiepskich programistów)

Zaś jeśli klient miałby przyjść i rzucić wymaganiami sprzętowymi("5 sek, do setki, cabrio, czerwony") to twój pierwszy przykład wydaje mi się równie (cytuję) "głupi" jak twój drugi przykład ino na innym poziomie abstrakcji ;)

pozostaje przy swoim: większość czytających MOTOR facetów zapewne potrafi napisać "5 do setki, czerwony, cabrio" i ich ukryty cel zawsze pozostanie tajemnicą (jeden leci na blachary a drugi jest fanem takich samochodów, obrażasz wielu tych drugich ludzi)

Standardowy problem z metaforami.

problem mają ci co zamiast czytać wiedzą lepiej... mój problem to (znowu mam takiego pacana w projekcie): podaje mu diagram klas a ten pajac czepia się, że nie ma asocjacji i liczności między encjami. Ja mu na to, że po pierwsze nie encje a klasy a po drugie w systemie faktura nie jest związana asocjacją z zamówieniem (na diagramie) bo logikę tę obsługuje Fabryka faktur (co pokazałem na diagramie sekwencji), po trzecie brak liczności na diagramie to brak ograniczeń na na liczność. Po drugie prawdopodobnie faktury zostaną zamienione przyszłym systemem FK i jak zastosujemy asocjacje to nie będzie to możliwe, jak poprzestanę na interfejsie do faktury to zamiana klasy Faktura na interfejs do systemu FK będzie dość prostym zabiegiem. Nie będę cytował dalszej rozmowy bo jest żenująca...

Mam nadzieję, że po protu szybko czytałeś i coś Ci umknęło...

Temat: A ja się dziwię programistom, przepraszam Was...

Jakub Wojt:

Nie zgodzę się.
Modele doświadczalne tworzy się, aby badać potencjalnie nieprzewidywalne zachowanie 'układu rzeczywistego' przed jego powstaniem.

Spróbuję w twoim zdaniu zmienić kilka słów:
Model systemu tworzy się, aby badać potencjalnie nieprzewidywalne zachowanie "architektury systemu" przed jej powstaniem.
Moim zdaniem brzmi sensownie i co więcej stwierdzenie nadal jest prawdziwe :)

Jak architektura może się ‘zachowywać’ ?

Oto jedna z definicji architektury (ISO/IEC 42010:2007): "Architektura systemu informatycznego jest to podstawowa organizacja systemu wraz z jego komponentami, wzajemnymi powiązaniami, środowiskiem pracy i regułami ustanawiającymi sposób jej budowy i rozwoju." Chociaż określenie Philippe'a Kruchtena mi bardziej odpowiada, to zauważ, że w każdej definicji architektury występują poważania (połączenia) komponentów (elementów). Zachowanie architektury przejawia się w perspektywie dynamicznej: co, z czym i w jaki sposób jest połączone. Tak jak pisałem, to że serwer aplikacji, serwer baz danych i np. IVR są przetestowane z osobna i są bez wątpienia stabilne, nie oznacza jeszcze, że ich kompozycja będzie stabilna i czy ta architektura zachowa się w sposób przewidywalny, bo za każdym tym blokiem są szczegóły i wewnętrzne powiązania.

Architektura systemu to nie tylko infrastruktura. Sam system informatyczny składa się z komponentów i warstw. W ramach warstwy występują połączenia pomiędzy komponentami, a warstwy komunikują się między sobą. Tu również stabilność pojedynczych komponentu z osobna nie daje gwarancji stabilności całej architektury.

Po to właśnie modeluje się architekturę systemu (raczej wizualnie), by wszystkie powiązania i połączenia prześledzić. I jeśli rozszerzamy interfejs jednego z komponentów powinniśmy prześledzić wszystkie powiązania i oszacować wszystkie komplikacje. Wtedy zachowanie się systemu nas nie zaskoczy.

http://en.wikipedia.org/wiki/Model_checking
Większość modeli może weryfikować 'maszynowo / automatycznie' pod względem spójności i kompletności.
Oczywiście tylko pod warunkiem, że istnieje jego formalna specyfikacja.

Z tego co widzę, to ten model i jego narzędzia są zbudowane, by testować integrację systemu. Mamy zaimplementowany system wedle zaprojektowanego modelu i automatycznie testujemy wszystkie stany systemu.

Pytanie moje jest cały czas takie same: jak zweryfikować, czy system jest tym, co użytkownik chciał? Modele systemu i implementację z reguły wykonuje ten sam dostawca. I tu pętla się zamyka, bo gotujemy się w tym samym sosie. To co tu opisujesz, z pewnością jest zasadne, gdy klient ma swój ośrodek kompetencji analitycznych. Ale wtedy jedynie przenosimy to ryzyko z siebie na klienta. Patrząc na przedsięwzięcie całościowo, nadal mamy analityka (wyoutsource'owanego), którego model sprawdzamy, a nie wymagania słowno-ustne klienta.

Mam nadzieję, że kiedyś ‘akceptacja klienta’ będzie polegać na weryfikacji modelu analityka i wywołaniu na nim testów. IMHO wszystkim zaangażowanym w projekt powinno na tym zależeć... ale to tylko tak na marginesie

Tu trzeba pokonać opór klienta przed technikalicznym myśleniem (nie wiem skąd się wzięło słowo technikalia, ale często występuje) ;)

GUI nie jest do tego potrzebne.. architektura systemu tym bardziej.

Każdy system ma architekturę, chyba że jest jedna klasa (program), jeśli dodamy do tego jedną tabelę w bazie, dostaniemy już typową (chociaż ułomną) architekturę. Kiedyś odbyłem podobną rozmowę, ktoś mi próbował wmówić, że jego system nie ma żadnej architektury. Architektura to powiązania elementów systemu. Czyli co? Nie ma elementów czy elementy nie mają powiązań?

Serwer aplikacji jest ok, serwer bazodanowy jest ok, komponent "X" jest ok, klasa "Y" jest ok. Ale jak to wszystko współdziała i czy współgra?
Tu jest największe wyzwanie dla architekta, testera i programisty.

IMHO takie kwestie programista / tester powinien mieć w nosie. Zadaniem programisty jest zaimplementowanie jakiejś części (warstwy) funkcjonalności. Jeśli ta funkcjonalność przechodzi zadane testy - to na tym odpowiedzialność programisty się kończy. Jeśli kolejne warstwy kodu ' nie kleją się ' to znaczy, że architekt skopał sprawę.

Oprócz programisty i architekta mamy integratora (często jest to starszy programista), jeśli integrator nie sprawdził wyniku swoje pracy, to sorry, ale to programista skopał sprawę. Są jeszcze testy integracyjne, no to dochodzi jeszcze skopanie sprawy przez testera. Jeśli coś się nie klei, to może skopał też i architekt, a może komponenty powstały niezgodnie z specyfikacją? Niestety te rzeczy nie są czarno-białe.

Z pewnością odpowiedzialność programisty kończy się na wyklepaniu swoje części kodu. Ale na pewno nie odpowiedzialność dostawcy. Programista, architekt, tester itp., wchodzą w skład zespołu dostawcy. Jak dostawca przetestuje integrację to jego sprawa, ale jedno jest pewne: powinien przetestować. Czy nie masz przypadkiem luki w swoim podejściu?

argumentacja mnie nie przekonała ;)
Jak już pisałem, dla mnie kolejność jest taka (jakby to ‘orginalnie’ nie brzmiało): najpierw się ustala co chce się zrobić, (funkcjonalność biznesowa + GUI) a później się to robi (architektura i implementacja).

Widzę, że ja tu Ciebie nie przekonam :) Może kilku klientów z malarskimi aspiracjami lub takich co się lepiej od nas wszystkich znają się na GUI Cię przekona. Na szczęście to nie będzie strata moich zasobów a twoich ;)

Projektant ma informację o tym, co w tym polu będzie się znajdować (parametry funkcji biznesowych + definicje typów tych parametrów). Na tej podstawie będzie umiał dobrać typ i wygląd ‘pól tekstowych’.

A ponieważ zna się na ergonomii - elegancko rozmieści te pola na formularzu.

Klient nie burzy się, że pokazujecie najpierw coś, co zatwierdza, a potem dostaje produkt z poprzestawianymi polami?

Metodyka odnosi się do sposobu realizacji projektu a nie do szacowania jego kosztów.

Niektóre metodyki mają w sobie wpisane modele estymacji kosztów projektu.

Temat: A ja się dziwię programistom, przepraszam Was...

Jarek Żeliński:

pozostaje przy swoim: większość czytających MOTOR facetów zapewne potrafi napisać "5 do setki, czerwony, cabrio" i ich ukryty cel zawsze pozostanie tajemnicą (jeden leci na blachary a drugi jest fanem takich samochodów, obrażasz wielu tych drugich ludzi)

W tym ukrytym celu jest zawsze problem. Tym ukrytym celem może być np. ekspansja na rynku. Klient nie może powiedzieć do czego będzie służyć system. Wtedy albo się jąka przy zbieraniu wymagań, albo bierze kilku dostawców do budowy systemu, albo leci na złamanie karku, by jak najkrócej wyeksponować się na ryzyko. Kończy się to z reguły tak samo :)

Temat: A ja się dziwię programistom, przepraszam Was...

.Ten post został edytowany przez Autora dnia 09.08.16 o godzinie 21:48

Temat: A ja się dziwię programistom, przepraszam Was...

Paweł Włodarski:

Jarek Żeliński:

Paweł Włodarski:
Nie zaplątałeś się trochę w tej metaforze ;)? Zgaduję,

nie zgaduj tylko czytaj bo robisz własnie to co większość kiepskich programistów: "wiedzą lepiej"...

wtedy ta zupełnie fikcyjna i nieocenzurowana rozmowa mogłaby wyglądać tak:

Klient mówi: "jakaś bryka coby wyrwać blachary w Mielnie"
Dobry dostawca mówi: OK, Ferrari z bajerami na lans.

mierzysz swoją miarką (kolejna choroba kiepskich programistów)

Wydajesz się być trochę zdenerwowany.

Znowu Ci się wydaje :)

Ej trzeba panować nad emocjami ;)

To panuj...

Bo weź przyjrzyj się teraz metaforze, która podałeś i zastanów się jakie to ma mieć przełożenie na rzeczywistość : "poproszę stronę , czerwoną, z obrazkiem na górze, niech się ładuje w 0.5 sekundy" : "dobry sprzedawca(?!) - to będzie blog!"

Moim jakże skromnym zdaniem jednak wiedza po co ma być ta strona jednak by się przydała. Jak ten fakt jest zaakcentowany w twojej metaforze? No chyba nie jest.

Jest z prostego powodu, przykład: mój kolega zażyczył sobie drugi telefon (gniazdo w ścianie) w łazience, uznał, że mu to pomoże i nie musi się z tego tłumaczyć. Wykonawca tej instalacji starał się go przekonać, że to zły pomysł (odpuszczę sobie argumenty obu stron :)) i to było głupie, bo co najwyżej powinien zapytać dlaczego i uznać nawet brak odpowiedzi (kolega ma prawo nie tłumaczyć się z tego kiedy i jakie rozmowy prowadzi).

Dobry wykonawca powinie poprzestać na stwierdzeniu, ze to będzie dodatkowe 20zł. Próba narzucenia swojego stylu spędzania czasu w łazience była bez sensu i nie żadnego uzasadnienia.

Jesteś w stanie bez metafor/porównań opisać kwestię oczekiwań klienta.

Czym jest "opis kwestii oczekiwań klienta", bo ja po protu stosuję przypadki użycia, szablony ekranów (mockupy) i model pojęciowy (taksonomię czyli model informacyjny organizacji klienta). Jako narzędzie "wykrycia" przypadków użycia
stosuje model procesów tej organizacji.

Bo z metaforami to naprawdę trzeba uważać gdyż używając tego środka komunikacji największe absurdy można przemycić.

No to polecam np. książkę:
"From Documents to Applications via Frameworks: the
Tools and Materials approach" (dostępna na Amazon), cytat:

metodyka ta Based on object-oriented design and construction
techniques, the T&M approach unifies various components
such as a leitmotif with design metaphors, applicationoriented
documents and an evolutionary approach using
prototyping. Even the implementation is supported by a
complete Java-based application framework, called JWAM
(WAM is a German acronym for the Tools & Materials
approach).

Ci ludzie (autorzy) zrobili więcej dobrych rzeczy niż być może wszyscy tu dyskutanci razem...wiec raczej nie jest to bełkot...

Temat: A ja się dziwię programistom, przepraszam Was...

Jarek Żeliński:

Bo weź przyjrzyj się teraz metaforze, która podałeś i zastanów się jakie to ma mieć przełożenie na rzeczywistość : "poproszę stronę , czerwoną, z obrazkiem na górze, niech się ładuje w 0.5 sekundy" : "dobry sprzedawca(?!) - to będzie blog!"

Moim jakże skromnym zdaniem jednak wiedza po co ma być ta strona jednak by się przydała. Jak ten fakt jest zaakcentowany w twojej metaforze? No chyba nie jest.

Jest z prostego powodu, przykład: mój kolega zażyczył sobie drugi telefon (gniazdo w ścianie) w łazience, uznał, że mu to pomoże i nie musi się z tego tłumaczyć. Wykonawca tej instalacji starał się go przekonać, że to zły pomysł (odpuszczę sobie argumenty obu stron :)) i to było głupie, bo co najwyżej powinien zapytać dlaczego i uznać nawet brak odpowiedzi (kolega ma prawo nie tłumaczyć się z tego kiedy i jakie rozmowy prowadzi).

Dobry wykonawca powinie poprzestać na stwierdzeniu, ze to będzie dodatkowe 20zł. Próba narzucenia swojego stylu spędzania czasu w łazience była bez sensu i nie żadnego uzasadnienia.

Post podzieliłem na część dydaktyczną i tematyczną także jeśli kogoś nie interesują rozważania odnośnie metafor niech przejdzie do części drugiej.

<cześć dydaktyczna>
Wiesz metafora zastosowana dobrze może pomóc ale moim zdaniem popełniasz szereg błędów stosowaniu tego środka.
Weźmy ostatni przykład, jest sytuacja A (zamówienie strony), nagle podajesz sytuację B bez żadnego powiązania logicznego (dodatkowo sytuacja B ma wiele pominięć) . Teraz wyciągasz wnioski z sytuacji B bardzo błędnie sugerując, ze wynikają z nich wnioski dla sytuacji A.

Bo teraz wyobraź sobie, że napiszę "mój kolega zażyczył sobie gniazdko do netu w łazience,uznał, że mu to pomoże i nie musi się z tego tłumaczyć. Wykonawca tej instalacji poprosił go aby jednak mu swoją decyzję wytłumaczył. Ten powiedział, że chce czatować w czasie kąpieli na to wykonawca zasugerował sieć bezprzewodową - będzie mniej kabli. Kolega krzyknął radośnie ""łaaał nawet nie wiedziałem, że można to zrobić w tak wygodny sposób, dziękuję za SUGESTIĘ!"".

Dobry wykonawca powinien zatroszczyć się aby dostarczyć klientowi rozwiązanie spełniające w najlepszy sposób jego potrzeby. "

Wszelkie wyciąganie wniosków o projektach IT z tego porównania jest absolutnie błędne. Dodatkowo jest zastawiona pułapka polegająca na tym, że teraz dyskusja z sytuacji A może się przenieść an grunt sytuacji B.
</cześć dydaktyczna>

<część tematyczna>
Abstrahując od wszelkich gniazdek, sprzedaży samochodów i innych dziwnych porównań, nadal uważam, że realizacja projektu IT jest tak złożonym przedsięwzięciem iż dążąc do rozwiązania optymalnego należy na ile to tylko możliwe dowiedzieć się jakie klient ma cele biznesowe.

A że wątek zaczął się od tematu "klient nie wie czego chce" to przychylam się do opinii Aleksandra, że czasami nie wie w 100% czego chce. A jak rozpatrzymy kwestię czterowymiarowo to klient może chcieć czegoś innego w poniedziałek a czegoś innego w czwartek bo po prostu mogły się zmienić pewne zewnętrzne czynniki albo zmienił się sam klient (jeśli mamy do czynienia z klientem "kolektywnym").
</część tematyczna>

pzdrPaweł Włodarski edytował(a) ten post dnia 24.08.11 o godzinie 21:06