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

Jak najbardziej przed właściwym projektowaniem jest faza Rozpoczęcie, która dotyka typowych biznesowych aspektów projektu. Dopiero potem jest analiza systemowa i projektowanie.

To znaczy ?

Natomiast używając alegorii z wieżą, budowa takiej wedle RUP wyglądała by mniej więcej tak jak wznoszenie żurawi

Ale budowlańcy wiedzą co robią... co to znaczy ?

Ktoś takiego klienta "rozpieszcza" :) Problem leży gdzieś po środku pomiędzy klientem a dostawcą. Jedni i drudzy powinni dojrzeć do pewnego ładu projektowego.

... i obydwaj powinni wiedzieć co robią.
Aktualnie któraś zer stron nie wie.

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

Jakub Wojt:

Jak najbardziej przed właściwym projektowaniem jest faza Rozpoczęcie, która dotyka typowych biznesowych aspektów projektu. Dopiero potem jest analiza systemowa i projektowanie.

To znaczy ?

RUP będzie to model dziedziny, model biznesowy, specyfikacja procesów itp. Np. w PRINCE2 (Przygotowanie Projektu) będzie to zarys Uzasadnienia Biznesowego itd.

Natomiast używając alegorii z wieżą, budowa takiej wedle RUP wyglądała by mniej więcej tak jak wznoszenie żurawi

Ale budowlańcy wiedzą co robią... co to znaczy ?

Żuraw budowlany nie wznosi się tak jak wieże: od dołu do góry. Skręca się najpierw z prefabrykowanych elementów część poziomą wraz z kabiną. Potem wstawia się część środkową, potem kolejną itd. Całkiem ciekawe podejście, ale uzasadnione.

Ktoś takiego klienta "rozpieszcza" :) Problem leży gdzieś po środku pomiędzy klientem a dostawcą. Jedni i drudzy powinni dojrzeć do pewnego ładu projektowego.

... i obydwaj powinni wiedzieć co robią.
Aktualnie któraś zer stron nie wie.

Z Titanikiem też tak było: jedni i drudzy wiedzieli co robią, ale czegoś zabrakło jednym i drugim. Byli zbyt pewni siebie.

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

Projektowanie z analizą biznesową na początku:

http://it-consulting.pl/autoinstalator/wordpress/2012/...

Larman bazuje na RUP (tak sądzę), z RUP'em jest ten problem, że z zasady bazuje na UML a ta notacja w zasadzie nie radzi sobie z modelem biznesowym CIM stanowiącym podstawę motywacji biznesowej projektu. Dlatego "zaliczam się" do grona uznającego RUP jako metodykę developera, zakładająca istnienie wymagań (przypadków użycia) jak u Larman'a.

Minusem procesu Larman'a dla mnie jest "opracowywanie modelu dziedziny na bazie scenariuszy UC". Modele UC i ich scenariusze to za mało by tworzyć klasy modelu dziedziny (skąd specyfikacje dokumentów jako obiektów dziedzinowych??)

P.S.
Żuraw: montuje się go na budowie z segmentów jednak zanim choć jeden z nich - segmentów - zostanie wyprodukowany musi powstać kompletny projekt całego dźwigu. Nie ma zmiłuj.Jarek Żeliński edytował(a) ten post dnia 15.05.12 o godzinie 23:01

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

Jakub Wojt:

Stanisław Jerzy Niepostyn:
Ale jaja ... ;) "Doświadczony <<Analityk

> > biznesowy>>" nie zna manifestu ....

Ani Newton ani Einstein nie pisali "manifestów" a konkretne prace naukowe...
"Manifest" to może sobie napisać każdy każdy i z dowolnego (najczęściej głupiego) powodu

Nie sądzę by niewiedza była powodem do dumy, ale ....
Ja jednak pozostanę nieugięty: jak nie mam pojęcia o danej sprawie, to nie zabieram głosu.

ale od bardzo długiego czasu wypowiada się na temat metodyk agilnych ....

jeszcze nikt nie udowodnił nie istnienia UFO (karmy, prądów wodnych etc ...) więc jak ktoś pisze, że ich (ufo, prądów etc..) niema to na prawdę nie robi odkrycia a jedynie stwierdza, że go nie ma.

XP, Scrum, FDD, TDD istnieje .... a to, że nie masz o nich pojęcia, bądź nie chcesz o nich nic wiedzieć, wcale nie oznacza, że ich nie ma.

Zatem marsz w stronę wiedzy ... :)

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

Jarek Żeliński:

Scope-creep jest wg Capersa Jonesa (i nie tylko jego) jedną z głównych przyczyn upadku projektów... i ja się z nim zgadzam. Na mnie jak płachta na byka działają próby wrzutek po zamknięciu zakresu. Witamy w procesie obsługi zmian :)

witam w procesie ich wyrzucania ;) (pisze to całkiem poważnie).

Całkiem poważnie i bardzo chętnie, ale jednak nie zawsze się da. W innym wątku (http://www.goldenline.pl/forum/2904752/wymagania-bizne... ) uzasadniałem swoje podejście "Co by tu jeszcze wywalić"? :-)

Klient ma w umowie metodykę:
1.musi wskazać biznesowe uzasadnienie wrzutki
2. musi wskazać, z czego rezygnuje w zamian przy umowie fixed price lub wskazać finansowanie

Nie mam nic przeciwko zmianom — są w projektach rzeczą zupełnie normalną i jako takie powinny być obsługiwane, kiedy już naprawdę muszą (ad. punkt 1 Twojego komentarza). I prawdą jest, że klient ma mieć w umowie procedurę na wrzutki. Ale duża część - zdawało by się dużych i profesjonalnych - firm IT w ogóle tego nie ma w umowach. I kończy się tak, jak Aleksander pisał wcześniej o naszym rodzimym podejściu — czyli "A nie dałoby się jeszcze tego i tego?". Czyli feerią nadużyć. W PL nagminne, ale nasz naród nie ma monopolu na takie kombinowanie...
Niektórzy klienci (np. polski prywaciarz-byznesmen rulezzz tutaj) będzie toczył pianę, kiedy zastosujemy punkt 2. Twojej wypowiedzi (pod którym to punktem podpisuję sie obiema rękami) do jego potoku życzeń.
Osobiście uwielbiam oglądać miny "biznesmenów-właścicieli" lub "wysoko postawionych dyrektorów" po takim dictum :-)

Ale dobrą wiadomością jest to, że (wg moich obserwacji) jest coraz lepiej ze zrozumieniem podejścia pt. fixed price = fixed scope. Lepiej, niż przed dekadą. Albo dochodzą do stanowisk lepiej wyedukowani ludzie (chyba tak), albo ci starzy się doedukowali i coś zrozumieli... (eeee... sam w to nie wierzę)

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

Bartosz Andrzejewski:
Niektórzy klienci (np. polski prywaciarz-byznesmen rulezzz tutaj) będzie toczył pianę, kiedy zastosujemy punkt 2. Twojej wypowiedzi (pod którym to punktem podpisuję sie obiema rękami) do jego potoku życzeń.
Osobiście uwielbiam oglądać miny "biznesmenów-właścicieli" lub "wysoko postawionych dyrektorów" po takim dictum :-)

ja to uczciwie mówię, zaznaczam i zapisuję w umowie...

Ale dobrą wiadomością jest to, że (wg moich obserwacji) jest coraz lepiej ze zrozumieniem podejścia pt. fixed price = fixed scope. Lepiej, niż przed dekadą. Albo dochodzą do stanowisk lepiej wyedukowani ludzie (chyba tak), albo ci starzy się doedukowali i coś zrozumieli... (eeee... sam w to nie wierzę)

też to obserwuję... moim zdaniem uczą ich pokory projekty, które spaprali sami lub spaprał im dostawca...Jarek Żeliński edytował(a) ten post dnia 16.05.12 o godzinie 17:00

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

Ale jaja ... ;) "Doświadczony <<Analityk

> > > biznesowy>>" nie zna manifestu ....

Ani Newton ani Einstein nie pisali "manifestów" a konkretne prace naukowe...
"Manifest" to może sobie napisać każdy każdy i z dowolnego (najczęściej głupiego) powodu

Nie sądzę by niewiedza była powodem do dumy, ale ....
Ja jednak pozostanę nieugięty: jak nie mam pojęcia o danej sprawie, to nie zabieram głosu.

A mimo wszytko piszesz o sprawie o której nie masz pojęcia (podważanie agile)

ale od bardzo długiego czasu wypowiada się na temat metodyk agilnych ....

jeszcze nikt nie udowodnił nie istnienia UFO (karmy, prądów wodnych etc ...) więc jak ktoś pisze, że ich (ufo, prądów etc..) niema to na prawdę nie robi odkrycia a jedynie stwierdza, że go nie ma.

XP, Scrum, FDD, TDD istnieje .... a to, że nie masz o nich pojęcia,

och ...

bądź nie chcesz o nich nic wiedzieć, wcale nie oznacza, że ich nie ma.

Oczywiście - są. Ale nie działają.

Zatem marsz w stronę wiedzy ... :)

Wiedzy czy pseudo-wiedzy ?Jakub Wojt edytował(a) ten post dnia 16.05.12 o godzinie 22:04

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

Jakub Wojt:

Zatem marsz w stronę wiedzy ... :)

Wiedzy czy pseudo-wiedzy ?

Przed chwilą zadałem pytanie na serwerze Springera (chyba wiesz co tojest Springer?).
Wprowadziłem jednen wyraz "agile". Otrzymałem ponad 10 tysiecy wyników...
Pierwszy lepszy ...
"Applying XP to an Agile–Inexperienced Software Development Team
Agile Methods are becoming each day a more and more frequently used alternative...
Liana Silva, Célio Santana, Fernando Rocha, Maíra Paschoalino and Gabriel Falconieri, et al.
Lecture Notes in Business Information Processing, 1, Volume 9, Agile Processes in Software Engineering and Extreme Programming, Part 5, Pages 114-126"

Ale drugi niemniej lepszy być może bardziej by ci pasował:
"Demography of agile gibbons (Hylobates agilis)
Demographic processes and the structure of a population of agile gibbons ( Hylobates agilis ) were investigated over 6 years in the Gunung Palung...
John C. Mitani
International Journal of Primatology, 1990, Volume 11, Number 5, Pages 411-424"

Zatem właśnie odkryliśmy agilnego małpiszona ...

Warto zatem zdobywać wiedzę ?

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

Jakub Wojt:
A mimo wszytko piszesz o sprawie o której nie masz pojęcia

Stanisław Jerzy Niepostyn:
Przed chwilą zadałem pytanie na serwerze Springera (chyba wiesz co tojest Springer?).

A przecież można dyskutować bez udowadniania, kto ma dłuższego...

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

Wiedzy czy pseudo-wiedzy ?

Przed chwilą zadałem pytanie na serwerze Springera (chyba wiesz co tojest Springer?).
Wprowadziłem jednen wyraz "agile". Otrzymałem ponad 10 tysiecy wyników...

Zasady agile:
http://agilemanifesto.org/principles.html

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Mi się wydaje, że klient wolałby odbierać system raz - kompletny.
Tzn. to by była sytuacja optymalna, klient nie tracił by czasu na obsługę (testowanie?) półproduktu.

Jak widać czas klienta nie jest czymś z czym Agile się liczy.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Dokonywanie zmian w wymaganiach systemu na późnym etapie jego realizacji może spowodować bardzo poważne problemy i dlatego należy czegoś takiego unikać.

Dobra metodyka powinna ilość takich zmian minimalizować a "welcomować".
To jest "rozwiązywanie" problemów poprzez ich ignorowanie.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Dlaczego nie raz ?

Business people and developers must work
together daily throughout the project.

MUST ? O rly ?
Dlaczego musi ?

W żadnej innej dziedzinie inżynierii biznes nie musi codziennie wspólnie pracować z wykonawcami.
Dobra metodyka powinna czas klienta oszczędzać a nie nim "szastać".

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Co jest najważniejszą cechą pracowników ? Kompetencje ? Nie - motywacja.
Ale tak sądzą tylko Ci którzy sami ich (kompetencji) nie posiadają. Tacy ludzie rzeczywiście zamiast pracą zespołu kierować (i wziąć odpowiedzialność za efekt) mogą tylko mu (zespołowi) "zaufać".

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

O rly ?
IT to chyba rzeczywiście jakaś wyjątkowa dziedzina inżynierii ponieważ w żadnej innej projektant nie musi "rozmawiać" z wykonawcą a mimo to wciąż jest efektywnie.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Co to w ogóle jest "sustainable development" ? :)

Continuous attention to technical excellence
and good design enhances agility.

Zwinność czego ? :)

Simplicity--the art of maximizing the amount
of work not done--is essential.

? :)
What ???

The best architectures, requirements, and designs
emerge from self-organizing teams.

Jak ktoś nie wie jak zorganizować zespół (wymagane kompetencje) no to niestety zespół organizuje się sam.

Znowu - "rozwiązywanie" problemu przez uznanie go za "dobrą praktykę".

W kontekście powyższego: co "mądrego" można znaleźć w tych publikacjach skoro same zasady Agile są po prostu bezsensu.

Ale drugi niemniej lepszy być może bardziej by ci pasował:

może i bardziej ale wciąż nie jest zainteresowany żadną z pozycji :)

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

Jakub Wojt:
...

Może w języku polskim nabiorą większego sensu ;)?: http://agilemanifesto.org/iso/pl/principles.html

Najważniejsze dla nas jest zadowolenie Klienta
wynikające z wcześnie rozpoczętego i ciągłego dostarczania
wartościowego oprogramowania.

Bądź otwarty na zmieniające się wymagania
nawet na zaawansowanym etapie projektu.
Zwinne procesy wykorzystują zmiany
dla uzyskania przewagi konkurencyjnej Klienta.

Często dostarczaj działające oprogramowanie
od kilku tygodni do paru miesięcy,
im krócej tym lepiej z preferencją krótszych terminów.

Współpraca między ludźmi biznesu i programistami
musi odbywać się codziennie w trakcie trwania projektu.

Twórz projekty wokół zmotywowanych osób.
Daj im środowisko i wsparcie,
którego potrzebują i ufaj im, ze wykonają swoją pracę.

Najwydajniejszym i najskuteczniejszym
sposobem przekazywania informacji do
i ramach zespołu jest rozmowa twarzą w twarz

Podstawową i najważniejszą miarą postępu jest działające oprogramowanie.

Zwinne procesy tworzą środowisko do równomiernego
rozwijania oprogramowania. Równomierne tempo
powinno być nieustannie utrzymywane poprzez sponsorów,
programistów oraz użytkowników.

Poprzez ciągłe skupienie na technicznej doskonałości
i dobremu zaprojektowaniu oprogramowania zwiększa zwinność.

Prostota – sztuka maksymalizacji pracy niewykonanej – jest zasadnicza.

Najlepsze architektury, wymagania
i projekty powstają w samoorganizujących się zespołach.

W regularnych odstępach czasu zespół
zastanawia się jak poprawić swoją efektywność,
dostosowuje lub zmienia swoje zachowanie.

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

Jakub Wojt:
...

Porównajmy te zasady do najnowszej edycji PRINCE2 :)

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Mi się wydaje, że klient wolałby odbierać system raz - kompletny.
Tzn. to by była sytuacja optymalna, klient nie tracił by czasu na obsługę (testowanie?) półproduktu.

Jak widać czas klienta nie jest czymś z czym Agile się liczy.

PRINCE2:2009: pryncypia Zarządzanie Etapowe. Etapy wyznaczamy nie dłuższe niż miesiąc-dwa. Kazdy etap kończy się odbiorem Grupy Zadań i weryfikacją Uzasadnienia Biznesowego.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Dokonywanie zmian w wymaganiach systemu na późnym etapie jego realizacji może spowodować bardzo poważne problemy i dlatego należy czegoś takiego unikać.
Dobra metodyka powinna ilość takich zmian minimalizować a "welcomować".
To jest "rozwiązywanie" problemów poprzez ich ignorowanie.

PRINCE2:2009: w przypadku zmiany otoczenia biznesowego powstaje Plan Nadzwyczajny oraz ponowna ocena DIP, w szczególności Uzasadnienia Biznesowego. Jeśli projekt nadal jest zasadny obowiązuje Plan Nadzwyczajny.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Dlaczego nie raz ?

PRINCE2:2009: pryncypia Zarządzanie Etapowe. Po to by szybko się zorientować jesli wystapią problemy w projekcie.

Business people and developers must work
together daily throughout the project.

MUST ? O rly ?
Dlaczego musi ?
W żadnej innej dziedzinie inżynierii biznes nie musi codziennie wspólnie pracować z wykonawcami.
Dobra metodyka powinna czas klienta oszczędzać a nie nim "szastać".

PRINCE2:2009: temat Organizacja. Po to by wyznaczyć role i obowiązki w projekcie. Zarzadzanie jest procesem ciągłym jak i zarządzanie ryzykiem. Brak komunikacji może położyć każdy projekt. Po to na odpowiednim poziomie organizacji następują komunikacja by móc zarządzać projektem.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Co jest najważniejszą cechą pracowników ? Kompetencje ? Nie - motywacja.
Ale tak sądzą tylko Ci którzy sami ich (kompetencji) nie posiadają. Tacy ludzie rzeczywiście zamiast pracą zespołu kierować (i wziąć odpowiedzialność za efekt) mogą tylko mu (zespołowi) "zaufać".

PRINCE2:2009: podczas wyznaczania rół i obowiązków trzeba wyznaczać odpowiednio zmotywowanych ludzi żywotnie zainteresowanych powodzeniem projektu.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

O rly ?
IT to chyba rzeczywiście jakaś wyjątkowa dziedzina inżynierii ponieważ w żadnej innej projektant nie musi "rozmawiać" z wykonawcą a mimo to wciąż jest efektywnie.

PRINCE2:2009: Zebrania Komitetu Sterującego.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Co to w ogóle jest "sustainable development" ? :)

PRINCE2:2009: trzeba systematycznie mierzyć postępy projektowe. Stabilny wzrost/przyrost to podstawa.

Continuous attention to technical excellence
and good design enhances agility.

Zwinność czego ? :)

PRINCE2:2009: pryncypia Korzystania z Doświadczeń i ciągłe doskonalenie i dostosowywanie metodyki

Simplicity--the art of maximizing the amount
of work not done--is essential.

? :)
What ???

No cóż, generalna reguła oszczędności myślenia. w PRINCE2:2009: objawia się planowaniem jedynie przyszłego etapu pod koniec obecnego.

The best architectures, requirements, and designs
emerge from self-organizing teams.

Jak ktoś nie wie jak zorganizować zespół (wymagane kompetencje) no to niestety zespół organizuje się sam.

Robi się nudne :) Delegacja odpowiedzialności i zadań, tak aby nie sterować każdej robótki ręcznie na najwyższym poziomie organizacji. Też może być PRINCE2.

Znowu - "rozwiązywanie" problemu przez uznanie go za "dobrą praktykę".

W kontekście powyższego: co "mądrego" można znaleźć w tych publikacjach skoro same zasady Agile są po prostu bezsensu.

Trzeba widzieć zastosowanie, pochodzenie praktyki i sens który niesie.

Ale drugi niemniej lepszy być może bardziej by ci pasował:

może i bardziej ale wciąż nie jest zainteresowany żadną z pozycji :)

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

Aleksander Olszewski:

Jakub Wojt:
...

Może w języku polskim nabiorą większego sensu ;)?: http://agilemanifesto.org/iso/pl/principles.html
[i]

w moich oczach niestety nie nabrały :)

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

zwracam uwagę, ze Price2 czy PMI to dobre praktyki zarządzania projektami (ich jakością) a nie metodyka jakiejkolwiek inżynierii, także oprogramowania. Np. PMI jest popularne w budownictwie ale to nie znaczy, że delikwent z mega certyfikatem PMI zastąpi któregokolwiek inżyniera na budowie (dotyczy to także Price2), że o architekcie nie wspomną... Z Jakubem zgadzam się w 100%, sam tępię idiotyczne sesje JAD, spotkania codzienne z klientem itp., bo wielu moich klientów ma za sobą takie "zwinne" projekty (zmarnowany czas, i zarzucony projekt) i pierwsze czego sobie teraz nie życzą to właśnie tych częstych spotkań bo to ich koszty, im płacą za inną prace. A życzą sobie zobaczyć przydatny produkt w pierwszej iteracji a nie sto czterdziestej szóstej...

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

Jarek Żeliński:
zwracam uwagę, ze Price2 czy PMI to dobre praktyki zarządzania projektami (ich jakością) a nie metodyka jakiejkolwiek inżynierii, także oprogramowania. Np. PMI jest popularne w budownictwie ale to nie znaczy, że delikwent z mega certyfikatem PMI zastąpi któregokolwiek inżyniera na budowie (dotyczy to także Price2), że o architekcie nie wspomną... Z Jakubem zgadzam się w 100%, sam tępię idiotyczne sesje JAD, spotkania codzienne z klientem itp., bo wielu moich klientów ma za sobą takie "zwinne" projekty (zmarnowany czas, i zarzucony projekt) i pierwsze czego sobie teraz nie życzą to właśnie tych częstych spotkań bo to ich koszty, im płacą za inną prace. A życzą sobie zobaczyć przydatny produkt w pierwszej iteracji a nie sto czterdziestej szóstej...

Agile mówi tylko tyle:

Współpraca między ludźmi biznesu i programistami
musi odbywać się codziennie w trakcie trwania projektu.


Nie są to codzienne spotkania, ale dostępność klienta i decyzyjność.

W pozostałych metodykach mówi się o ciągłości procesu zarządzania projektem, ryzykiem i jakością. Czy zarządzanie ma polegać na odpaleniu projektu i jego zamknięciu?

Klient staje się coraz bardziej "dojrzały" i chce mierzyć postępy systematycznie, chce płacić transzowo, chce móc sterować projektem. Dlaczego współpraca dostawcy dostawcy z klientem miała by się odbywać na zasadzie zaślubin arabskich? Projekt jest przedsięwzięciem niepewnym i dobra komunikacja to podstawa.

Mam wrażenie, że często ludzie mylą współpracę i komunikację z ręcznym sterowaniem i całodniową posiadówką.

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

to tylko praktyka moja i nie tylko:

Aleksander Olszewski:
Agile mówi tylko tyle:

Współpraca między ludźmi biznesu i programistami
musi odbywać się codziennie w trakcie trwania projektu.


Nie są to codzienne spotkania, ale dostępność klienta i decyzyjność.

no to w końcu są codzienne czy nie? Czytam po polsku jest napisane 'codzienne"...
po drugie największym błędem projektu jest spotkanie algorytmizującego życie programisty nie mającego bladego pojęcia o zarządzaniu i marketingu z biznesem, który o strukturze oprogramowania nie ma bladego pojęcia a do tego obaj używają skrajnie różnego slangu. Takie spotkania to jest MEGA PORAŻKA.

W pozostałych metodykach mówi się o ciągłości procesu zarządzania projektem, ryzykiem i jakością. Czy zarządzanie ma polegać na odpaleniu projektu i jego zamknięciu?

z zarządzaniem projektem nie dyskutuję, dodam jednak że zarządzanie budową a projektowanie budynku to dwa światy.

Klient staje się coraz bardziej "dojrzały" i chce mierzyć postępy systematycznie, chce płacić transzowo, chce móc sterować projektem.

Dlatego dobry kompletny projekt ma strukturę komponentową i klient widzi i płaci za z góry zaplanowany produkt. Za budowę hotelu też płaci się transzami mimo tego, ze przyjmować gości można po zakończeniu inwestycji.

Dlaczego współpraca dostawcy dostawcy z klientem miała by się odbywać na zasadzie zaślubin arabskich? Projekt jest przedsięwzięciem niepewnym i dobra komunikacja to podstawa.

poziom niepewności zależy od jakości projektu produktu, brak projektu powoduje, że niepewność tego co powstanie zbliża się do 100% i wtedy faktycznie metody zwinne mają sens :) (jeden z moich klientów nazwał to wprost: to była zwinność w wywinięciu się dostawcy z odpowiedzialności za to co dostarcza, a raczej usiłuje dostarczyć).

Mam wrażenie, że często ludzie mylą współpracę i komunikację z ręcznym sterowaniem i całodniową posiadówką.

Mam wrażenie, że ludzie często mylą zarządzanie projektem z projektowaniem tego co ma powstać jako produkt projektu.Jarek Żeliński edytował(a) ten post dnia 18.05.12 o godzinie 16:29

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

Jarek Żeliński:
...

Aleksander Olszewski:
Agile mówi tylko tyle:

Współpraca między ludźmi biznesu i programistami
musi odbywać się codziennie w trakcie trwania projektu.


Nie są to codzienne spotkania, ale dostępność klienta i decyzyjność.

no to w końcu są codzienne czy nie? Czytam po polsku jest napisane 'codzienne"...

Współpraca codzienna nie jest tym samym co spotkania codzienne. Czy się mylę?

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

Aleksander Olszewski:
Współpraca codzienna nie jest tym samym co spotkania codzienne. Czy się mylę?

a jak wygląda współpraca bez poświęcenia sobie czasu?

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

Jarek Żeliński:

Aleksander Olszewski:
Współpraca codzienna nie jest tym samym co spotkania codzienne. Czy się mylę?

a jak wygląda współpraca bez poświęcenia sobie czasu?

A jak by wyglądała taka np. analiza bez współpracy i z współpracą? Zapewne w pierwszym przypadku spotkałbyś się z klientem pierwszego dnia i ostatniego dnia analizy wcelu przedstawienia produktu końcowego analizy. Lub w drugą stronę: gdybyś chciał spotkać się z klientem w trakcie analizy, a klient nie miał by czasu, a jak już to musiałby się naradzić z swoim szefem, a ten powołać komisję do spraw rozwiązania zapytania itd.

W dym drugim ujęciu uzyskujemy dostęp do klienta w trakcie całej analizy, ale nie koniecznie wcielamy go do zespołu czy sami się wcielamy w struktury firmy. Może być kontakt telefoniczny, mailowy czy skype'owy. Decyzje są podejmowane szybko (bez zbędnej zwłoki) i są wiążące.

Ta pierwsza sytuacja przypomina znaną karykaturę: macie moje pełne wsparcie... poza moim czasem, pieniędzmi, wysiłkiem i tak długo, jak nie muszę być zaangażowany.

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

Aleksander Olszewski:

(...) W dym drugim ujęciu uzyskujemy dostęp do klienta w trakcie całej analizy, ale nie koniecznie wcielamy go do zespołu czy sami się wcielamy w struktury firmy. Może być kontakt telefoniczny, mailowy czy skype'owy. Decyzje są podejmowane szybko (bez zbędnej zwłoki) i są wiążące.

Potwierdzam z doświadczenia, że nic nie zastąpi kontaktu z klientem (spotkanie, telefon, mail, ...), z decyzyjnym i kompetentnym klientem, z którym udało się porozumieć (podobny język, sposób myślenia itd.). Ale nie zawsze ma się takiego klienta. Widziałam projekty zrealizowane w 100% zgodnie z zaakceptowaną analizą i później nieprzydatne wcale albo w niewielkim zakresie. Bo nie przewidziano kontaktu z klientem, niezbędnych zmian, czy doprecyzowań. Ale też wszystko zależy od specyfiki projektu, klienta, a może od precyzji i doskonałości analizy? ...