Andrzej Jarzabek wrote:

> On May 18, 3:15 pm, Michal Kleczek <k...@g...com> wrote:
>> Znacznie taniej jest usiasc, pomyslec i _bez_ programowania stwierdzic,
>> ze sie nie oplaca. Taki waterfall - najpierw myslimy, potem (ewentualnie)
>> programujemy.
>
> Agile też na tym polega. Z tą różnicą, że myślenie jest timeboxowane
> na 15 minut. :)

IMHO tu lezy sedno problemu z "agile" i niekorzystnego wplywu jaki "agile"
wywiera na przemysl IT. Znam to z wlasnego doswiadczenia - klient
zafascynowany "metodykami agile" wymaga np. cotygodniowych releasow (bo sie
naczytal o krotkich iteracjach). Co wiecej - te "releasy" to musi byc
oprogramowanie produkcyjnej jakosci i kazdy "release" musi byc bogatszy w
funkcjonalnosc.
Po czym nastepuja negocjacje, bo przeciez musi byc czas na _myslenie_ - a
ten jak ostatni duren sie upiera, ze myslenie == programowanie.
Juz nie mowiac o tym, ze jak sie uwzgledni sam proces przygotowania
"releasu" i jego przetestowanie, to sie okazuje, ze ni diabla nie da sie
napisac linijki kodu, bo caly tydzien sie releasuje i testuje. A jak
probowac rownolegle miec iles tam galezi to nic sie nie robi tylko
"merguje".
Inny znowu - troche moze lepiej, bo przynajmniej nie wymaga produkcyjnej
jakosci - oczekuje ciaglego dostarczania prototypow w trakcie
przygotowywania projektu.
I ni cholery nie jestem ludzi w stanie przekonac, ze bedzie duzo taniej
zamknac paru ludzi na 1 miesiac w pokoiku z tablica i duza iloscia papieru
ale bez dostepu do komputera.
Bo na etapie projektu komputer tylko przeszkadza.

--
Michal

do góry

On May 18, 3:39 pm, Michal Kleczek <k...@g...com> wrote:
> Andrzej Jarzabek wrote:
> > On May 18, 2:19 pm, Michal Kleczek <k...@g...com> wrote:
> >> Andrzej Jarzabek wrote:.
>
> >> > A co zrobi, jeśli nie znajdzie dostawcy, który się na takie kary
> >> > zgodzi (i o którym z dużym prawdopodobieństwem da się powiedzieć, że
> >> > będzie wypłacalny)?
>
> >> Bedzie tak dlugo podnosil wynagrodzenie az:
> >> a) znajdzie sie dostawca
> >> b) stwierdzi ze sie nie oplaca i/lub znajdzie substytut
>
> > No i w praktyce substytutem będzie wzięcie ryzyka na siebie.
>
> Nie wiem jak "wziecie ryzyka" moze byc substytutem (zamiennikiem) produktu.

OK, nie zrozumieliśmy się. W takim razie:
c) bierze na siebie ryzyko

> >> Jesli chodzi o wyplacalnosc dostawcy to przyjeta praktyka jest wymog
> >> roznego rodzaju zabezpieczen finansowych. Jak dostawcy na takie nie stac,
> >> to znaczy ze jest gowniany i wspolpraca z nim jest ryzykowna. Jezeli i
> >> tak go wybieramy, to znaczy, ze stac nas na takie ryzyko.
>
> > No i tak samo jest z agile: jak je wybieramy, to znaczy, że stac nas
> > na takie ryzyko. Albo i nie stać, rzecz jasna.
>
> Tyle, ze przy "agile" nie kupujemy produktu tylko _prace_ - to tu jest
> roznica, a nie w sposobach zabezpieczania potencjalnych roszczen.

No tak, tylko że przy nie-agile kupujesz produkt, którego nie ma i być
może nigdy nie będzie. Przy agile (powiedzmy) kupujesz konkretnie
pracę polegającą na tworzeniu konkretnego produktu, który być może
powstanie, a być może nie. W obywdyu przypadkach ryzyko polega na tym,
że produkt może nie powstać, lub powstać w innej formie, niż byśmy to
chcieli. Agile proponuje metodę aktywnego zarządzania tym ryzykiem. Bo
ogólnie prawidłowość jest taka, że jeśli znajdziesz kogoś, kto się
zgodzi pokryć 100% twoich strat w oprzypadku niedostarczenia produktu
i dać 100% gwarancję, to ten ktoś również poda cenę, która pochłonie
100% oczekiwanych zysków z eksploatacji programu.


> > Tylko że wtedy ponisimy takie ryzyko, że metody moga być kosztowne i
> > czasochłonne, a minimalizacja mało efektywna.
>
> Oczywiscie. Ale i tak jest taniej niz robic produkt do momentu az juz
> bedziemy pewni, ze sie nie da.

Jeśli się faktycznie nie da. Owszem, takie właśnie jest twoje ryzyko:
zamówisz program, którego w ogóle się nie da zrobić w użytecznej
postaci i wtpoisz trochę kasy. Ale jeśli odsiejesz te propozycje,
gdzie na pierwszy rzut oka doświadczony członek zespołu od razu powie
"tego się nie da zrobić" lub chociaż "nie byłbym taki pewien, czy to
się rzeczywiście da zrobić", to jednak ryzyko tego, że się nie będzie
dało zrobić _w żadnej użytecznej postaci_ nie jest takie znowu duże.
Pomijając projekty typowo badawcze, przeszkodą w tworzeniu
oprogramowania raczej nie jest to, że czegos się obiektywnie nie da.

> >> Gdyby takich metod nie bylo to nikt by sie nie podjal budowy mostu
> >> sredniej wielkosci (bo sa to metody dotyczace zarowno IT jak i innych
> >> przedsiewziec). Te metody maja jedna rzecz wspolna - najpierw sie mysli,
> >> potem sie robi - taki waterfall.
>
> > Mosty mają swoją specyfikę, a oprogramowanie swoją. Jakby takie metody
> > można było przyłożyć do wszystkiego, to można by było mieć
> > przedsięwzięcie na zasadzie:
> > "potrzebuję wiedzieć czy P=NP" albo
> > "czy da się faktoryzować w czasie wielomianowym", albo
> > "udowodnić/obalić hipotezę Riemanna",
> >  a kiedyś jeszcze - Wielkie Twierzenie Fermata.
> > I dla każdego z tych problemów możnaby zrobić analizę i studium
> > wykonalności, które by powiedziały jaki jest wymagany budżet, ilu
> > matematyków trzeba wynająć i ile im to czasu zajmie. Uważasz, że tak
> > się da?
>
> To jest sprowadzenie ad absurdum, ktore nie ma IMO w tej dyskusji
> zastosowania, bo projekty IT w przemysle nie sa badaniami naukowymi
> (oczywiscie poza centrami badan). Podobnie jak budowa mostu nie jest
> projektem majacym na celu wynalezienie antygrawitacji by przenosic pojazdy
> ponad rzeka.

A tworzenie oprogramowania nie jest budową mostu.

> > No ale ponieważ oprócz grzęźnięcia w błocie jest milion innych
> > problemów, które spowodują, że traktor będzie bezużyteczny, i ponieważ
> > w praktyce spisując umowę zleceniodawca będzie w stanie sobie
> > wyobrazić i zawrzeć klauule najwyżej na 100 tysięcy takich powodów, to
> > pozostanie jeszcze 900 tysięcy sposobów, żeby traktor był kompletnie
> > bezużyteczny, mimo że  w 100% zgodny z umową:
> > być może będzie a być może nie będzie grzęznąć
> > silnik byc może się zatrze a byc może nie zatrze po dwóch minutach
> > pracy
> > chłodnia byc może będzie, a być może nie będzie cieknąć
> > opony być może się nie stopią, a być może się stopią w temperaturze
> > powyżej 30 stopni.
> > itd. itp.
> > Patrząc na to w ten sposób, zleceniodawca może się co najwyżej modlić
> > i liczyć na cud, że 100% zgodny z umową produkt będzie się w ogóle
> > nadawał do eksploatacji.
>
> No a jednak jak kupujesz samochod to nic takiego sie nie dzieje. Rozumiem,
> ze zanim go kupisz, to wspolpracujesz z dealerem na zasadzie "agile".

A mówimy o kupowaniu seryjnie produkowanych samochodów, czy zleceniu
wykonania unikatowego egzemplarza pod moje wymagania? Bo tego drugiego
nigdy nie robiłem. A jeśli chodzi o to pierwsze, to jak kupuję np.
program do obróbki video i mam do wyboru dwa, jeden robiony metodą
agile a drugi waterfall, to też nie jest tak, że w pierwszym przypadku
zgodze się płacić co miesiąc, po dwóch miesiącach dostanę wersję którą
będę mógł robic jakąkolwiek obróbkę, a potem mój przedstawiciel będzie
mówił programistom co bym jeszcze chciał, a w drugim przypadku napisze
listę czego bym chciał, a za miesiąc mi powiedzą ile muszę zapłacić i
za ile dostanę program. Raczej w obydwu przypadkach sprzedawca sięgnie
na półkę i poda mi pudełko - kompletnie bez różnicy, czy wezmę ten
agile czy nie agile.

> > Ale to jest przecież nieprawda. Agile (np. XP) zakłada, że
> > zleceniodawca wyśle swojego speca od traktorów żeby siedział z
> > zespołem projektującym traktor i z jednej strony mówił projektantom,
> > że to jest jednak bardzo wazna sprawa, żeby traktor nie grzęzł w
> > błocie.
>
> No to albo klient powie o jakims wymaganiu albo nie powie - sugerujesz ze
> "agile" jakos magicznie wplywa na klienta, ze powie?

Nie powie o wszystkich wymaganiach na początku, przy zawieraniu umowy,
bo o wszystkich się nie da powiedzieć.

Natomiast jak robisz agile i pokazujesz mu projekt albo prototyp,
który jakiegoś konkretnego wymagania nie spełnia, to jest spora
szansa, że na jakimś etapie klient to zauwazy i powie.

> > Zakłada, że po dwóch tygodniach będzie demo, gdzie zamawiający
> > będzie mógł zobaczyć pierwszy prototyp i spytać "a po błocie to to
> > pojedzie"?
>
> Nie rozumiem po co klient ma placic za stworzenie demo traktora tylko po to,
> zeby powiedziec, ze traktor ma jezdzic po blocie. Taniej by bylo po prostu
> sie zastanowic po co nam ten traktor i jak go bedziemy uzywac.

Pewnie, że taniej i pewnie, że to trzeba i tak zrobić. Problem tylko
taki, że samo zastanownienie się w żaden sposób nie zapobiegnie przed
dostarczeniem przez wykonawcę traktora, który grzęźnie w błocie.

> >> Normalni ludzie, jak nie sa pewni czego chca to robia _prototyp_ (lub
> >> serie prototypow). Ale nikt nie wymaga (w odroznieniu od agile), zeby
> >> prototyp byl w pelni funkcjonalny - bo po co za to placic? (zreszta to
> >> juz wtedy nie jest prototyp).
>
> > Ale cały development oprogramowania, to tworzenie prototypów.
>
> To jest wlasnie teza propagowana przez zwolennikow "agile". Ja sie z nia nie
> zgadzam - i _nigdy_ nie wdrazam produkcyjnie prototypu (podobnie jak nie
> kupuje prototypu samochodu, zeby jechac nim na wakacje).

Przecież zanim ten model samochodu, którym jedziesz na wakacje, został
wdrożony do produkcji, to producent zbudował prototyp nie różniący się
niczym od modelu seryjnego. Tutaj analogią stakeholdera nie jesteś ty,
tylko kierownictwo firmy produkującej samochód zlecające nowy model w
biurze projektowym.

Poza tym cała analogia samochodowa jest bzdurna.

do góry

W dniu 18.05.2011 18:05, Michal Kleczek pisze:
> Andrzej Jarzabek wrote:
>
>> On May 18, 4:00 pm, Michal Kleczek<k...@g...com> wrote:
>>> Andrzej Jarzabek wrote:
>>>> On May 18, 11:06 am, Michal Kleczek<k...@g...com> wrote:
>>>
>>>>> 1) najbardziej prawdopodobne jest to, ze XP/Agile stosuje sie w
>>>>> projektach o tak malym znaczeniu i koszcie, ze tak naprawde wszystko
>>>>> jedno jak sie to robi, zas zarzadzanie mozna powierzyc jakiemus
>>>>> matolowi bo nawet jak spieprzy to nic nie nie stanie
>>>
>>> [snip]
>>>> Jeśli natomiast mówimy o "skończeniu" w sensie dostarczenia pierwszej
>>>> wersji produkcyjnej dla klienta, to właśnie przecież jedną z koncepcji
>>>> około-agile jest to, żeby "skończyć" jak najszybciej: zamiast w
>>>> pierwszym kroku identyfikować wszystko, co klient chce mieć i wpisać
>>>> to do wymagań i dalej planować development tak, żeby w miarę
>>>> możliwości wszystkie wymagania dostarczyć w wersji 1.0, to starać się
>>>> zidentyfikować minimalny zestaw funkcjonalności, przy której produkt
>>>> jest w ogóle użyteczny dla klienta, i starać się zrobić wersję 1.0 z
>>>> taką funkcjonalnością, ale za to w dwa miesiące.
>>>
>>> To tylko potwierdza moja teze - jezeli daje sie w dwa miesiace zrobic
>>> _uzyteczne_ (w sensie gotowe do wdrozenia produkcyjnego) oprogramowanie,
>>> to oznacza tylko tyle, ze to oprogramowanie jest po prostu trywialne.
>>
>> Można to też ująć w ten sposób, że prawie zawsze złożone
>> oprogramowanie ma w sobie "trywialny" ale już użyteczny, choćby w
>> minimalnym stopniu, rdzeń.
>>
>
> Dajmy na to taki RDBMS
Parser zapytań+storage. Bez constraint, optymalizacji zapytań, etc.


> albo OS - jaki jest ten trywialny ale juz uzyteczny
> rdzen,
Bootowanie, scheduler, ładowanie modułów.

> ktory daje sie zrobic w dwa miesiace w wersji nadajacej sie do
> produkcji?
Co to znaczy "nadającej się do produkcji"?


> Nawet - przykladowo - glupi programik do wypelniania PIT nie ma takiego
> "rdzenia", bo - mimo ze koncepcyjnie prosty - nadaje sie do sprzedazy
> dopiero jak jest dopracowany w szczegolach (co zajmuje czas) - inaczej firma
> moze stracic tzw "dobre imie" co sie przeklada na przyszle przychody.
Ale nadaje się do przetestowania usability już w momencie utworzenia
GUI. Potem jako kolejne przyrosty będzie można zrobić obsługę kolejnych
pitów.

>
>> Oczywiście cel posiadania wersji gotowej do releasowania w ciągu dwóch
>> miesięcy nie jest taki, żeby po dwóch miesiącach produkt wypuścić do
>> produkcji, tylko żeby od tego momentu być gotowym do zrobienia release
>> w dowolnym momencie.
>
> Niespecjalnie widze roznice (chyba ze "zrobienie release" jest czyms innym
> niz "wypuszczenie do produkcji" - jezeli tak, to tylko przesuwamy problem).
>
Masz "core". Zleceniodawca sprawdza i stwierdza "ok, dojdą klucze
podstawowe"/"obsługa systemu plików" i możemy zacząć tego używać. A wy w
tym czasie będziecie robić klucze obce/obsługę sieci.

--
Pozdrawiam
Michoo

do góry

Michoo wrote:

> W dniu 18.05.2011 18:05, Michal Kleczek pisze:
>> Andrzej Jarzabek wrote:
>>>
>>> Można to też ująć w ten sposób, że prawie zawsze złożone
>>> oprogramowanie ma w sobie "trywialny" ale już użyteczny, choćby w
>>> minimalnym stopniu, rdzeń.
>>>
>>
>> Dajmy na to taki RDBMS
> Parser zapytań+storage. Bez constraint, optymalizacji zapytań, etc.
>
>
>> albo OS - jaki jest ten trywialny ale juz uzyteczny
>> rdzen,
> Bootowanie, scheduler, ładowanie modułów.
>
>> ktory daje sie zrobic w dwa miesiace w wersji nadajacej sie do
>> produkcji?
> Co to znaczy "nadającej się do produkcji"?

To taki, zeby mogl byc wykorzystywany produkcyjnie (uzyteczny dla
uzytkownikow koncowych) - to jest to, co postuluje "agile".
Zycze powodzenia ze zrobieniem powyzszych w 2 mies. (zreszta one nawet w
zalozeniach nie spelniaja warunku uzytecznosci, bo gdzies mi tu brakuje
jakiegokolwiek interfejsu uzytkownika)

>
>
>> Nawet - przykladowo - glupi programik do wypelniania PIT nie ma takiego
>> "rdzenia", bo - mimo ze koncepcyjnie prosty - nadaje sie do sprzedazy
>> dopiero jak jest dopracowany w szczegolach (co zajmuje czas) - inaczej
>> firma moze stracic tzw "dobre imie" co sie przeklada na przyszle
>> przychody.
> Ale nadaje się do przetestowania usability już w momencie utworzenia
> GUI. Potem jako kolejne przyrosty będzie można zrobić obsługę kolejnych
> pitów.

Ale sie nie nadaje do uzycia produkcyjnego (co jest postulowane przez
"agile").
Do testowania "usability" nie potrzeba zadnego "agile" - wystarczy wyklikac
_prototyp_ w jakims VB czy innym narzedziu RAD nie przejmujac sie tym, co
jest "pod spodem" bo prototyp z zalozenia idzie do kosza. Tak jest po prostu
taniej, bo mozna to zrobic w pare godzin.
Oczywiscie rownolegle mozna robic to co "pod spodem" - ale do tego jest
potrzebny (hint) projekt, ktory wyspecyfikuje, ze w ogole dzielimy
oprogramowanie na UI i "pod spodem" oraz powie nam co to wlasciwie znaczy
"podzielic" i jak ten podzial przebiega.
Taki projekt robi sie _zanim_ zacznie sie programowac - taki waterfall:
najpierw myslimy, potem programujemy.

--
Michal

do góry

W dniu 2011-05-18 14:44, Andrzej Jarzabek pisze:

> A co zrobi, jeśli nie znajdzie dostawcy, który się na takie kary
> zgodzi (i o którym z dużym prawdopodobieństwem da się powiedzieć, że

Każda umowa ma określone konsekwencje w przypadku jej niewypełnienia. To
czy będą one w niej zapisany, czy wynikną z kodeksu to inna sprawa.
Zawsze istnieje odpowiedzialność sprzedawcy / producenta za wytworzony
produkt.

> będzie wypłacalny)? Powszechnie wiadomo, ż projekty informatyczne
> często mają opóźnienia i że warunki są często renegocjowane. Wykonawcy

Źle zarządzanie projekty.

> oprogramowania, zwłaszcza jeśli mowa o dużych firmach, raczej nie będą
> chętne do brania na siebie ryzyka gigantycznych strat w przypadku
> kiedy okaże się, że czegośtam w praktyce nie da się zaimplementować.

Nigdy, nawet w czasach gdy pisałem samodzielnie oprogramowanie na
zlecenie nie podjąłbym się go bez uprzedniej analizy wymagań oraz
określenia wykonalności. Kurcze - przecież to są podstawy, na ich
podstawie można oszacować czas trwania projektu oraz jego wartość.
Przecież nikt w umowie nie wpisze wartości roboczogodziny tym bardziej
jeśli nie ustali się czasu potrzebnego na realizację projektów. Aż tak
naiwnych klientów nie ma.

> Analogią raczej byłoby zamówienie stworzenia nowego modelu traktora.
> Firma potrzebuje nowy model traktora, który będzie maił jakiś
> specjalny ficzer, i dostaje taki model, tylko że po dostarczeniu
> okazuje się, że ten model grzęźnie w błocie i jako taki jest
> bezużyteczny. Wykonawca twierdzi, że dostarczony prototyp spełnia
> wszystkie warunki zapisane w umowie, a jak zleceniodawca chce taki,
> który nie grzęźnie, to on chętnie podpisze kolejną umowę na wersję
> 2.0, tylko że będzie to kosztowało 50 milionów i zajmie kolejne dwa
> lata.

Po pierwsze jeśli chodzi o traktory to z zasady grzęzną w błocie. Od
niegrzęźnięcia są albo opony bliźniaki albo traktory na gąsienicach.
Pomijam, że wymagana jest także odpowiednia moc (ponad standardowa)
silnika. Ale za to wszystko się dopłaca.
Tak samo jakbyś miał pretensje do sprzedawcy samochodu, że osobówka
(typowy sedan) nie jest w stanie jeździć po zaoranym polu. Przecież
powinien. Ba nawet w ofercie nigdzie nie było informacji że tego nie
potrafi.
Reasumując, dla traktora nie jest typowym jeżdżenie po błocie (takim w
którym można ugrzęznąć), więc takie wymaganie o ile miałoby być
zrealizowane, musiało by być jasno opisane.
Co więcej, analityk w trakcie pracy z klientem bez problemu by to
wyłapał, przy wizycie na tym błotnistym polu. A mając takie wymaganie,
wytwórca mógłby przed przystąpieniem do realizacji zlecenia określić czy
w ogóle jest w stanie coś takiego wykonać.

pozdrawiam,
Przemek O.

do góry

On Wed, 18 May 2011 17:26:02 +0200, Michal Kleczek <k...@g...com>
wrote:

>R. P. wrote:
>
>> A.L. wrote:
>>> To tak jakby zaczac budowanei domu od sprowadzenia ciezarowki z
>>> betonem i "Wacek, lejmy beton! Co tam projekt, niepotzrebne odkuje sie
>>> potem!"
>>
>> W PL wlasnie tak sie buduje ;)
>
>Ale ideologia "agile" to USA pochodzi...


Niestety

A.L.

do góry

On Wed, 18 May 2011 08:40:08 -0700 (PDT), Andrzej Jarzabek
<a...@g...com> wrote:

>On
>Oczywiście cel posiadania wersji gotowej do releasowania w ciągu dwóch
>miesięcy nie jest taki, żeby po dwóch miesiącach produkt wypuścić do
>produkcji, tylko żeby od tego momentu być gotowym do zrobienia release
>w dowolnym momencie. Od tego memntu masz możliwość ustalania, które
>konkretnie dodatkowe ficzery implementować w jakiej kolejności tak,
>żeby użytecznośc produktu rosła jak najszybciej, żeby stakeholder mógł
>w pewnym momencie powiedzieć "to skoro mamy już killer ficzer A,
>chociaż nie mamy jeszcze B i C, które też by mi się przydały, to
>jednak bym chciał wdrożyć już produkt z A a bez B i C, bo już mogę na
>tym zacząć zarabiać. To kiedy mogę dostać wersję 1.0?" i usłyszeć
>odpowiedź "za 2 tygodnie".


Drogi Kolego, s pisania Kolegi wnosze ze Kolaga jest na trzecim
semestrze informatyki, a software pzremyslowego nie mowiac o jego
prdukcji, nei widzial nawet pzrez szybe.

A.L.

do góry

W dniu 2011-05-17 23:20, Andrzej Jarzabek pisze:
> On 17/05/2011 18:49, Przemek O. wrote:
>> W dniu 2011-05-17 18:53, Andrzej Jarzabek pisze:
>>
>> Dokumentacja jest potrzebna zawsze przy dużych projektach.
>
> Z mojego doświadczenia wynika, że bieżąca dokumentacja w dużych
> projektach jest bardzo często mocno niekompletna,

Kierownik projektu - dupa.

nieaktualna,

j.w.

> a koszt jej utrzymania przewyższa korzyści jakie przynosi.

To nie jest prawdą. Koszt utrzymania przy wykorzystaniu automatów
dokumentujących jest niewielki (zarówno czasowy jak i kwotowy). Tylko
trzeba mieć dobry i sumienny zespół który wie co robi.

> W skrócie - niepotrzebna.

To już bujda na resorach. Jeśli nigdy nie była Ci potrzebna, to masz
szczęście.

> Ktoś siedzi rok w projekcie i go nie zna? Chyba żartujesz.

Ktoś kto siedzi rok w projekcie razem z kilkoma innymi programistami ma
prawo nie pamiętać implementacji wszystkiego co zrobił na początku, lub
tym bardziej co ktoś inny zrobił.

> Po pierwsze, po to masz coding standards, żeby nie było.
> Po drugie, w praktyce zespół, który pracuje nad kodem od roku ma o nim
> lepszą wiedzę, niż jest zawarta w dokumentacji. Jeśli praktykujesz
> shared ownership, to masz sporą szansę na to, że dany programista będzie
> sam znał odpowiedź. A jeśli nie, to praktykując kolokalizację zespołu,
> łatwo jest mu po prostu zapytać i dostać odpowiedź. A jeśli utknie, to
> po to masz daily standup, żeby ci, co wiedzą, mogli się zgłosić do pomocy.

Teoria... piękna. W praktyce to tak nie działa.

> Ja mówię o tym, co w waterfallu jest tworzone w design phase. Wymagań i
> analizy do tego nie wliczam.

Tylko że to powstaje na ich podstawie. Z ogólnych bajek zleceniodawcy
oprogramowanie się nie zmaterializuje. A i umowę wypadałoby podpisać na
coś konkretnego, a nie na wyimaginowaną możliwość otrzymania być może
czegoś co potrzebuje w bliżej nieokreślonym terminie.

>> Yea! Right! Jak już pisałem to się sprawdzi przy pisaniu notatnika.
> A jednak całkiem spore programy się w ten sposób robi.

A bo ja wiem, nie spotkałem się jeszcze z dużym projektem tworzonym w
całości z uwzględnieniem Agile. Częściowo tak, w całości nie. Ale może
pracuje w dziedzinach gdzie z założenia nie można sobie na to pozwolić.

> Tu trochę przyznam, że wychodzę poza swoje kompetencje, ale o ile
> rozumiem, to przede wszystkim XP pomyślanie jest nie pod kątem
> projektów, które się w pewnym momencie zdaje i zamyka, tylko raczej do
> takich, które w pewnym (wczesnym) momencie mają pierwszy release, a
> potem regularni i dość często kolejne release'y, np. co miesiąc albo co
> dwa miesiące.

To co opisujesz, to bardziej mi pasuje do starej definicji
prototypowania z ominięciem najważniejszej części, że prototypu nie
wdraża się produkcyjnie.

> I jeśli to jest zewnętrznie zlecony projekt, to - na ile się orientuję -
> preferuje się umowy sformułowane tak, że dopóki zleceniodawca płaci, to
> dostaje kolejne wersja - z jakimiś tam zabezpieczeniami dla obydwu stron.
>
> Jeśli się nie da, a decyduje się na XP, to się zakłada, że kontrakt
> będzie renegocjowany po zawarciu, że zlecenidawca będzie skłonny do
> zmiany kontraktu jak zobaczy, że dostaje w pierwszej kolejności to,
> czego najbardziej potrzebuje i że będzie miał szybko funkcjonalny
> produkt. Wtedy odpowiednie role w zespole osłaniają przed tym programistów.

Nie rozumiem. Patrzę teraz z perspektywy przedsiębiorcy. Mnie interesuje
na kiedy mogę mieć produkt i ile za niego mam zapłacić. Średnio mnie
interesuje czy dostanę jakiś kawałek wcześniej czy później. Ważna jest
data wdrożenia całości.
Przykład z życia. Właśnie będą mi kłaść kostkę na posesji. Rozmawiałem z
kilkoma firmami i ważne dla mnie jest cena i termin wykonania. Jeśli
mieliby to robić 'agile' to po położeniu iluś metrów dopiero bym
sprawdzał czy dobrą kostkę kładą, czy kolor mi pasuje itd itp. Dostałbym
prototyp działający (no bo jest kostka, jest położona i można bo niej
chodzić). Szkoda tylko, że nie pasuje mi jej grubość, kolor i wzór. I
teraz to rozbierają i robią zgodnie z moimi sugestiami. Oczywiście po
drodze może się okazać że wzór nie do końca jest taki jak chciałem (tzn
początek był dobry, ale rozwinięcie złe). Następna poprawka, a płace im
od metra. Po położeniu okazało się że nie zrobili odwodnień, bo myśleli
że ich nie potrzebuje i znowu poprawka.
W tym momencie pomimo że mam 350m2 kostki do położenia zapłacę im za
położenie jakiegoś 1tyś m2.
A wystarczyło zrobić na początku analizę, spytać co po tym będzie
jeździć, zaproponować wzór, kolor itd itp. Jeden projekt, jedno
wykonanie i płaca za faktyczny metraż i brak straconego czasu.
I tylko pozornie nie ma to związku z tworzeniem oprogramowania.


> No i oczywiście niektóre projekty są wewnętrzne, więc nie ma całego tego
> krapu.

To całkiem inna bajka. Jeśli ktoś choć raz pisał projekt wewnętrzny to
dobrze o tym wie.

> Powieem ci tak: mylisz się.

No to moment, macie tych analityków i projektantów w zespole czy nie?

> Nie wiem, może pracujesz w jakiejś specyficznej branży, albo
> specyficznej kulturze, w której waterfall się sprawdza, ale consensus
> jest jednak taki, że nie sprawdza się prawie nigdy.

Żartujesz chyba, przez tyle lat się sprawdzał i nagle przestał? Fakt mam
specyficzną branżę, wymagającą dużego nadzoru i certyfikowania
oprogramowania. I jedno powiem, jeśli chcesz mieć oprogramowanie
certyfikowane, to nie przejdzie brak projektu, analizy czy dokumentacji
kodu.

> Ja też pracowałem z analitykami, wydaje mi się, że dość dobrymi, ale
> zawsze było tak, że dokumenty, które wyprodukowali trzeba było mocno
> modyfikować w trakcie developmentu. I komunikacja, a nie dokumentacja,
> była kluczowa dla skuteczności realizacji _rzeczywistych_ wymagań.

Ale komunikacja zawsze jest istotna. Tyle że analityk musi znać zarówno
specyfikę branży dla której pisze się oprogramowanie, jak i możliwości
zespołu. Z mojej strony mogę jedynie zauważyć, że o ile modyfikacja
wymagań (z zasady ich doprecyzowanie) ma miejsce, jednak wyłapywane to
jest na etapie tworzenia projektu aplikacji a nie w fazie kodowania.
Zmiany w fazie projektowania są dużo mniej kosztowne niż w fazie kodowania.

pozdrawiam,
Przemek O.

do góry

Andrzej Jarzabek wrote:

> Te pomysły to przede wszystkim położenie nacisku na bezpośrednią
> komunikację, np. że raczej warto włozyć wysiłek w to, żeby z zespołem
> siedział ktoś dobrze rozumiejący dziedzinę, niż żeby ktoś taki
> przygotował szczegółową dokumentację.

Tylko że jeśli człowiek znający dziedzinę pójdzie na urlop, bądź jest chory,
to z jego pomocy się nie skorzysta. Natomiast ze stworzonej dokumentacji -
tak.

do góry

W dniu 2011-05-18 23:06, Wojciech Jaczewski pisze:
> Andrzej Jarzabek wrote:
>
>> Te pomysły to przede wszystkim położenie nacisku na bezpośrednią
>> komunikację, np. że raczej warto włozyć wysiłek w to, żeby z zespołem
>> siedział ktoś dobrze rozumiejący dziedzinę, niż żeby ktoś taki
>> przygotował szczegółową dokumentację.
>
> Tylko że jeśli człowiek znający dziedzinę pójdzie na urlop, bądź jest chory,
> to z jego pomocy się nie skorzysta. Natomiast ze stworzonej dokumentacji -
> tak.

Zgadzam się. Z dokumentacją są niestety dwa problemy, które powodują,
dobra dokumentacja jest bardzo droga:
- nie wiadomo, o co będzie chciał zapytać ktoś proszący o pomoc,
dlatego trzeba opisać każdy szczegół
- im bardziej szczegółowa dokumentacja, tym szybciej się dezaktualizuje

Obstawiałbym, że średnio tańszy jest shared ownership. Ale nie neguję
podstawowej tezy - dokumentacja się przydaje. Tyle, że nie jest celem
projektu (zwykle), a jedynie narzędziem.

--
Paweł Kierski
n...@p...net

do góry