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.

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

Oczywiście że próbują i odpowiadają na istotne pytania. Że nie na
wszystkie? Otóż to po nich komu, że na niektóre jednak odpowiadają i
że stosowanie tych odpowiedzi przynosi korzyści.

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

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

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

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

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.

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

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

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