On May 18, 1:55 pm, Michal Kleczek <k...@g...com> wrote:
>
> > Gdyby tak było zawsze, to każda firma stosująca Agile by upadła. Bo
> > programiści robiliby cokolwiek bez konsekwencji lub projekty
> > prowadziłoby niekompetentne kierownictwo. A są firmy, które tego używają
> > i działają. Być może nieoptymalnie - ale jak to sprawdzisz?
>
> Tak zupelnie powaznie to mam spore watpliwosci czy sa firmy stosujace
> metodyki "agile" w _calosci_ procesu produkcji oprogramowania. Jest to po
> prostu niemozliwe, bo "metodyki agile" w ogole nie mowia o wielu istotnych
> aspektach takiego procesu, koncentrujac sie tylko na jego drobnym wycinku.
> Nie jest mozliwe stosowanie np. XP samego w sobie - wezmy przykladowo kilka
> pytan, na ktore trzeba sobie odpowiedziec projektujac system:
>
> 0) czy w ogole potrzebujemy programowac? moze wystarczy kupic produkt z
> polki? jesli tak to jaki? albo moze raczej kupic produkt(y) i go (je)
> dostosowac lub zintegrowac?
> 1) potrzebujemy, czy tez nie RDBMS (jezeli tak to jaki) - to wariant 0)
> 2) w jakim jezyku (jezykach) programowania powinnismy stworzyc system (lub
> poszczegolne podsystemy - a wczesniej - jakie podsystemy beda skladac sie na
> nasz system?)

Jeszcze zapomniałeś dodać, że procesy Agile na ogół nie określają w
jaki sposób wybiera się nazwę dla tworzonego programu.

Pomijając jednak to, to można zwrócić uwagę, że jednak pewne aspekty
tego, o czym piszesz są uwzględnione gdzie niegdzie w Agile. Na
przykład praktyka samoorganizacji zespołów mówi coś o tym, że zespół
dobiera sobie narzędzia potrzebne do realizacji zadania zgodnie ze
swoimi umiejętnościami i wiedzą. Co oczywiście do końca nie rozwiązuje
problemu, bo trzeba najpierw taki zespół dobrać i z pewnością
znajomości pewnych języków czy technologii będą kluczem.

Tylko że właściwie co z tego wynika?

> 5) jak duzy zespol potrzebujemy?

Akurat do tego agile się odnosi, tylko raczej z drugiej strony: przy
jak dużym zespole stosowanie praktyk będzie możliwe/skuteczne?

> 7) jak bedziemy zapewniac jakosc? czy potrzebujemy zakupic narzedzia /
> sprzet / ludzi do stworzenia centrum testowego?

W tej kwestii akurat XP ma sporo do powiedzenia.

> XP w ogole sie powyzszym nie zajmuje - raczej czyni niejawne zalozenie, ze
> pewne decyzje sa juz podjete, infrastruktura istnieje itd, a teraz zostaje
> juz tylko zajac sie pisaniem kodu.

No niekoniecznie, ale raczej przyjmuje założenie (sensowne IMO), że
pewnych rzeczy nie ma sensu określać w ramach metodologii towrzenia
oprogramowania, bo są głównie zależne od specyfiki projektu i różnych
innych czynników, np. instytucjonalnych. Z dugiej strony metodologie
agile jak najbardziej odnoszą się przecież do różnych kwestii
organizacyjnych poza samym pisaniem kodu, np. obecnośc customera,
organizacja miejsca i czasu pracy, interakcji między uczestnikami
projektu. Oczywista jest sprawa, ze są rzeczy, które są "out of
scope", ale nimi też często pośrednio różne metodologie zajmują się
poprzez np. definiowanie kompetencji pewnych ról.(product owner,
visionary itd.)


> > Weźmy taki Scrum. Każda iteracja to umowa na wykonanie konkretnych
> > funkcjonalności w konkretnym czasie. Selekcja funkcjonalności
> > do kolejnej iteracji opiera się - niespodzianka! - na liczeniu ROI.
> > Sortujemy po stosunku spodziewanego przyrostu wartości produktu do
> > kosztu (z góry ustalonego) czasu pracy zespołu (+ ewentualne dodatkowe
> > koszty).
>
> Tyle, ze potrzebujemy wiedzy nie na temat 1 krotkiej iteracji, lecz _calego_
> projektu, ktory planujemy. Jak mam wydac pieniadze na stworzenie produktu,
> to chcialbym - z mozliwie duza pewnoscia - moc zalozyc ile wydam i ile
> zyskam. Chociazby po to, zeby wiedziec czy w ogole mi sie oplaca zaczynac, a
> nie po prostu kupic sobie nowy samolot albo pol wyspy na Karaibach.

Tylko że alternatywy nie dają ci możliwie dużej pewności. Natomiast
krótki cykl i feedback daje orientację co do realnych postępów i
możliwość wyciągnięcia wtyczki na wczesnym etapie, zanim zbyt wiele
się utopi w projekcie.

> Wybacz, ale Agile z usprawnianiem procesu ma tyle wspolnego, ze zaklada sie,
> ze proces sie bedzie "zmienial".

Nie no, bez przesady, konkretne metodologie mają do tego konkretne
praktyki.