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

do góry

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.

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

>
>> > Powszechnie wiadomo, ż projekty informatyczne
>> > często mają opóźnienia i że warunki są często renegocjowane. Wykonawcy
>> > 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ć.
>>
>> Dlatego tez istnieje cos takiego jak analiza wymagan, studium
>> wykonalnosci i inne metody pozwalajace zminimalizowac ryzyko wystapienia
>> takiego przypadku.
>
> 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.

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

[ciach]
>> Jezeli klient nie wyartykuuje, ze traktor ma jezdzic
>> po blocie i w nim nie grzeznac, to dostanie traktor, ktory byc moze
>> bedzie, a byc moze nie bedzie grzeznac.
>
> 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".

>> Sek w tym, ze metody "agile" zakladaja, ze
>> najpierw nalezy zrobic w pelni funkcjonalny traktor i za niego zaplacic,
>> a potem zobaczyc czy sie nada.
>
> 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?

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

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

--
Michal

do góry

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.

--
Michal

do góry

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.

do góry

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

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

W dwa meisiace to sie mozna podrapac w glowe.

W dwa meisiace to student nie dokonczy programu studenckiego.

"Agile" a wczesniej "extreme programming" to "metodologie" dla
kretynow i neiudacznikow z przemyslu ktorzy nie wiedza jak porzadnei
zorganizowac prace, jak robic specyfikacje projektowe, jak
przetsrzegac tych specyfikacji, jak robic testowanie i potem jak robic
dokumentacje.

To tak jakby zaczac budowanei domu od sprowadzenia ciezarowki z
betonem i "Wacek, lejmy beton! Co tam projekt, niepotzrebne odkuje sie
potem!"

A.L.

do góry

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

do góry

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

--
Michal

do góry

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

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

do góry

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

do góry

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 albo OS - jaki jest ten trywialny ale juz uzyteczny
rdzen, ktory daje sie zrobic w dwa miesiace w wersji nadajacej sie 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.

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

--
Michal

do góry