Andrzej Jarzabek wrote:

> On May 18, 3:15 pm, Michal Kleczek <k...@g...com> wrote:
>> Andrzej Jarzabek wrote:
>> > On May 18, 1:55 pm, Michal Kleczek <k...@g...com> wrote:
>>
>> > 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.
>
> No więc właśnie to bzdura, bo nic takiego nie wynika. Jeśli kopiesz
> rowy koparką, ale w ramach kopania rowów masz też etap gdzie
> decydujesz czy i gdzie kopać, i do decydowania o tym koparki nie
> używasz, to nie znaczy, że ta cała koparka jest bezuzyteczna, bo
> przecież jej i tak "naprawdę" nie używasz.

To oznacza tylko tyle, ze ta "koparka" jest malo wazna/interesujaca z punktu
widzenia calosci przedsiewziecia. Reklamowanie jej jako panaceum (a tak jest
reklamowane "agile") na cokolwiek jest albo glupota albo oszustwem.

[ciach]
>
>> >> 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.
>
> To jest pytanie interesujące dla kogoś, kto decyduje jakie metody/
> procesy stosować dla jakich projektów. Samo pytanie jest przecież
> zależne od szczegółów projektu.
>

Tyle ze zanim zadamy to pytanie, to trzeba np. okreslic wielkosc projektu i
wielkosc potrzebnego zespolu. Zeby to zrobic trzeba wykonac jakies czynnosci
(hint: analiza wymagan i projekt - w kazdym razie wstepny 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-Orien
ted-Systems-Models-
>> Patterns/dp/0201809389
>
> Załóżmy, że przynajmniej na razie jej nie przeczytam. Możesz jakoś bez
> tego rozwinąć swoje "e tam"?
>
>> XP do testowania sie ma tyle, ze mowi "trzeba testowac".
>
> Nieprawda. Proponuję przeczytać jakąś książkę o XP, powiedzmy
> http://www.amazon.com/Art-Agile-Development-James-Sh
ore/dp/0596527675/
>

Tej akurat nie czytalem - wystarczyly mi wypociny niejakiego Kenta Becka -
oparcie testowania (ale takze przeciez i projektu oprogramowania, ktory
zarowno wynika jak i wplywa na sposoby testowania) o automatyczne "unit
testy" i "customer testing" (jak w XP) jest po prostu liznieciem tematu.
Ksiazka (gruba jak cholera - ok 1tys stron) tak naprawde tylko ilustruje jak
szeroki on jest i ze nie ma mozliwosci organizacji procesu wytworczego bez
przewidzenia miejsca dla _specjalizowanej_ grupy/roli testerow czy tez
projektantow testow (bo przecietny programista nie ma o tym wiekszego
pojecia). Znane mi metodyki agile (fakt - tylko XP) nie przewiduja takiej
roli.

>> >> 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.
>
> To nie tak. Agile mówi, że skutecznośc długotrwałego i skrupulatnego
> planowania nie jest dużo większa niż skuteczność planowania w postaci
> półodzinnego zebrania, a za to dużo więcej kosztuje no i pochłania
> czas.

Jasne - w pol godziny mozna zaplanowac budowe nietrywialnego systemu
informatycznego. Ciekawe dlaczego nie daje sie tego zrobic z banalnym
remontem parokilometrowego odcinka drogi powiatowej.

>
>> Trzeba by rezygnowac z tworzenia wieloletnich planow
>> inwestycyjnych, budzetowania z perspektywa dluzsza niz miesiac itp.
>
> E tam. Budżetowanie i inwestowanie nie jest przecież funkcją
> dostarczenia takich czy innych ficzerów w kodzie, tylko strumieni
> przychodów i wydatków.

No ale skad sie biora wydatki? Przeciez taki zespol programistow XP to spory
koszt, ktory trzeba uwzglednic.

> Dla dostawcy oprogramowania każdy nowy projekt
> to niewspółmierne ryzyko, pieniądze robi się na ciągnięciu kasy od
> istniejących klientów za istniejące produkty. Dla większej firmy
> zawsze kalkulacja wygląda tak: "żeby się rozwijać, musimy zrobić nowy
> produkt. Zapewne na tym stracimy, ale jest szansa, że produkt odniesie
> sukces i w przyszłości zamieni się w stałe źródło zysków". Żadne
> planowanie w tym nie pomoże, bo przecież nie uwzględnisz w planowaniu
> tego, czy pomysł jest dobry, czy oprogramowanie będzie dobrej jakości
> i jak się świat zmieni w przyszłości.

Oczywiscie, ze uwzglednisz - sugerujesz, ze taki dajmy na to MS nie planuje
wydatkow, deadlinow i ficzerow w nowej wersje Windows? (tylko prosze bez
argumentu, ze Win jest be, bo to nie ma nic do rzeczy - zreszta nie jest
taki be skoro wszyscy kupuja)

>
> Oczywiście w przypadku firmy robiącej program na konkrene zamówienie,
> strumienie przychodów i wydatków zależą od podpisanych kontraktów i od
> kosztów operacyjnych, więc też się poddają łatwemu planowaniu
> niezależnie od tego, czy istnieje plan implementowania konkretnch
> features.

Oczywiscie, ze nie, bo takie podejscie zaklada, ze mamy stale koszty (w
postaci stalego zespolu) lub stale przychody (bo z grubsza za kazdy
"feature" jest dodatkowa kasa). A przeciez ludzi mozna po prostu (w
uproszczeniu) zwolnic, jak sa niepotrzebni - tym samym zmniejszajac koszty.
Lub mozna dorzucic features zwiekszajac margines zysku.

>
>> 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".
>
> Ale o czym ty mówisz? O firmie, która nie ma gotowych produktów, nie
> ma płacących klientów, ma tylko pomysł i zespół - i wchodzi na giełdę?
>

Nie - firma notowana na gieldzie musi non-stop przekonywac inwestorow, ze
jej plany inwestycyjne maja sens - w przeciwnym wypadku akcje stanieja,
posiadacze akcji straca, zdenerwuja sie i zmienia zarzad. Proste jak budowa
cepa.

>> > 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.
>
> Agile też na tym polega. Z tą różnicą, że myślenie jest timeboxowane
> na 15 minut. :)

Na to odpowiem w oddzielnym poscie, bo to (zartobliwe) ale istotne
spostrzezenie.

>
>> >> 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?
>
> Np. retrospective.

Jakis link?

--
Michal