Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Jako autor niejednych wymagań jestem regularnie atakowany przez
dostawców, szczególnie gotowego oprogramowania ERP (nie lubią
mnie strasznie niektórzy). Jak tylko napisze o obiektowych analizie
i projektowaniu, pisze czego robić się nie powinno bo można
zepsuć produkt słyszę, że się nie znam, oni jako wdrażający
wszystko wiedza najlepiej i moje ulubione: "nikt tak nie robi jak
Pan mówi" co najczęściej mówią mi jacyś GoldenPartnerzy.
Generalnie uważają takich jak ja projektantów za wrogów w
oferowaniu tego co oferują.

No to mam dla analityków, dostawców ERP i ich klientów w
szczególności po raz kolejny od siebie radę:

Są gotowe systemy ERP obiektowe, zbudowane na bazie obiektowych
wzorców projektowych, możliwe do rozbudowy metodami
analiza_obiektowa-projekt_obiektowy-implementacja. Teraz pora na
kilka przykładowych zaleceń metodycznych (celowo w obcym języku
ale dlaczego za moment) których sam jestem gorącym orędownikiem w
projektowaniu:


It is very important to have a clear interface between the
presentation logic (user interface) and the business logic. Do not
mix these two types of logic.

Business logic must be implemented in classes and on tables.

Never design your business logic so that it has direct references to
controls on forms or reports. The design of the business logic must
enable any relevant form or report to use it.


I teraz po kolei:
- nie wierzcie dostawcom ERP że są drogi na skróty, że nie
trzeba w kastomizajci niczego projektować tylko od razy się
"kastomizuje"
- wyrzućcie na ulicę każdego analityka, który nie zna
UML/analizy obiektowej
- nie prawda jest, że analityk wymagań na gotowy ERP nie musi
znać inżynierii oprogramowania, wystarczą dobra aparycja,
łatwość nawiązywania kontaktów i umiejętność pisania
"strukturalnych tekstów" i "specyfikacji wymagań użytkownika"
- jak przyjdzie ktoś i powie, że wdroży wraz z kastomizacja
system ERP na bazie 200 stron takiej tekstowej pseudoanalizy to
wyrzućcie go za drzwi zanim skończy te bełkotliwie herezje.

Czemu o tym pisze? Bo co jakiś czas sprawdzam dostawców ERP czy
przypadkiem nie robią czegoś wbrew woli producenta oprogramowania
które oferują i... (tu niestety nieuknikniony productplacment bo
wypada podać źródło): angielski tekst powyżej to fragment
pewnych zaleceń producenta systemu ERP, który wysuwa się na
czoło w tym kraju więc nie jest jakimś odszczepieńcem:
http://msdn.microsoft.com/en-us/library/aa857073.aspx

System ten to Framework:
http://msdn.microsoft.com/en-us/library/aa659223.aspx
i trzeba umieć tego używać a by to umieć trzeba być analitykiem
projektantem a nie tylko pisarzem...

Większość projektów bazuje na wzorcu MVC:
http://msdn.microsoft.com/en-us/library/ff649643.aspx

a dla niedowiarków:
http://msdn.microsoft.com/en-us/library/dd857485(VS.85...

A co mnie naszło, że o tym pisze? Bo jeden z moich kolejnych
klientów zaczął do mnie list od słów: "Szanowny Panie, własnie
jeden z GoldPartnerów firmy Microsoft modelowo położył mój
projekt, czy może nam Pan pomóc..." i tylko kłopot w tym, że
projekt położony ale i budżet zjedzony w 80%...

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Haha budżet to już sprawka PM i zarządzania finansami w projekcie. Jak mawiał mój niegdyś były przełożony "planuj, planuj bo na planowanie nie powinno nigdy zabraknąć czasu, jeżeli nie chcesz by Twój projekt poległ..." :)Adam Bulenda edytował(a) ten post dnia 28.01.11 o godzinie 19:35

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Zgodziłbym się z przedstawionymi tezami, ale z małym uzupełnieniem:
- w pierwszej należałoby dodać, że oczywiście nie ma drogi na skróty, trzeba projektować, chyba że opieramy wdrożenie w modelu przyrostowym (iteracyjnym), a w szczególności metodykach zwinnych, które w przeciwieństwie do modelu kaskadowego, nie wymaga szczegółowego projektu;
- tak, wyrzucajmy na ulicę analityków, którzy nie potrafią opisać koncepcji w konkretnej, jednoznacznie rozumianej notacji UML czy BPMN, ale pod warunkiem, że po stronie klienta jest ktoś, kto tą notację zna. No chyba, że wykorzystujemy metodykę np. UML do analizy "wewnętrznej", celem wyłapania dziur w koncepcji a rzeczonemu klientowi przekazujemy już tylko wyniki tej analizy w sposób dla niego zrozumiały.

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Zgodziłbym się z przedstawionymi tezami, ale z małym uzupełnieniem:
- w pierwszej należałoby dodać, że oczywiście nie ma drogi na skróty, trzeba projektować, chyba że opieramy wdrożenie w modelu przyrostowym (iteracyjnym), a w szczególności metodykach zwinnych, które w przeciwieństwie do modelu kaskadowego, nie wymaga szczegółowego projektu;

chcesz powiedzieć, że można wybudować metodą przyrostową wieżę na sto pieter bez projektu???

- tak, wyrzucajmy na ulicę analityków, którzy nie potrafią opisać koncepcji w konkretnej, jednoznacznie rozumianej notacji UML czy BPMN, ale pod warunkiem, że po stronie klienta jest ktoś, kto tą notację zna. No chyba, że wykorzystujemy metodykę np. UML do analizy "wewnętrznej", celem wyłapania dziur w koncepcji a rzeczonemu klientowi przekazujemy już tylko wyniki tej analizy w sposób dla niego zrozumiały.

BPMN czy UML to notacje a nie metodyki, modele te robi się dokładnie z tego samego powodu dla którego tworzy się rysunki techniczne czy wizualizacje architektoniczne, bez projektu można z małym ryzykiem zbić budę dla psa lub komórkę w ogródku ale nie wielopiętrowy dom ... a to, że są na świecie wielopiętrowe domy budowane bez projektu nie jest dowodem, że to dobra metoda (wygrane w Lotto nie stanowią dowodu na to, że to ogólnie dobry sposób na utrzymanie rodziny...)Jarek Żeliński edytował(a) ten post dnia 11.05.12 o godzinie 18:16

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Jako autor niejednych wymagań jestem regularnie atakowany przez dostawców, szczególnie gotowego oprogramowania ERP (nie lubią mnie strasznie niektórzy). Jak tylko napisze o obiektowych analizie i projektowaniu, pisze czego robić się nie powinno bo można zepsuć produkt słyszę, że się nie znam, oni jako wdrażający wszystko wiedza najlepiej i moje ulubione: "nikt tak nie robi jak Pan mówi" co najczęściej mówią mi jacyś GoldenPartnerzy.

Ale to komplement, bo jak się robi "tak jak wszyscy" to 80% projektów kończy się porażką albo quasi porażką (quasi sukcesem) :)

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Piotr Gorski:
- tak, wyrzucajmy na ulicę analityków, którzy nie potrafią opisać koncepcji w konkretnej, jednoznacznie rozumianej notacji UML czy BPMN, ale pod warunkiem, że po stronie klienta jest ktoś, kto tą notację zna. No chyba, że wykorzystujemy metodykę np. UML do analizy "wewnętrznej", celem wyłapania dziur w koncepcji a rzeczonemu klientowi przekazujemy już tylko wyniki tej analizy w sposób dla niego zrozumiały.

W analizie stosuję notację UML i moim jedynym życzeniem odnośnie wiedzy Klienta jest to, żeby wiedział czego chce. Jednoznaczny język (np. notacja UML), którym analityk przekaże wytyczne względem systemu dla potrzeb prac implementacyjnych, jest niezbędny. Na elaborat słowno-pisany może pozwolić sobie najwyżej Klient. To właśnie analityk musi to dalej uporządkować i „przetworzyć” na język JEDNOZNACZNY i zrozumiały np. dla programisty.

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Piotr Gorski:
...
a w szczególności metodykach zwinnych, które w przeciwieństwie do modelu kaskadowego, nie wymaga szczegółowego projektu;

aż mnie zżera ciekawość: jakież to metodyki zwinne masz na myśli?

Może te pseudo zwinne polskie nieudolne podrygi zwinności? A może w manifeście Agile jest coś na ten temat?

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Beata Iwańska:
W analizie stosuję notację UML i moim jedynym życzeniem odnośnie wiedzy Klienta jest to, żeby wiedział czego chce.

Klient zawsze wie czego chce. Problem jest w tym, by dotrzeć do tego, co klient ma na myśli. Klient z reguły mówi żargonem, skrótami. Co więcej sądzi, że rozmawia z kimś, kto myśli w podobny sposób co i on. Jak często można usłyszeć stwierdzenie: no wie pan/pani robimy to zwykle tak i tak, co tam więcej powiedzieć. Czy analityk ma poprzestać jedynie na wysłuchaniu klienta?

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Jarek Żeliński:

chcesz powiedzieć, że można wybudować metodą przyrostową wieżę na sto pieter bez projektu???

Odpowiem pytaniem, czy chcesz powiedzieć, ze wdrożenie systemu ERP można równać do budowy wieży na sto pięter? Wg mojej opinii można spory system czy to ERP czy CRM czy inny zbudować metodą przyrostową. Projekt musi być, ale nie koniecznie szczegółowy z diagramami przed rozpoczęciem. Oczywiście mogę się mylić, nie próbuję się wymądrzać a podyskutować :). Wśród klientów widzę coraz większe zainteresowanie podejściem iteracyjnym do wdrożenia. Pozwala to klientowi stopniowo uszczegóławiać koncepcję, której tak naprawdę na początku nie ma dokładnie sprecyzowanej.

BPMN czy UML to notacje a nie metodyki, modele te robi się dokładnie z tego samego powodu dla którego tworzy się rysunki techniczne czy wizualizacje architektoniczne, bez projektu można z małym ryzykiem zbić budę dla psa lub komórkę w ogródku ale nie wielopiętrowy dom ... a to, że są na świecie wielopiętrowe domy budowane bez projektu nie jest dowodem, że to dobra metoda (wygrane w Lotto nie stanowią dowodu na to, że to ogólnie dobry sposób na utrzymanie rodziny...)

Jestem zdecydowanym zwolennikiem notacji UML. Być może błędnie zrozumiałem intencje jej wykorzystania jako narzędzia do sprecyzowania wymagań wspólnie z klientem. Bo UML jako język komunikacji z developerem i, jak już wspomniałem, jako narzędzie do analizy "wewnętrznej" jest rewelacyjny.
Niemniej zanim zaczniemy projektować narzędzie musimy wiedzieć czego klient chce. No i tu z moich doświadczeń wynika, że UML może się okazać złym rozwiązaniem, bo klient go nie rozumie. Co wtedy?

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Beata Iwańska:

Jednoznaczny język (np. notacja UML), którym analityk przekaże wytyczne względem systemu dla potrzeb prac implementacyjnych, jest niezbędny. Na elaborat słowno-pisany może pozwolić sobie najwyżej Klient. To właśnie analityk musi to dalej uporządkować i „przetworzyć” na język JEDNOZNACZNY i zrozumiały np. dla programisty.

Jak najbardziej zgadzam się z tym, że analityk uporządkowuje i przetwarza koncepcję na język zrozumiały dla programisty. Opis w notacji UML jest zdecydowanie najlepszym mi znanym rozwiązaniem (pod warunkiem, że programista zna dobrze notację :)).

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Aleksander Olszewski:

aż mnie zżera ciekawość: jakież to metodyki zwinne masz na myśli?

Może te pseudo zwinne polskie nieudolne podrygi zwinności? A może w manifeście Agile jest coś na ten temat?

No cóż, metodyki zwinne dopiero raczkują na polskim rynku... też mam takie wrażenie. Niemniej klientów intryguje inne podejście do wdrożenia, gdzie będzie mniej papierów, a więcej rozmów. Częste spotkania i analiza w miejsce czytanie 1000 stronicowych koncepcji...

Nie jestem zwolennikiem ścisłego trzymania się jakiejkolwiek metodyk. Być może błędnie, ale zauważyłem, że wspólnie z klientem powinno się ustalać model optymalnej współpracy. Metodyki są raczej zbiorem najlepszych praktyk... dla mnie.

Mylę się? Po tym co napisałeś wygląda, że masz duże doświadczenie w metodykach zwinnych. Sądzisz, że przeciwieństwo "polskich podrygów zwinności" nadadzą się do wdrożenia 100 piętrowej wieży? Czy raczej powyżej 3 pięter nie ma co startować?

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Aleksander Olszewski:

Beata Iwańska:
W analizie stosuję notację UML i moim jedynym życzeniem odnośnie wiedzy Klienta jest to, żeby wiedział czego chce.

Klient zawsze wie czego chce. Problem jest w tym, by dotrzeć do tego, co klient ma na myśli. Klient z reguły mówi żargonem, skrótami. Co więcej sądzi, że rozmawia z kimś, kto myśli w podobny sposób co i on. Jak często można usłyszeć stwierdzenie: no wie pan/pani robimy to zwykle tak i tak, co tam więcej powiedzieć. Czy analityk ma poprzestać jedynie na wysłuchaniu klienta?

A tu się nie zgodzę z Tobą Aleksander, bo klient nie zawsze wie czego chce. No chyba, że mówimy o tym, że chce wdrożyć "system" bo będzie lepiej :). Rolą dobrego analityka jest m.in. uświadomić klientowi czego tak naprawdę chce=potrzebuje, a więc co pozwoli mu usprawnić jego biznes, szybko się zwrócić itd. Klient jest ekspertem w swoim biznesie a analityk powinien wiedzieć jak zoptymalizować procesy i wesprzeć funkcjonalnie systemem. Co do pozostałych: żargon, skróty itp itd - to fakt :).

Beato, ciekawy jestem dlaczego tak bardzo chcesz, żeby klient wiedział czego chce? Zauważyłem, że jak nie wie, to dopiero analiza robi się ciekawa. Wtedy masz naprawdę pole do wykazania się doświadczeniem i kreatywnością. Co sądzisz?

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Piotr Gorski:
...
Mylę się? Po tym co napisałeś wygląda, że masz duże doświadczenie w metodykach zwinnych. Sądzisz, że przeciwieństwo "polskich podrygów zwinności" nadadzą się do wdrożenia 100 piętrowej wieży? Czy raczej powyżej 3 pięter nie ma co startować?

Żadna ze zwinnych metodyk nie odrzuca formalnej notacji. Co więcej Crystal proponuje sesję analizy na początku i w połowie iteracji, Scrum na początku iteracji a XP stosuje tzw. user story i alegorie. Co więcej niektóre z metodyk Agile proponują przypadki użycia jako standardowy opis wymagań. Sam manifest Agile mówi tyle: Przekłądamy działające oprogramowanie ponad obszerną dokumentację. Oznacza to tyle co oszczędność działania: tyle dokumentacji co trzeba w projekcie a nie tyle co bywa zwykle.

Ciężko powiedzieć ile pięter można wybudować poszczególną metodyką. Powiedziałbym, że każdą da się zbudować około 50 pięter. Pozostałe to kwestia zwracania uwagi na szczegóły. Tu niestety w przypadku np. iteracyjno-przyrostowego podejścia czy cyklicznego rozwoju istotną kwestią jest dobrze utrzymany projekt systemu czy dokumentacja architektury. Inną alegorią (która mi bardziej przypadłą do gustu) jest pomyślenie o projekcie jako przeprawie przez tereny bagienne: można na raz, można na raty, można szukać ścieżki, a można ją wybudować dla siebie czy następnych podróżników.

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Piotr Gorski:
...
A tu się nie zgodzę z Tobą Aleksander, bo klient nie zawsze wie czego chce.

Znany kawał mówi tyle, że klient będzie wiedział czego chce dopiero wtedy, gdy zobaczy to czego nie chciał ;)

No chyba, że mówimy o tym, że chce wdrożyć "system" bo będzie lepiej :). Rolą dobrego analityka jest m.in. uświadomić klientowi czego tak naprawdę chce=potrzebuje, a

tu ja się nie zgodzę. Analityk nie może uświadamiać. Co najwyżej konsultant :) Analityk powinien zrozumieć jak ten biznes się kręci i co IT może wytworzyć by ten biznes wesprzeć. Czyli w sumie się zgadzamy :)

więc co pozwoli mu usprawnić jego biznes, szybko się zwrócić itd. Klient jest ekspertem w swoim biznesie a analityk powinien wiedzieć jak zoptymalizować procesy i wesprzeć funkcjonalnie systemem. Co do pozostałych: żargon, skróty itp itd - to fakt :).

Beato, ciekawy jestem dlaczego tak bardzo chcesz, żeby klient wiedział czego chce? Zauważyłem, że jak nie wie, to dopiero analiza robi się ciekawa. Wtedy masz naprawdę pole do wykazania się doświadczeniem i kreatywnością. Co sądzisz?

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Projekt musi być, ale nie koniecznie szczegółowy z diagramami przed rozpoczęciem.

to czym jest taki projekt???

Oczywiście mogę się mylić, nie próbuję się wymądrzać a podyskutować :). Wśród klientów widzę coraz większe zainteresowanie podejściem iteracyjnym do wdrożenia. Pozwala to klientowi stopniowo uszczegóławiać koncepcję, której tak naprawdę na początku nie ma dokładnie sprecyzowanej.

ostatnie zdaniem jest kluczem większości porażek... "co prawda nie mam pojęcia o co mi chodzi ale zacznijcie, zobaczę co z tego wyjdzie", najgorsze jest to, że ten sam zamawiający ma potem pretensje, że nic nie wyszło...

powiem tak, dyskusji na ten temat przewaliło się wiele i może lepiej je poczytać zamiast bić kolejną piane, po protu nie widziałem, i nie ja jeden - za wyjątkiem nieskomplikowanych systemów typu strony www czy jakieś rejestry - ukończonego w terminie i budżecie projektu biznesowego, który wystartował by bez projektowania. Dziś po raz kolejny wysłuchałem jako to klient, który mi trzy lata temu powiedział, że wdroży ERP bez analizy i projektu bo uznali, że "prace analityczne przed zakupem są niepotrzebne, mówi tak każdy dostawca ERP jaki u nich był a to duże firmy więc wiedzą lepiej". Rok temu procesowali się z jednym z tych dostawców ERP, któremu niestety nie wyszło, a oni niemalże nie poszli do piachu....

Niemniej zanim zaczniemy projektować narzędzie musimy wiedzieć czego klient chce.

do tego służy analiza biznesowa

No i tu z moich doświadczeń wynika, że UML może się okazać złym rozwiązaniem, bo klient go nie rozumie. Co wtedy?

UML to projektowanie, a u klienta najpierw należy wykonać analizę biznesową, tu UML nie ma nic do rzeczy. Rysunki techniczne są dla developera, dla inwestora są wizualizacje...

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Niemniej klientów intryguje inne podejście do wdrożenia, gdzie będzie mniej papierów, a więcej rozmów.

dobrze, że nie uwierzyli w to Ci co budują nasze domy :)

Częste spotkania i analiza w miejsce czytanie 1000 stronicowych koncepcji...

1000 stronicowa koncepcja to totalna porażka...

Sądzisz, że przeciwieństwo "polskich podrygów zwinności" nadadzą się do wdrożenia 100 piętrowej wieży? Czy raczej powyżej 3 pięter nie ma co startować?

to się robi po bożemu a nie zwinnie ;) a tak zwany "wodospad" to nie rok projektowania i pięć lat developerki tylko najpierw analiza, potem projekt architektury, a potem seria projektów (podsystemy) trwających nie dłużej niż rok każdy z nich ...

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Jarek Żeliński:

powiem tak, dyskusji na ten temat przewaliło się wiele i może lepiej je poczytać zamiast bić kolejną piane, po protu nie widziałem, i nie ja jeden - za wyjątkiem nieskomplikowanych systemów typu strony www czy jakieś rejestry - ukończonego w terminie i budżecie projektu biznesowego, który wystartował by bez projektowania.

Zdaję sobie sprawę, że nie "przecieramy nowych szlaków" :), że przewaliło się... i absolutnie nie mam zamiaru "bić piany". Napisałeś ostrzeżenie, być może również do klientów, z którymi ja będę pracował. Nie zgadzam się z Tobą w pełni więc polemizuję z pewnymi tezami. Liczyłem, że czegoś się dowiem od kogoś bardziej doświadczonego.

Widzę natomiast, że Ty masz ochotę "pobić pianę" ;), bo wyciągasz z moich odpowiedzi kwestie, które są nieistotne, np. 1000 stronicowa koncepcja... to przecież oczywiste wyolbrzymienie w kontekście reszty mojej wypowiedzi.

Jarku, nie zrozum mnie źle, ale czy nie jesteś zbyt konserwatywny w swoich poglądach?

Szkoda, bo zapowiadała się ciekawa dyskusja. Poczytam, zamiast "bić pianę". Chyba że ktoś chciałby kontynuować :).

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Piotr Gorski:
Szkoda, bo zapowiadała się ciekawa dyskusja. Poczytam, zamiast "bić pianę". Chyba że ktoś chciałby kontynuować :).

Z tego co piszesz wyciągam wnioski, że opisujesz Rational Unified Process. Własnie poprzez iteracje budujemy wielki system bez początkowych jakichs szczegółowych diagramów. Budujemy, wdrazamy, patrzymy, że dobrze działa, więc bierzemy następny kawałek i tak dalej. Nie daj się zwieść agilnych historyjkom - to też iteracyjny sposób budowy oprogramowania, ale nie zawsze zespołowi chce się łapać za powiększanie dokumentacji.
A propos, czy wiesz, że RUP został opublikowany 13 lat temu ? A pierwszy większy projekt w Polsce, w którym zastosowano RUP to był system dopłat dla rolnictwa (IACS), którego budowe zaczęto w 2001 roku ?

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Napisałeś ostrzeżenie, być może również do klientów, z którymi ja będę pracował. Nie zgadzam się z Tobą w pełni więc polemizuję z pewnymi tezami. Liczyłem, że czegoś się dowiem od kogoś bardziej doświadczonego.

nie zrozum mnie źle, ale odkrywanie koła co tydzień może być dla wielu ludzi nużące, dlatego dobrym zwyczajem jest przestudiowanie grupy przed "wszczynaniem" tematu... po raz kolejny

Widzę natomiast, że Ty masz ochotę "pobić pianę" ;), bo wyciągasz z moich odpowiedzi kwestie, które są nieistotne, np. 1000 stronicowa koncepcja... to przecież oczywiste wyolbrzymienie w kontekście reszty mojej wypowiedzi.

nie mam ochoty bic piany, po prostu tu przyznałem Ci rację

Jarku, nie zrozum mnie źle, ale czy nie jesteś zbyt konserwatywny w swoich poglądach?

nie, moja praca od kilku lat polega na sprzątaniu po projektach "zwinnych", mój kolega prawnik podobni tylko w "innych warunkach"... uwierz, że to potrafi zachwiać wiarę w "postęp" i powrócić do źródeł, jest taka stara zasada zarządzania projektami: 60:40 co znaczy: 60% czasu na planowanie i 40% na realizację, proporcje spotykam róże ale im bardziej planowanie zbliża się do zera tym większy huk w drugiej części... analiza i projektowanie przed rozpoczęciem kodowania to planowanie. Wbija się ludziom do głów, że "model kaskadowy" to miesiące tworzenia dokumentacji i lata kodowania, co jest kompletna bzdurą.

Szkoda, bo zapowiadała się ciekawa dyskusja. Poczytam, zamiast "bić pianę". Chyba że ktoś chciałby kontynuować :).

zacznij od poczytania... i nie wierz w to, ze "internet zawiera całą wiedzę"...

pisze to szczerze, jakakolwiek złośliwość absolutnie nie jest moim celem.

W kwestii ciekawej dyskusji może od razu zacząć od pytania: jakie są kluczowe ryzyka w projekcie IT i jak je minimalizować? Praktyka pokazuje, ze kluczowe ryzyko to 200% obsuwy w terminie oddania i 60% większy koszt (statystyka projektów), badania te wykazują, że kluczową przyczyną jest brak lub źle zdefiniowane wymagania w projekcie.

Co może zminimalizowąć ryzyka takich wpadek?

I tu mam propozycję: nie używajmy terminów agile i wodospad bo nie mają ścisłej definicji, posługujmy się nawami kolejnych produktów tworzonych w projekcie, nazwami jego etapów. To, mam nadzieję, pozwoli uniknąć bicia piany czyli posługiwania się pojęciami nie mającymi definicji. Jarek Żeliński edytował(a) ten post dnia 12.05.12 o godzinie 01:10

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Jarek Żeliński:
moja praca od kilku lat polega na sprzątaniu

No teraz się nie dziwię ;)