Andrzej Jarzabek wrote:

> On May 18, 1:55 pm, Michal Kleczek <k...@g...com> wrote:
>>
>> 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?
>

Z tego wynika, ze to cale "agile" to machanie rekami i "buzzwordy" i - jak
napisalem - nikt tak naprawde ich nie stosuje (bo sie nie da) ale wszyscy o
tym mowia.
Co komu po metodykach, ktore nawet nie probuja odpowiadac na istotne pytania
dot procesu produkcji oprogramowania? (Juz pomijajac kwestie, ze odpowiedzi
na pytania, na ktore odpowiadaja sa hmm... kontrowersyjne)

>> 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?
>

Ogon macha psem.
To pytanie jest interesujace dla propagatorow agile, a nie dla kogos, kto ma
zaplanowac projekt.

>> 7) jak bedziemy zapewniac jakosc? czy potrzebujemy zakupic narzedzia /
>> sprzet / ludzi do stworzenia centrum testowego?
>
> W tej kwestii akurat XP ma sporo do powiedzenia.
>

Eee tam. Proponuje przeczytac ksiazke powiedzmy:
http://www.amazon.com/Testing-Object-Oriented-System
s-Models-
Patterns/dp/0201809389

XP do testowania sie ma tyle, ze mowi "trzeba testowac".

[ciach]
>> > 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.

"Agile" za to mowia, ze w ogole nie nalezy probowac. To nie do przyjecia o
tyle, ze wywraca do gory nogami cale doswiadczenie wielu (wszystkich?)
organizacji. Trzeba by rezygnowac z tworzenia wieloletnich planow
inwestycyjnych, budzetowania z perspektywa dluzsza niz miesiac itp.
Jak chcesz przekonac inwestorow gieldowych, ze inwestycja w oprogramowanie
ma sens, jezeli jedyne co im jestes w stanie powiedziec, to ze "wywalimy
tylko X PLN na dwa miesiace pracy zespolu i wtedy zobaczymy co dalej".

> 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.

Znacznie taniej jest usiasc, pomyslec i _bez_ programowania stwierdzic, ze
sie nie oplaca. Taki waterfall - najpierw myslimy, potem (ewentualnie)
programujemy.

>
>> 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.

A jakie np?

--
Michal