On May 18, 4:51 pm, Michal Kleczek <k...@g...com> wrote:
> Andrzej Jarzabek wrote:
>
> > 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.

Dla mnie z kolei mało interesujące jest to, jak coś "jest
reklamowane".


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

Nie no, oczywiście, zanim zaczyna działać agile potrzebna jest jakaś
koncepcja projektu, przynajmniej co to ma być za program i komu do
czego potrzebny. Tylko że to jest całkiem realny scenariusz, że taka
koncepcja istnieje i pytanie brzmi co dalej.

> > Nieprawda. Proponuję przeczytać jakąś książkę o XP, powiedzmy
> >http://www.amazon.com/Art-Agile-Development-James-S
hore/dp/0596527675/
>
> Tej akurat nie czytalem - wystarczyly mi wypociny niejakiego Kenta Becka -

Tutaj mamy problem definicyjny: jeśli dla ciebie XP to tylko to, co
opisał Beck i trzymanie się dokładnie tego bez zmiany ani słowa, to
nie mamy o czym dyskutować - powiem tylko, że być może masz rację.

Jeśli potraktujemy XP jako szerszą rodzinę metodologii wywodzących się
i rozszerzających koncepcje Becka, to polecam jednak zapoznać się z
Shore&Warden - to bardzo dobra książka, uzupełniająca i
uszczegóławiająca wiele braków w metodologii 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.

Shore&Warden przewiduje.

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

O tym musisz spytac kogoś, kto się zna na budowaniu dróg.

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

Programistom zwykle płaci się jakieś ustalone pensje czy stawki
dzienne, nie?

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

Nie uważam, że jest be i nie wiem jaki proces ma Micxrosoft, natomiast
patrząc na to, jak radzą sobie z dostarczaniem publicznie ogłaszanych
produktów w publicznie ogłaszanych terminach, to mam mocne
podjerzenia, że jeśli wewnętrznie używają jakichś terminów i budżetów
to są one kompletną fikcją.

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

Możesz, ale plan całości projektu niewiele w tym pomoże. Jeśli z
twojego planu wynika, że połowa programistów zrobi zakontraktowany
scope w zakontraktowane 12 miesięcy, więc zwolnisz albo przeniesiesz
do innego projektu drugą połowę, to ryzykujesz, że obudzisz się z ręką
w nocniku, kiedy po 12 miesiącach zakontraktowany scope będzie
wykonany w 50%.

Jeśli natomiast chodzi o dodawanie features, to w przypadku
zamówionego programu jak ci to pomoże, skoro w umowie jest cena za to,
co w umowie? Myślisz, że z dobrego serca zleceniodawca zapłaci więcej?

W Agile robisz tak, że decydujesz ilu programistów pracuje przy
projekcie (w XP i tak masz wąski zakres) i w ramach tego cały czas
dodajesz features według tego, co klient mówi. W pewnym momencie masz
sytuację, kiedy odpowiedniu dużo features jest zaimplementowane,
jesteś "ready to release", stakeholder ogląda demo i mówi "chcę
release z taką funkcjonalnością". Potem się z nim dogaduje, czy chce
kolejną wersję, robi się planowanie co i w jakiej kolejności będzie
implementowane i jazda. Klient płaci zgodne z umową, programiści,
dzierżawa buira, prąd kosztują tyle a tyle i masz budżet.

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

Pracowałem przez kilka lat w spółkach giełdowych i według mojego
doświadczenia realia działania takich spółek nie mają nic wspólnego z
tym, co opisujesz. Posiadacze akcji nie widzą poszczególnych
projektów, dostają tylko roczne i kwartalne wyniki całej spółki, z
wyszczególnieniem tylko kilk głównych pozycji na co idą czy skąd się
bierze kasa. Zarząd (board of directors) ma jakiś tam bardzo ogólny
wgląd w działalność całości firmy, ale ni tez są bardzo daleko od
takich rzeczy jak to, jakie korzyści i terminy planowane są dla
konkretnych projektów. Decyzje podejmują tylko w grubych sprawach typu
megers and acquisitions, reorganizacja, wymiana CEO. CEO kieruje firmą
mianując kierowników regionów czy działów, w działach są zespoły które
mają swoich managerów i dopiero taki manager decyduje o tym, jakie
projekty i dlaczego ma realizowac zespół. Spokojnie może być tak, że
na podstawie jakiegoś pomysłu "takie coś możnaby sprzedać klientom"
popartego przez osoby z odpowiednim doświadczeniem i wpływami robi sie
np. dwumiesięczne viability study, w trakcie którego może być
wyprodukowane demo z zestawem features, który już wnosi jakąś wartość,
i jeśli to zostanie wdrożone i przyniesie zyski, a równocześnie będą
powstawać kolejne wersje z kolejnymi ficzersami wnoszącymi dalszą
wartość, to z punktu widzenia kierownika działu czy regionu dany
zespół będzie wygladał dobrze, a jeśli odpowiednia ilość zespołów
będzie odpowiedno szybko produkowała produkty przynoszące odpowiednio
wcześnie zyski, to dział będzie wyglądał dobrze i CEO powie
kierownikowi działu "dobra robota Stefek, powiedz, może by się dało
wprowadzić tę całą waszą 'metodologię' jako company-wide process" - a
zarząd przyklaśnie.

> >> A jakie np?
> > Np. retrospective.
> Jakis link?

Są opisane w Shore&Warden, ale są też całe książki na ten temat:
http://www.amazon.com/Agile-Retrospectives-Making-Te
ams-Great/dp/0977616649/
(przyznam że nie czytałem, bo mnie to aż na takim poziomie
szczegółowości nie interesuje, wystarczy mi to, opeiram się na tym, co
przeczytałem w Shore&Warden, gdzie jest rozdział poświęcony temu
tematowi)