Tylko dla Agile developerow - Jak zwinny jest twoj zespol?
Piotr Gabryanczyk
Osobiscie przeszedlem przez kilka zespolow, ktore mialy siebie same za
agile. Za kazdym razem okazywalo sie jednak, ze kolejny zespol
stosowal jeszcze wiecej ciekawych technik agile. Kiedy np. myslalem,
ze uzycie pair-programming jest nierealne okazywalo sie, ze w
nastepnym zespole szef sam do tego zachecal. Dalo mi to wiare, ze da
sie zarzadzac projektem w ten sposob i ze sa zespoly, ktore chca i
robia to na codzien.
Ciekaw jestem jak wiele z praktyk zawartych w tej metodologii jest w
uzyciu w waszych zespolach. Pochwalcie sie, a moze inni uwierza, ze
sie da! :)
Ponizej krotka ankieta, ktorej wyniki opublikuje za kilka dni:
http://www.surveymonkey.com/s.aspx?sm=0Rc0O_2bpW6OCO_2fPe9bDIMCQ_3d_3d
Podeslijcie tego linka do wszystkich zainteresowanych, nie tylko z tej
grupy.
To pierwsza taka ankieta, wiec czekam rowniez na sugestie jak mozna ja
rozszerzyc lub zmienic.
Pozdrawiam
Piotr Gabryanczyk
A.L.
<pio...@gmail.com> wrote:
>Jesli nie jestes zainteresowany Agile Development nie czytaj dalej.
>
>Osobiscie przeszedlem przez kilka zespolow, ktore mialy siebie same za
>agile. Za kazdym razem okazywalo sie jednak, ze kolejny zespol
>stosowal jeszcze wiecej ciekawych technik agile. Kiedy np. myslalem,
>ze uzycie pair-programming jest nierealne okazywalo sie, ze w
>nastepnym zespole szef sam do tego zachecal. Dalo mi to wiare, ze da
>sie zarzadzac projektem w ten sposob i ze sa zespoly, ktore chca i
>robia to na codzien.
>
>Ciekaw jestem jak wiele z praktyk zawartych w tej metodologii jest w
>uzyciu w waszych zespolach. Pochwalcie sie, a moze inni uwierza, ze
>sie da! :)
>
Ja juz pisalem Agile, XP: to jest zboczonmy produkt chorej wyobrazni.
W szczegolnosci, cale pieprzenei o "pair programming" do smieci wloze.
To jest wymysl facetow ktorzy nigdy nic nie mieli wspolnego z
rzeczywistoscia przemyslowa, ustalaniem budzetu, najmowaniem ludzi,
ocenianiem koztow projektu i tak dale. Pair programming dober ejs tw
CHinach gdzie jest miliard kluczi i placi im sie garsc ryzu dziennie
A ankiety do swojej pracy licencjackiej przeprowadzaj gdzie indziej. I
najlepiej na inny temat.
A.L.
Michał 'Khorne' Rzechonek
> Ciekaw jestem jak wiele z praktyk zawartych w tej metodologii jest w
> uzyciu w waszych zespolach. Pochwalcie sie, a moze inni uwierza, ze
> sie da! :)
Uwierzą, że się da, a potem nie daj Boże zechcą zastosować to
w mojej pracy i będę musiał odejść. Dziękuję, postoję.
Agile i XP to nic nie znaczące "buzzwords" służące w 90% za
przykrywkę burdelu w projekcie.
--
Khorne
Seweryn Habdank-Wojewódzki
Piotr Gabryanczyk wrote:
> Jesli nie jestes zainteresowany Agile Development nie czytaj dalej.
Agile nie! Dobre developowanie tak!
> Osobiscie przeszedlem przez kilka zespolow, ktore mialy siebie same za
> agile.
Znałem i znam takie zespoły, które pracowały "agile" zanim to się
rozreklamowało i zamin poudziwniano w programowaniu wszystko co było
normalne.
> ze uzycie pair-programming jest nierealne okazywalo sie, ze w
> nastepnym zespole szef sam do tego zachecal.
Wiesz. Zadam Ci pytanie, praktyczne, kiedyś je zadałem jednej Pani
orędowniczki PP.
Jak pogodzisz programistę -- żarłoka sypiącego jedzenie na klawiaturę, z
ekranem opalcowanym i ociekającym ketchupem (bo jadł frytki i coś
tłumaczył) z pedantyczną Panią analityk, która chodzi w żakiecie jest
elegancka i zadbana?
Załóż, że oboje są świetni i załóż, że wywałka któregokolwiek z zespołu
kończy się upadkiem projektu.
Co zrobisz?
To nie jest wymysł. Ludzie są różni i przestawianie ich jak pionków na
szachownicy jest "evil".
Co więcej ta Pani od PP w moich badaniach na efektywność kodowania nie była
wstanie wykazać lepszości agile niż tego co wszyscy robią. Zasłaniała się
jakością i maintainowaniem i różnymi błachostkami, ale konkrety nie padły.
Co mam sądzić o PP?
> Dalo mi to wiare, ze da
> sie zarzadzac projektem w ten sposob i ze sa zespoly, ktore chca i
> robia to na codzien.
Zamiast PP wystarczy mieć sensowne meetingi i burze mózgów. PP to wyrzucanie
pieniedzy w błoto.
> Ciekaw jestem jak wiele z praktyk zawartych w tej metodologii jest w
> uzyciu w waszych zespolach.
Tylko tyle ile ma sens.
Np. pisanie, że kod się sam dokumentuje jest dobre w projektach za 50 PLN.
To co robiłem i robię to bez obszernego raportu z opisanymi, wynikami,
wzorami, wykresami, przykładami zastosowania, dyskusją obliczeń,
objaśnieniem czemu kod jest taki a nie inny nie był projektem zamkniętym.
Nie był iteracją zamkniętą.
Nie jest tylko ważne co jest napisane, ważne jest to jak jest napisane a
jeszcze ważniejsze DLACZEGO. Wiele rzeczy ma być w "książce" bo szef
projektu nie musi czytać każdego komentarza zarówno "DLACZEGO" jak i /*
wypisz imię */.
> Pochwalcie sie, a moze inni uwierza, ze sie da! :)
Wolę zdrowy rozsądek niż sztuczne reguły.
Jedynie co mi się podoba w agile, to jest sensowne MDD (ale bez pomocy
softu, który jest kulawy) i TDD, które każdy sensowny programista stosował
tylko tego nie nazywał.
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
Paweł Kierski
[...]
> > ze uzycie pair-programming jest nierealne okazywalo sie, ze w
> > nastepnym zespole szef sam do tego zachecal.
>
> Wiesz. Zadam Ci pytanie, praktyczne, kiedyś je zadałem jednej Pani
> orędowniczki PP.
>
> Jak pogodzisz programistę -- żarłoka sypiącego jedzenie na klawiaturę, z
> ekranem opalcowanym i ociekającym ketchupem (bo jadł frytki i coś
> tłumaczył) z pedantyczną Panią analityk, która chodzi w żakiecie jest
> elegancka i zadbana?
> Wolę zdrowy rozsądek niż sztuczne reguły.
>
Dlatego sensowne są metody, które pozwalają zespołowi na decydowanie
jak ma pracować. Jeśli ludziom lepiej się pisze w parach - OK. Jeśli
nie - też dobrze. Standard kodowania (w sensie formatowania kodu): dla
różnych przypadków wypisujemy warianty i każdy określa "ja najchętniej
X, ale nie przeszkadza mi Y i Z, za to A i B jest dla mnie
nieczytelne". I bardzo szybko można ustalić, jak pisać, żeby jak
najmniej osób zmieniało przyzywczajenia i dla jak największej liczby
osób kod był łatwy do czytania. I tak dalej, aż do tego, że to zespół
(o ile rozumie ograniczenia biznesowe i jest odpowiedzialny, a z innym
nie warto pracować) najlepiej ustali _realne_ terminy dostarczenia
produktu.
--
Paweł Kierski
ne...@pkierski.net
dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
albo koniecznie chcesz obejść moje filtry 8-)
Michal Kleczek
Bla bla bla bla...
Jak czytam takie rzeczy to zawsze mam wrazenie, ze to pisza ludzie nacpani i
szczesliwie zyjacy "gdzies indziej". Tam gdzie klient nie wymaga terminow,
tylko laskawie czeka, az mu sie je zaproponuje, tam gdzie nie ma
konkurencji milionow Hindusow i Chinczykow za 5$/h, tam gdzie zespol jest
nieskonczenie stabilny i sklada sie z samych wyjadaczy z
kilkudziesiecioletnim doswiadczeniem typu Robert Martin/Martin Fowler czy
inni.
Tez bym tak chcial...
Michal
Paweł Kierski
[...]
> Bla bla bla bla...
> Jak czytam takie rzeczy to zawsze mam wrazenie, ze to pisza ludzie nacpani i
> szczesliwie zyjacy "gdzies indziej". Tam gdzie klient nie wymaga terminow,
> tylko laskawie czeka, az mu sie je zaproponuje, tam gdzie nie ma
> konkurencji milionow Hindusow i Chinczykow za 5$/h, tam gdzie zespol jest
> nieskonczenie stabilny i sklada sie z samych wyjadaczy z
> kilkudziesiecioletnim doswiadczeniem typu Robert Martin/Martin Fowler czy
> inni.
Klient wymaga terminów, klient ma budżet, klient zadaje pytanie
teraz. Tylko termin wymagany (oraz wymagania) *trzeba* uzgodnić z
zespołem, bo to zespół najlepiej wie, czy jest w stanie zrobić, czy
nie. Jeśli klient zaproponuje termin nierealny, to można mu
zaproponować mniejszą funkcjonalność. Oczywiście, o ile budżet
wystarczy co najmniej na wynagrodzenie programistów 8-) A czasem może
się okazać, że klinetowi tak naprawdę wystarczy (przynajmniej na
początek) funkcjonalność okrojona.
Jak się klient nie zgadza, to znaczy, że projekt jest niewykonalny
w aktualnym zespole, przy takich ograniczeniach. Branie go jest
oszukiwaniem siebie i klienta. Oczywiście - być może programiści są
kiepscy, albo mają słabe narzędzia, ale to temat na wewnętrzną
analizę i ewentualne poprawki (do decyzji o przerzuceniu się na
kopanie rowów włącznie).
Narzucanie terminów trochę przypomina robienie rozkładu jazdy
autobusów w górach, zakładając średnią szybkość na jakimś poziomie.
Tylko, że między niektóymi przystankami jest z górki, gdzieniegdzie są
korki w miasteczkach. A najlepiej te "techniczne" ograniczenia znają
kierowcy - dobrze ich zapytać, czy między A i B da się przejechać w 10
minut. Zakładając, że masz najlepszych kierowców i autobusy na jakie
Cię stać w tej chwili.
Takie podejście najbardziej sprawdza się wtedy, gdy klient sam nie
do końca wie, co chce. Można mu co iterację pokazywać kolejne
funkcjonalności, dla których stosunek cena (wartość dla niego) do
kosztu (najprościej: czasu) jest najlepszy.
> Tez bym tak chcial...
Zapraszam - Martinów nie gwarantuję 8-)
Piotr Dembiński
[...]
> > Wolę zdrowy rozsądek niż sztuczne reguły.
> >
> [...]
>
> Dlatego sensowne są metody, które pozwalają zespołowi
> na decydowanie jak ma pracować.
Agile i XP to właśnie nic więcej, jak zbiór metod. I to metod znanych
od bardzo dawna, tylko dopiero niedawno jakoś tam skodyfikowanych.
> Jeśli ludziom lepiej się pisze w parach - OK.
Pair programming to po prostu połączenie przeglądu kodu
z projektowaniem. Jedna osoba pisze, a druga od razu przegląda
utworzony przez nią kod. Zamiast programowania w parach można
stosować przeglądy oraz inspekcje kodu.
> Jeśli nie - też dobrze. Standard kodowania (w sensie formatowania
> kodu): dla różnych przypadków wypisujemy warianty i każdy określa
> "ja najchętniej X, ale nie przeszkadza mi Y i Z, za to A i B jest
> dla mnie nieczytelne".
Właśnie, postulat kodu będącego dokumentacją wynika z innego
postulatu, mianowicie postulatu tworzenia kodu czytelnego, zgodnego
z określonymi standardami.
--
http://www.piotr.dembiński.prv.pl
Michal Kleczek
> Michal Kleczek w wiadomości <frasl5$ple$1...@mx1.internetia.pl> pisze:
> [...]
>> Bla bla bla bla...
>> Jak czytam takie rzeczy to zawsze mam wrazenie, ze to pisza ludzie
>> nacpani i szczesliwie zyjacy "gdzies indziej". Tam gdzie klient nie
>> wymaga terminow, tylko laskawie czeka, az mu sie je zaproponuje, tam
>> gdzie nie ma konkurencji milionow Hindusow i Chinczykow za 5$/h, tam
>> gdzie zespol jest nieskonczenie stabilny i sklada sie z samych wyjadaczy
>> z kilkudziesiecioletnim doswiadczeniem typu Robert Martin/Martin Fowler
>> czy inni.
>
> Klient wymaga terminów, klient ma budżet, klient zadaje pytanie
> teraz. Tylko termin wymagany (oraz wymagania) *trzeba* uzgodnić z
> zespołem, bo to zespół najlepiej wie, czy jest w stanie zrobić, czy
> nie.
Jak zespol nie jest w stanie zrobic to klient wybiera inny zespol.
> Jeśli klient zaproponuje termin nierealny, to można mu
> zaproponować mniejszą funkcjonalność. Oczywiście, o ile budżet
> wystarczy co najmniej na wynagrodzenie programistów 8-) A czasem może
> się okazać, że klinetowi tak naprawdę wystarczy (przynajmniej na
> początek) funkcjonalność okrojona.
>
> Jak się klient nie zgadza, to znaczy, że projekt jest niewykonalny
> w aktualnym zespole, przy takich ograniczeniach. Branie go jest
> oszukiwaniem siebie i klienta. Oczywiście - być może programiści są
> kiepscy, albo mają słabe narzędzia, ale to temat na wewnętrzną
> analizę i ewentualne poprawki (do decyzji o przerzuceniu się na
> kopanie rowów włącznie).
W ten sposob nigdy nie dostaniesz zadnej roboty. Chyba, ze masz kumpli ew.
rodzine w zarzadach organizacji dysponujacych nieporownywalnie wieksza kasa
niz twoje koszty.
To mniej wiecej tak, jakby mi pracownik powiedzial - jestem kiepski, nie
umiem tego zrobic i nie wezme tej roboty. Za pierwszym razem odpowiadam: to
sie naucz. Za drugim nic nie mowie. Za trzecim: sp...j. Koloryzuje, ale do
tego sie to sprowadza.
>
> Narzucanie terminów trochę przypomina robienie rozkładu jazdy
> autobusów w górach, zakładając średnią szybkość na jakimś poziomie.
> Tylko, że między niektóymi przystankami jest z górki, gdzieniegdzie są
> korki w miasteczkach. A najlepiej te "techniczne" ograniczenia znają
> kierowcy - dobrze ich zapytać, czy między A i B da się przejechać w 10
> minut. Zakładając, że masz najlepszych kierowców i autobusy na jakie
> Cię stać w tej chwili.
Ale na rynku znajda sie tacy, ktorzy maja zarowno autobusy jak i kierowcow
lepszych i tanszych.
>
> Takie podejście najbardziej sprawdza się wtedy, gdy klient sam nie
> do końca wie, co chce. Można mu co iterację pokazywać kolejne
> funkcjonalności, dla których stosunek cena (wartość dla niego) do
> kosztu (najprościej: czasu) jest najlepszy.
>
Taa... do tego jest niepoprawnym altruista prowadzacym dzialalnosc
charytatywna i zechce sobie dla wlasnego widzimisie placic za kazda kolejna
iteracje zeby zaspokoic swoja ciekawosc: co wlasciwie powstanie za ta kase?
Michal
Stachu 'Dozzie' K.
> Paweł Kierski wrote:
>
>> Michal Kleczek w wiadomości <frasl5$ple$1...@mx1.internetia.pl> pisze:
>> [...]
>>> Bla bla bla bla...
>>> Jak czytam takie rzeczy to zawsze mam wrazenie, ze to pisza ludzie
>>> nacpani i szczesliwie zyjacy "gdzies indziej". Tam gdzie klient nie
>>> wymaga terminow, tylko laskawie czeka, az mu sie je zaproponuje, tam
>>> gdzie nie ma konkurencji milionow Hindusow i Chinczykow za 5$/h, tam
>>> gdzie zespol jest nieskonczenie stabilny i sklada sie z samych wyjadaczy
>>> z kilkudziesiecioletnim doswiadczeniem typu Robert Martin/Martin Fowler
>>> czy inni.
>>
>> Klient wymaga terminów, klient ma budżet, klient zadaje pytanie
>> teraz. Tylko termin wymagany (oraz wymagania) *trzeba* uzgodnić z
>> zespołem, bo to zespół najlepiej wie, czy jest w stanie zrobić, czy
>> nie.
>
> Jak zespol nie jest w stanie zrobic to klient wybiera inny zespol.
...post factum i po wyłożeniu kilkudziesięciu tysięcy złotych?
>> Jeśli klient zaproponuje termin nierealny, to można mu
>> zaproponować mniejszą funkcjonalność. Oczywiście, o ile budżet
>> wystarczy co najmniej na wynagrodzenie programistów 8-) A czasem może
>> się okazać, że klinetowi tak naprawdę wystarczy (przynajmniej na
>> początek) funkcjonalność okrojona.
>>
>> Jak się klient nie zgadza, to znaczy, że projekt jest niewykonalny
>> w aktualnym zespole, przy takich ograniczeniach. Branie go jest
>> oszukiwaniem siebie i klienta. Oczywiście - być może programiści są
>> kiepscy, albo mają słabe narzędzia, ale to temat na wewnętrzną
>> analizę i ewentualne poprawki (do decyzji o przerzuceniu się na
>> kopanie rowów włącznie).
>
> W ten sposob nigdy nie dostaniesz zadnej roboty. Chyba, ze masz kumpli ew.
> rodzine w zarzadach organizacji dysponujacych nieporownywalnie wieksza kasa
> niz twoje koszty.
> To mniej wiecej tak, jakby mi pracownik powiedzial - jestem kiepski, nie
> umiem tego zrobic i nie wezme tej roboty. Za pierwszym razem odpowiadam: to
> sie naucz. Za drugim nic nie mowie. Za trzecim: sp...j. Koloryzuje, ale do
> tego sie to sprowadza.
A teraz sobie wyobraź że weźmie robotę, przekroczy termin trzykrotnie,
a na dokładkę spierdoli wykonanie i trzeba będzie po nim poprawiać przez
pół roku.
>> Narzucanie terminów trochę przypomina robienie rozkładu jazdy
>> autobusów w górach, zakładając średnią szybkość na jakimś poziomie.
>> Tylko, że między niektóymi przystankami jest z górki, gdzieniegdzie są
>> korki w miasteczkach. A najlepiej te "techniczne" ograniczenia znają
>> kierowcy - dobrze ich zapytać, czy między A i B da się przejechać w 10
>> minut. Zakładając, że masz najlepszych kierowców i autobusy na jakie
>> Cię stać w tej chwili.
>
> Ale na rynku znajda sie tacy, ktorzy maja zarowno autobusy jak i kierowcow
> lepszych i tanszych.
Naturalnie. Na tym polega wolny rynek. Ale prawdopodobne jest, że te
autobusy są dostosowane do innych warunków drogowych, kierowcy do tej
pory jeździli na drugim końcu polski i nie znają tras, zaplecze
techniczne leży i kwiczy, a sama firma nie ma już wolnych zasobów, które
mogłaby przeznaczyć na obsługę kolejnego klienta. To też oczywiście
część wolnego rynku.
>> Takie podejście najbardziej sprawdza się wtedy, gdy klient sam nie
>> do końca wie, co chce. Można mu co iterację pokazywać kolejne
>> funkcjonalności, dla których stosunek cena (wartość dla niego) do
>> kosztu (najprościej: czasu) jest najlepszy.
>>
>
> Taa... do tego jest niepoprawnym altruista prowadzacym dzialalnosc
> charytatywna i zechce sobie dla wlasnego widzimisie placic za kazda kolejna
> iteracje zeby zaspokoic swoja ciekawosc: co wlasciwie powstanie za ta kase?
Nie miałeś do czynienia z nieinformatycznym klientem, prawda? Taki
delikwent często kompletnie nie ma pojęcia, co by chciał za
funkcjonalność i często zmienia zdanie.
--
Secunia non olet.
Stanislaw Klekot
Michal Kleczek
[ciach]
>>
>> Jak zespol nie jest w stanie zrobic to klient wybiera inny zespol.
>
> ...post factum i po wyłożeniu kilkudziesięciu tysięcy złotych?
Ja nie jestem sobie wyobrazic klienta, ktory wyklada kilkadziesiat tysiecy
zlotych nie majac przekonania, ze dostanie za te pieniadze cos, co mu jest
potrzebne. Jezeli tak robi tzn, ze zostal oszukany.
[ciach]
>
> A teraz sobie wyobraź że weźmie robotę, przekroczy termin trzykrotnie,
> a na dokładkę spierdoli wykonanie i trzeba będzie po nim poprawiać przez
> pół roku.
Ze tak powiem - shit happens. Jak ludzie buduja dom to tez maja przypadki,
ze tynkarze spapraja robote i trzeba poprawiac. Co nie znaczy, ze z gory
nie ustalaja, co ma byc zrobione i za ile. Ja - jako tynkarz - dokladam
wszelkich staran, zeby klient mial to, co chce, dobrej jakosci, tanio (ale
nie ponizej kosztow) i - co bardzo wazne - zeby nie musial sobie zawracac
dupy tym jak, kiedy, jakim samochodem dowoze materialy i innymi pierdolami.
Wyobraz sobie, ze klienci to lubia.
>
>>> Narzucanie terminów trochę przypomina robienie rozkładu jazdy
>>> autobusów w górach, zakładając średnią szybkość na jakimś poziomie.
>>> Tylko, że między niektóymi przystankami jest z górki, gdzieniegdzie są
>>> korki w miasteczkach. A najlepiej te "techniczne" ograniczenia znają
>>> kierowcy - dobrze ich zapytać, czy między A i B da się przejechać w 10
>>> minut. Zakładając, że masz najlepszych kierowców i autobusy na jakie
>>> Cię stać w tej chwili.
>>
>> Ale na rynku znajda sie tacy, ktorzy maja zarowno autobusy jak i
>> kierowcow lepszych i tanszych.
>
> Naturalnie. Na tym polega wolny rynek. Ale prawdopodobne jest, że te
> autobusy są dostosowane do innych warunków drogowych, kierowcy do tej
> pory jeździli na drugim końcu polski i nie znają tras, zaplecze
> techniczne leży i kwiczy, a sama firma nie ma już wolnych zasobów, które
> mogłaby przeznaczyć na obsługę kolejnego klienta. To też oczywiście
> część wolnego rynku.
Jezeli jestes monopolista to mozesz byc agile...
>
>>> Takie podejście najbardziej sprawdza się wtedy, gdy klient sam nie
>>> do końca wie, co chce. Można mu co iterację pokazywać kolejne
>>> funkcjonalności, dla których stosunek cena (wartość dla niego) do
>>> kosztu (najprościej: czasu) jest najlepszy.
>>>
>>
>> Taa... do tego jest niepoprawnym altruista prowadzacym dzialalnosc
>> charytatywna i zechce sobie dla wlasnego widzimisie placic za kazda
>> kolejna iteracje zeby zaspokoic swoja ciekawosc: co wlasciwie powstanie
>> za ta kase?
>
> Nie miałeś do czynienia z nieinformatycznym klientem, prawda? Taki
> delikwent często kompletnie nie ma pojęcia, co by chciał za
> funkcjonalność i często zmienia zdanie.
>
Ja codziennie mam doczynienia z "nieinformatycznym klientem". Tylko, ze to
dziala zupelnie odwrotnie niz ty mowisz. To nie jest tak, ze klient ma
ochote sobie zrobic system informatyczny, ale nie wie jaki i do czego.
Klient sie zajmuje dajmy na to handlem pietruszka, to ja do niego
przychodze, cos mu proponuje - a on ocenia, czy to co mu proponuje jest dla
niego warte tyle ile ja za to zadam. Zauwaz, ze to jest MOJA rola
dowiedziec sie/wymyslic, co ten klient moze chciec kupic i to jest MOJE
ryzyko, ze nie trafie.
Szczesliwie jest coraz wiecej leszczy, ktorzy sie lapia na XP/Agile -
rozsadna konkurencja sie zmniejsza.
Michal
Paweł Kierski
[...]
> > Klient wymaga terminów, klient ma budżet, klient zadaje pytanie
> > teraz. Tylko termin wymagany (oraz wymagania) *trzeba* uzgodnić z
> > zespołem, bo to zespół najlepiej wie, czy jest w stanie zrobić, czy
> > nie.
>
> Jak zespol nie jest w stanie zrobic to klient wybiera inny zespol.
Wtedy przekwalifikujemy się na sprzedaż pietruszki, albo kopanie
rowów, bo to oznacza, że nie ma miejsca na rynku dla nas.
[...]
> To mniej wiecej tak, jakby mi pracownik powiedzial - jestem kiepski, nie
> umiem tego zrobic i nie wezme tej roboty. Za pierwszym razem odpowiadam: to
> sie naucz. Za drugim nic nie mowie. Za trzecim: sp...j. Koloryzuje, ale do
> tego sie to sprowadza.
Jeśli klient jest w sytuacji, że może dalej szukać wykonawcy, to
powie... hmmm... "idźcie sobie" przy pierwszym podejściu. Może kupi
produkt z półki. Tak - do tego to się sprowadza.
> > Narzucanie terminów trochę przypomina robienie rozkładu jazdy
> > autobusów w górach, zakładając średnią szybkość na jakimś poziomie.
> > Tylko, że między niektóymi przystankami jest z górki, gdzieniegdzie są
> > korki w miasteczkach. A najlepiej te "techniczne" ograniczenia znają
> > kierowcy - dobrze ich zapytać, czy między A i B da się przejechać w 10
> > minut. Zakładając, że masz najlepszych kierowców i autobusy na jakie
> > Cię stać w tej chwili.
>
> Ale na rynku znajda sie tacy, ktorzy maja zarowno autobusy jak i kierowcow
> lepszych i tanszych.
Jak się znajdą, to znaczy, że jesteśmy kiepscy - albo coś
poprawiamy, albo kopanie rowów. BTW - mając kilometr rowu do
wykopania, trzech ludzi z łopatami i termin "za godzinę" też się nie
da. Ale może z koparkami daliby radę? Aha - trzeba mieć koparki i
kwalifikacje do ich obsługi? OK - kupujemy i szkolimy. Jak nie mamy
kasy - sprzedaż pietruszki.
> > Takie podejście najbardziej sprawdza się wtedy, gdy klient sam nie
> > do końca wie, co chce. Można mu co iterację pokazywać kolejne
> > funkcjonalności, dla których stosunek cena (wartość dla niego) do
> > kosztu (najprościej: czasu) jest najlepszy.
> >
>
> Taa... do tego jest niepoprawnym altruista prowadzacym dzialalnosc
> charytatywna i zechce sobie dla wlasnego widzimisie placic za kazda kolejna
> iteracje zeby zaspokoic swoja ciekawosc: co wlasciwie powstanie za ta kase?
Nie. Jest klientem, który przychodzi i na początku mówi "zróbcie mi
system, żeby był dobry". Wtedy wyciąga się z niego "A co by Pan tak
najbardziej chciał, żeby to robiło?" i robi.
Paweł Kierski
> Stachu 'Dozzie' K. wrote:
>
> [ciach]
> >>
> >> Jak zespol nie jest w stanie zrobic to klient wybiera inny zespol.
> >
> > ...post factum i po wyłożeniu kilkudziesięciu tysięcy złotych?
>
> Ja nie jestem sobie wyobrazic klienta, ktory wyklada kilkadziesiat tysiecy
> zlotych nie majac przekonania, ze dostanie za te pieniadze cos, co mu jest
> potrzebne. Jezeli tak robi tzn, ze zostal oszukany.
On może nie mieć wiedzy, czy to coś jest mu potrzebne. Wtedy
oszukuje się sam.
> [ciach]
> >
> > A teraz sobie wyobraź że weźmie robotę, przekroczy termin trzykrotnie,
> > a na dokładkę spierdoli wykonanie i trzeba będzie po nim poprawiać przez
> > pół roku.
>
> Ze tak powiem - shit happens. Jak ludzie buduja dom to tez maja przypadki,
> ze tynkarze spapraja robote i trzeba poprawiac. Co nie znaczy, ze z gory
> nie ustalaja, co ma byc zrobione i za ile. Ja - jako tynkarz - dokladam
> wszelkich staran, zeby klient mial to, co chce, dobrej jakosci, tanio (ale
> nie ponizej kosztow) i - co bardzo wazne - zeby nie musial sobie zawracac
> dupy tym jak, kiedy, jakim samochodem dowoze materialy i innymi pierdolami.
> Wyobraz sobie, ze klienci to lubia.
Ależ dokładnie o to chodzi! Do tego jeszcze tylko: jeśli zobowiążę
się do dotrzymania terminu, to go dotrzymuję. Na hasło "A nie można w
dwa tygodnie zamiast w trzy?" nie odpowiadam "Nooo... właściwie to by
się dało...", ale "Da się, ale bez tynku w piwnicy. Umówmy się tak: za
dwa tygodnie będzie bez piwnic, potem Pan zobaczy, czy potrzeba."
> > Nie miałeś do czynienia z nieinformatycznym klientem, prawda? Taki
> > delikwent często kompletnie nie ma pojęcia, co by chciał za
> > funkcjonalność i często zmienia zdanie.
> >
>
> Ja codziennie mam doczynienia z "nieinformatycznym klientem". Tylko, ze to
> dziala zupelnie odwrotnie niz ty mowisz. To nie jest tak, ze klient ma
> ochote sobie zrobic system informatyczny, ale nie wie jaki i do czego.
> Klient sie zajmuje dajmy na to handlem pietruszka, to ja do niego
> przychodze, cos mu proponuje - a on ocenia, czy to co mu proponuje jest dla
> niego warte tyle ile ja za to zadam. Zauwaz, ze to jest MOJA rola
> dowiedziec sie/wymyslic, co ten klient moze chciec kupic i to jest MOJE
> ryzyko, ze nie trafie.
I to tak działa. Tylko na początek próbujemy (z klientem) ustalić
minimalną funkcjonalność i to proponujemy na początek. Jak zacznie
tego używać, to może lepiej sprecyzuje, czego mu potrzeba jeszcze. A
co dla klienta ważne - będzie miał to względnie szybko, za względnie
małe pieniądze. Jak nie trafimy w ogóle, to mniejsza strata dla obu
stron.
Michal Kleczek
[ciach]
>> >
>>
>> Ja codziennie mam doczynienia z "nieinformatycznym klientem". Tylko, ze
>> to dziala zupelnie odwrotnie niz ty mowisz. To nie jest tak, ze klient ma
>> ochote sobie zrobic system informatyczny, ale nie wie jaki i do czego.
>> Klient sie zajmuje dajmy na to handlem pietruszka, to ja do niego
>> przychodze, cos mu proponuje - a on ocenia, czy to co mu proponuje jest
>> dla niego warte tyle ile ja za to zadam. Zauwaz, ze to jest MOJA rola
>> dowiedziec sie/wymyslic, co ten klient moze chciec kupic i to jest MOJE
>> ryzyko, ze nie trafie.
>
> I to tak działa. Tylko na początek próbujemy (z klientem) ustalić
> minimalną funkcjonalność i to proponujemy na początek. Jak zacznie
> tego używać, to może lepiej sprecyzuje, czego mu potrzeba jeszcze. A
> co dla klienta ważne - będzie miał to względnie szybko, za względnie
> małe pieniądze. Jak nie trafimy w ogóle, to mniejsza strata dla obu
> stron.
>
Sorry, ale to sa jakies bzdury. Ja mam kilka prostych pytan - jak wyglada
umowa miedzy stronami? Kiedy jest wystawiana faktura i jakie sa pozycje na
fakturze? Jak klient taka fakture ksieguje? Czy to mu wchodzi w srodki
trwale, czy nie? Jak to wplywa na koszt calego przedsiewziecia? Jak klient
planuje budzet na nablizszy rok? Uwzglednia ciebie w kosztach?
Wreszcie jak ty planujesz budzet? Jak zachowujesz plynnosc finansowa? Czy
potrzebujesz kredytu, zeby zrealizowac kontrakt? Jesli tak - to jak
wysokiego?
Z drugiej strony po prostu nie jestem w stanie zrozumiec, jak w ogole ktos
chce z takim zespolem zaczac rozmowe? Co macie klientowi do zaoferowania?
Przychodzisz i mowisz: "umiemy dobrze programowac, zrobimy panu jakis
system"?
Michal
Wiktor Zychla
na burdel w projekcie nie ma mocnych.
a podobnie jak agile, "ciężkie metody formalne" to też w 90% buzzwords
oznaczające, że każdy w panice obija sobie dupę blachą ze sterty
nieczytelnych i nikomu do niczego niepotrzebnych dokumentów. w razie draki -
mam papiery że to nie ja.
Wiktor Zychla
Paweł Kierski
[...]
> Z drugiej strony po prostu nie jestem w stanie zrozumiec, jak w ogole ktos
> chce z takim zespolem zaczac rozmowe? Co macie klientowi do zaoferowania?
> Przychodzisz i mowisz: "umiemy dobrze programowac, zrobimy panu jakis
> system"?
Widzę, że zaczynamy dyskusję w stylu "pokażmy skrajnie różną
sytuację/podejście, żeby wykazać, że oponent nie ma racji" 8-)
Z tego wszystkiego chcę tylko pokazać dwie cechy działania agile:
- staramy się dzielić projekt od razu na mniejsze, ale funkcjonalnie
"sprzedawalne" części i umawiamy się na oddawanie w takich częściach
- po każdym etapie patrzymy, co można zrobić lepiej w całym procesie,
którego efektem jest dostarczenie klientowi kolejego fragmentu
Tylko tyle i aż tyle. Reszta zostaje "po staremu" 8-)
Skrajnym przypadkiem jest dojście do wniosku, że projekt można
zrobić tylko "na raz", w ciągu np. roku. Ale to raczej skrajny
przypadek. Zazwyczaj da się dostarczyć klientowi po kwartale "coś co
działa, ale (na razie) nie ma foo i bar".
Michal Kleczek
> Michal Kleczek w wiadomości <frb1vj$bon$1...@mx1.internetia.pl> pisze:
>> Stachu 'Dozzie' K. wrote:
>>
>> [ciach]
>> >>
>> >> Jak zespol nie jest w stanie zrobic to klient wybiera inny zespol.
>> >
>> > ...post factum i po wyłożeniu kilkudziesięciu tysięcy złotych?
>>
>> Ja nie jestem sobie wyobrazic klienta, ktory wyklada kilkadziesiat
>> tysiecy zlotych nie majac przekonania, ze dostanie za te pieniadze cos,
>> co mu jest potrzebne. Jezeli tak robi tzn, ze zostal oszukany.
>
> On może nie mieć wiedzy, czy to coś jest mu potrzebne. Wtedy
> oszukuje się sam.
Tu chyba lezy clue. Widzisz - ja mam o swoich klientach dobre zdanie - na
ich biznesie sie nie znam, ale wiem, ze oni sie znaja i DOSKONALE WIEDZA,
czy cos co im chce sprzedac jest im potrzebne, czy nie. Zeby to ocenic
MUSZA WIEDZIEC CO TO JEST.
Nie spotkalem sie z takim, ktory wydaje pieniadze zupelnie bez sensu i bez
zastanowienia na co, a juz w szczegolnosci nie na bande programistow,
ktorzy beda budowac "jakis system".
Michal
Michal Kleczek
> Michal Kleczek w wiadomości <frb3pf$tc7$1...@mx1.internetia.pl> pisze:
> [...]
>> Z drugiej strony po prostu nie jestem w stanie zrozumiec, jak w ogole
>> ktos chce z takim zespolem zaczac rozmowe? Co macie klientowi do
>> zaoferowania? Przychodzisz i mowisz: "umiemy dobrze programowac, zrobimy
>> panu jakis system"?
>
> Widzę, że zaczynamy dyskusję w stylu "pokażmy skrajnie różną
> sytuację/podejście, żeby wykazać, że oponent nie ma racji" 8-)
>
> Z tego wszystkiego chcę tylko pokazać dwie cechy działania agile:
> - staramy się dzielić projekt od razu na mniejsze, ale funkcjonalnie
> "sprzedawalne" części i umawiamy się na oddawanie w takich częściach
> - po każdym etapie patrzymy, co można zrobić lepiej w całym procesie,
> którego efektem jest dostarczenie klientowi kolejego fragmentu
>
> Tylko tyle i aż tyle. Reszta zostaje "po staremu" 8-)
>
> Skrajnym przypadkiem jest dojście do wniosku, że projekt można
> zrobić tylko "na raz", w ciągu np. roku. Ale to raczej skrajny
> przypadek. Zazwyczaj da się dostarczyć klientowi po kwartale "coś co
> działa, ale (na razie) nie ma foo i bar".
>
Wreszcie rozmawiamy rozsadnie. Problem z agile polega jednak na tym, ze
wszystkie te "procesy" skupiaja sie na samym developmencie pomijajac
szerszy kontekst. Innymi slowy - zebys mogl cos podzielic na fragmenty, to
to cos musi byc zdefiniowane. Pytanie do specow od agile: kto, kiedy i w
jaki sposob to robi i kto za to placi?
Michal
Paweł Kierski
[...]
> >> Ja nie jestem sobie wyobrazic klienta, ktory wyklada kilkadziesiat
> >> tysiecy zlotych nie majac przekonania, ze dostanie za te pieniadze cos,
> >> co mu jest potrzebne. Jezeli tak robi tzn, ze zostal oszukany.
> >
> > On może nie mieć wiedzy, czy to coś jest mu potrzebne. Wtedy
> > oszukuje się sam.
>
> Tu chyba lezy clue. Widzisz - ja mam o swoich klientach dobre zdanie - na
> ich biznesie sie nie znam, ale wiem, ze oni sie znaja i DOSKONALE WIEDZA,
> czy cos co im chce sprzedac jest im potrzebne, czy nie. Zeby to ocenic
> MUSZA WIEDZIEC CO TO JEST.
Ale to super, że wie! Pytanie do niego jest takie: czy woli mieć
wersję "bardzo basic" za kwartał a potem zobaczymy, co jeszcze
potrzebne, czy chce poczekać na "full wypas" rok. Jakie są
niebezpieczeństwa drugiej opcji to raczej wiadomo 8-)
> Nie spotkalem sie z takim, ktory wydaje pieniadze zupelnie bez sensu
> i bez zastanowienia na co, a juz w szczegolnosci nie na bande
> programistow, ktorzy beda budowac "jakis system".
Ale i tu ma mniejsze ryzyko - jak po kwartale dostanie coś, co w
ogóle mu nie jest do niczego potrzebne, nawet jakby do tego dobudować
100 rozszerzeń, to chyba lepiej dla obu stron? Nawet jeśli o wykonanie
i pieniądze będą się procesować...
Paweł Kierski
[...]
> Wreszcie rozmawiamy rozsadnie. Problem z agile polega jednak na tym, ze
> wszystkie te "procesy" skupiaja sie na samym developmencie pomijajac
> szerszy kontekst. Innymi slowy - zebys mogl cos podzielic na fragmenty, to
> to cos musi byc zdefiniowane. Pytanie do specow od agile: kto, kiedy i w
> jaki sposob to robi i kto za to placi?
A jak to jest "normalnie"? 8-) W agile tak samo, tylko na początku
pilnujemy klienta, żeby precyzować na początek bardzo podstawowe
funkcjonalności.
Jednym z poprawianych procesów jest również komunikacja z klientem.
Na przykład może trzeba, po jego czy naszej stronie, znaleźć bardziej
komunikatywnego osobnika?
Michal Kleczek
> Michal Kleczek w wiadomości <frb4t0$kp6$1...@mx1.internetia.pl> pisze:
> [...]
>> Wreszcie rozmawiamy rozsadnie. Problem z agile polega jednak na tym, ze
>> wszystkie te "procesy" skupiaja sie na samym developmencie pomijajac
>> szerszy kontekst. Innymi slowy - zebys mogl cos podzielic na fragmenty,
>> to to cos musi byc zdefiniowane. Pytanie do specow od agile: kto, kiedy i
>> w jaki sposob to robi i kto za to placi?
>
> A jak to jest "normalnie"? 8-)
Na przyklad:
http://www.google.pl/search?hl=pl&q=RUP&btnG=Szukaj+w+Google&lr=
Michal
Paweł Kierski
Pierwszy link to:
http://pl.wikipedia.org/wiki/Rational_Unified_Process , a pod
http://pl.wikipedia.org/wiki/Rational_Unified_Process#Rozszerzenia_i_odmiany
w pierwszej linii jest "Agile Unified Process" 8-)
A.L.
wrote:
>Michal Kleczek w wiadomości <frb4t0$kp6$1...@mx1.internetia.pl> pisze:
>[...]
>> Wreszcie rozmawiamy rozsadnie. Problem z agile polega jednak na tym, ze
>> wszystkie te "procesy" skupiaja sie na samym developmencie pomijajac
>> szerszy kontekst. Innymi slowy - zebys mogl cos podzielic na fragmenty, to
>> to cos musi byc zdefiniowane. Pytanie do specow od agile: kto, kiedy i w
>> jaki sposob to robi i kto za to placi?
>
> A jak to jest "normalnie"? 8-) W agile tak samo, tylko na początku
>pilnujemy klienta, żeby precyzować na początek bardzo podstawowe
>funkcjonalności.
>
> Jednym z poprawianych procesów jest również komunikacja z klientem.
>Na przykład może trzeba, po jego czy naszej stronie, znaleźć bardziej
>komunikatywnego osobnika?
"Agile" to budowa domu wedle zasdy: "Planu nei ma? Nie szkodzi!
PANOWIE, LAC BETON! Klient i tak nei wie czego chce, a jak cos bedzie
nie tak to sie beton odkuje... ehem... zrefaktoryzuje!"
A.L.
Michal Kleczek
> Michal Kleczek w wiadomości <frb5i7$v15$1...@mx1.internetia.pl> pisze:
>> Paweł Kierski wrote:
>>
>> > Michal Kleczek w wiadomości <frb4t0$kp6$1...@mx1.internetia.pl> pisze:
>> > [...]
>> >> Wreszcie rozmawiamy rozsadnie. Problem z agile polega jednak na tym,
>> >> ze wszystkie te "procesy" skupiaja sie na samym developmencie
>> >> pomijajac szerszy kontekst. Innymi slowy - zebys mogl cos podzielic na
>> >> fragmenty, to to cos musi byc zdefiniowane. Pytanie do specow od
>> >> agile: kto, kiedy i w jaki sposob to robi i kto za to placi?
>> >
>> > A jak to jest "normalnie"? 8-)
>>
>> Na przyklad:
>> http://www.google.pl/search?hl=pl&q=RUP&btnG=Szukaj+w+Google&lr=
>
> Pierwszy link to:
> http://pl.wikipedia.org/wiki/Rational_Unified_Process , a pod
>
http://pl.wikipedia.org/wiki/Rational_Unified_Process#Rozszerzenia_i_odmiany
> w pierwszej linii jest "Agile Unified Process" 8-)
>
Dodali ze wzgledu na marketing - w praktyce - nie dziala, nie kupuj.
Michal
Paweł Kierski
[...]
> "Agile" to budowa domu wedle zasdy: "Planu nei ma? Nie szkodzi!
> PANOWIE, LAC BETON! Klient i tak nei wie czego chce, a jak cos bedzie
> nie tak to sie beton odkuje... ehem... zrefaktoryzuje!"
Jeśli już to raczej: "Planu nie ma? Ale podłogę chce mieć? To lejemy
beton, byle mały kwadracik, zobaczymy, może to wystarczy. O
ewentualnych ścianach i dachu pogadamy jak beton stężeje.". Oczywiście
lanie betonu w sytuacji, gdy mamy podejrzenia, że klient jednak chciał
basen byłoby oszustwem. Aha - piwnice można potem zrobić - obok. A ten
kawałek betonu będzie podjazdem, albo podłogą części bez piwnicy.
Oczywiście przeginam sobie nieco - ale tu bez konkretnego przykładu
pójdziemy zawsze w dyskusję, o której już pisałem:
>> Widzę, że zaczynamy dyskusję w stylu "pokażmy skrajnie różną
>> sytuację/podejście, żeby wykazać, że oponent nie ma racji" 8-)
--
Piotr Dembiński
Piotr Dembiński
[...]
> Widzisz - ja mam o swoich klientach dobre zdanie - na ich biznesie
> sie nie znam, ale wiem, ze oni sie znaja i DOSKONALE WIEDZA, czy cos
> co im chce sprzedac jest im potrzebne, czy nie. Zeby to ocenic MUSZA
> WIEDZIEC CO TO JEST.
Zwykle jest to baza danych z bajerami :)
Michal Kleczek
Troche racji w tym jest.
Z tym ze te bajery moga urosnac do sporych rozmiarow i wtedy robi
sie "system, ktorego czescia jest baza danych".
Michal
Piotr Dembiński
Nie rozumiem, o co wszystkim chodzi. Przecież i tak 99 procent
zleceniodawców chce mieć bazę danych.
Piotr Dembiński
> Piotr Dembiński wrote:
>
> > Michal Kleczek <kle...@gmail.com> writes:
> >
> > [...]
> >
> >> Widzisz - ja mam o swoich klientach dobre zdanie - na ich
> >> biznesie sie nie znam, ale wiem, ze oni sie znaja i DOSKONALE
> >> WIEDZA, czy cos co im chce sprzedac jest im potrzebne, czy
> >> nie. Zeby to ocenic MUSZA WIEDZIEC CO TO JEST.
> >
> > Zwykle jest to baza danych z bajerami :)
>
> Troche racji w tym jest.
No i już masz wyjaśnienie -- po prostu twoje projekty niczym się od
siebie nie różnią, masz duży współczynnik ponownego użycia wiedzy
nabytej w poprzednich przedsięwzięciach i możesz stosować takie,
a nie inne metody.
> Z tym ze te bajery moga urosnac do sporych rozmiarow i wtedy robi
> sie "system, ktorego czescia jest baza danych".
Wtedy robi się MVC z bajerami.
--
http://www.piotr.dembiński.prv.pl
Michal Kleczek
> Michal Kleczek <kle...@gmail.com> writes:
>
>> Piotr Dembiński wrote:
>>
>> > Michal Kleczek <kle...@gmail.com> writes:
>> >
>> > [...]
>> >
>> >> Widzisz - ja mam o swoich klientach dobre zdanie - na ich
>> >> biznesie sie nie znam, ale wiem, ze oni sie znaja i DOSKONALE
>> >> WIEDZA, czy cos co im chce sprzedac jest im potrzebne, czy
>> >> nie. Zeby to ocenic MUSZA WIEDZIEC CO TO JEST.
>> >
>> > Zwykle jest to baza danych z bajerami :)
>>
>> Troche racji w tym jest.
>
> No i już masz wyjaśnienie -- po prostu twoje projekty niczym się od
> siebie nie różnią, masz duży współczynnik ponownego użycia wiedzy
> nabytej w poprzednich przedsięwzięciach i możesz stosować takie,
> a nie inne metody.
Na pewnym poziomie abstrakcji projekty w ogole sie miedzy soba nie roznia.
Tym bardziej projekty dot. produkcji oprogramowania.
Jesli chodzi o "duzy wspolczynnik ponownego uzycia wiedzy" to tak - mam
duzy - robie to co umiem.
Co wiecej staram sie ponownie uzywac nie tylko wiedzy, ale tez _produktow_
powstalych wczesniej. Marnotrastwa nie lubie.
>
>> Z tym ze te bajery moga urosnac do sporych rozmiarow i wtedy robi
>> sie "system, ktorego czescia jest baza danych".
>
> Wtedy robi się MVC z bajerami.
>
A co ma MVC do bazy danych?
Michal
Piotr Dembiński
[...]
> >> Z tym ze te bajery moga urosnac do sporych rozmiarow i wtedy robi
> >> sie "system, ktorego czescia jest baza danych".
> >
> > Wtedy robi się MVC z bajerami.
> >
>
> A co ma MVC do bazy danych?
'M' jest od modelu danych. W gruncie rzeczy w systemie bazodanowym
można składować zarówno model, jak i kontroler oraz widok.
Michal Kleczek
Przepraszam, ze jestem upierdliwy, ale co to jest "system bazodanowy"?
Michal
Piotr Dembiński
[...]
> >> A co ma MVC do bazy danych?
> >
> > 'M' jest od modelu danych. W gruncie rzeczy w systemie
> > bazodanowym można składować zarówno model, jak i kontroler oraz
> > widok.
>
> Przepraszam, ze jestem upierdliwy, ale co to jest "system
> bazodanowy"?
Podsystem zarządzania bazą danych: system plików, system zarządzania
relacyjną bazą danych, transakcyjny system zarządzania relacyjną bazą
danych, system zarządzania bazą danych zorientowany na obiekty etc.
--
http://www.piotr.dembiński.prv.pl
A.L.
wrote:
Rozumiem co ksztaltuje Kolegi percepcje na temat informatyki: Baza
danych kaloszy i szlauchow gumowych dla Miejskiego Pzredsiebiorstwa
Kanalizacyjnego.
Z faktu ze 99% aplikacji MISO meic baze danych, nei wynika wcale ze to
co jest wokol bazy danych to jest proste GUI.
A.L.
Michal Kleczek
Chcialem sie upewnic, ze chodzi o DBMS. DBMS jak to DBMS jest od zarzadzania
bazami danych, a w bazie danych - jak to w bazie danych - sa dane. Nie ma
tam ani modelu, ani kontrolera, ani widoku. :)
Michal
Piotr Dembiński
[...]
> Chcialem sie upewnic, ze chodzi o DBMS. DBMS jak to DBMS jest od
> zarzadzania bazami danych, a w bazie danych - jak to w bazie danych
> - sa dane. Nie ma tam ani modelu, ani kontrolera, ani widoku. :)
A myślałem, że to tylko ja potrafię pisać głupoty na grupach...
Michal Kleczek
A ktore zdanie to glupota?
Michal
Piotr Dembiński
Przecież w bazie danych można składować procedury (kontroler), strony
WWW (widok) etc.
Michal Kleczek
No wlasnie to takie "agile".
W bazie danych mozna przechowywac DANE, ktore jakies PROGRAMY przetwarzaja w
sobie specyficzny sposob. Niektore - tak zupelnie w skrocie - wyswietlaja
je w postaci stron WWW, a inne (nazywaja sie interpretery) traktuja te DANE
jako program przetwarzajacy inne DANE.
Michal
Wojciech Malinowski
>>>>> A co ma MVC do bazy danych?
>>>> 'M' jest od modelu danych. W gruncie rzeczy w systemie
>>>> bazodanowym można składować zarówno model, jak i kontroler oraz
>>>> widok.
>>> Przepraszam, ze jestem upierdliwy, ale co to jest "system
>>> bazodanowy"?
>> Podsystem zarządzania bazą danych: system plików, system zarządzania
>> relacyjną bazą danych, transakcyjny system zarządzania relacyjną bazą
>> danych, system zarządzania bazą danych zorientowany na obiekty etc.
>
> Chcialem sie upewnic, ze chodzi o DBMS. DBMS jak to DBMS jest od zarzadzania
> bazami danych, a w bazie danych - jak to w bazie danych - sa dane. Nie ma
> tam ani modelu, ani kontrolera, ani widoku. :)
Taaa, powiedz to twórcom Oracle Application Express ;>
Pozdrawiam,
Wojciech Malinowski
Piotr Dembiński
[...]
> W bazie danych mozna przechowywac DANE, ktore jakies PROGRAMY
> przetwarzaja w sobie specyficzny sposob. Niektore - tak zupelnie
> w skrocie - wyswietlaja je w postaci stron WWW, a inne (nazywaja
> sie interpretery) traktuja te DANE jako program przetwarzajacy
> inne DANE.
W gruncie rzeczy, to dyskutujemy dokładnie nad tym samym, o czym
kiedyś dyskutowałem na pl.soc.prawo (<87641av...@hector.domek>).
Bronek Kozicki
> Jesli nie jestes zainteresowany Agile Development nie czytaj dalej.
>
przyznam, że zdumiewa mnie opór na tym wątku przeciwko Agile.
B.
Michal Kleczek
> Michal Kleczek w wiadomości <frb4t0$kp6$1...@mx1.internetia.pl> pisze:
> [...]
>> Wreszcie rozmawiamy rozsadnie. Problem z agile polega jednak na tym, ze
>> wszystkie te "procesy" skupiaja sie na samym developmencie pomijajac
>> szerszy kontekst. Innymi slowy - zebys mogl cos podzielic na fragmenty,
>> to to cos musi byc zdefiniowane. Pytanie do specow od agile: kto, kiedy i
>> w jaki sposob to robi i kto za to placi?
>
> A jak to jest "normalnie"? 8-) W agile tak samo, tylko na początku
> pilnujemy klienta, żeby precyzować na początek bardzo podstawowe
> funkcjonalności.
Tak mi sie przypomnialo - troche o tym jak jest "normalnie" mozna sobie
poczytac w ksiazkach wymienionych tu (calego bloga warto zreszta
przeczytac):
http://pathfinderpeople.blogs.com/hslahman/books/index.html
Swoja droga - warto czasem posluchac weteranow, co pamietaja jeszcze czasy
lamp elektronowych.
Wprowadzenie calkiem nieformalne "dla opornych" niejakiego Holuba bylo
kiedys drukowane w czesciach na IBM devWorks (praca nieskonczona), a teraz
jest skonsolidowane dostepne tu:
http://www.holub.com/publications/other/bankofallen.html
Michal
Michał 'Khorne' Rzechonek
> przyznam, że zdumiewa mnie opór na tym wątku przeciwko Agile.
Poniewaz Agile to nowy (no, nie taki nowy) silver bullet, a Fred
Brooks w "Mitycznym osobomiesiącu" udowiadnia, że takowe
nie istnieją. Zatem każdy, kto próbuje nam udowodnić, że jego
Ulubiona Metodologia to lek na całe zło jest skazany na
tar & feathers.
Agile - nie, dobry proces - tak.
--
Khorne
Bronek Kozicki
> On 13 Mar, 22:34, "Bronek Kozicki" <b...@spam-trap-cop.net> wrote:
>> przyznam, że zdumiewa mnie opór na tym wątku przeciwko Agile.
>
> Poniewaz Agile to nowy (no, nie taki nowy) silver bullet, a Fred
> Brooks w "Mitycznym osobomiesiącu" udowiadnia, że takowe
> nie istnieją. Zatem każdy, kto próbuje nam udowodnić, że jego
> Ulubiona Metodologia to lek na całe zło jest skazany na
Agile to nie metodologia.
B.
Paweł Kierski
I jak zwykle w usenetowych dyskusjach idzie o nieporozumienie na
poziomie terminologii. Agile rozumiem jako pewną klasę procesów,
których istotną cechą jest adaptacja. I to jest cenne, w pewnej klasie
projektów być na dłuższą metę jest efektywniejsze niż rozwiązanie dane
"z góry". Oczywiście zawsze można taki proces "zaadaptować" do bardzo
złego działania. I tak na końcu są ludzie, którzy (współ)pracują
dobrze albo źle. Agile - w założeniu - pozwala im bardziej
przystosować środowisko, żeby mogli pracować najlepiej jak potrafią.
Michal Kleczek
> Michał 'Khorne' Rzechonek w wiadomości
> <1c4d10bf-f966-4836...@s13g2000prd.googlegroups.com> pisze:
>> On 13 Mar, 22:34, "Bronek Kozicki" <b...@spam-trap-cop.net> wrote:
>> > przyznam, że zdumiewa mnie opór na tym wątku przeciwko Agile.
>>
>> Poniewaz Agile to nowy (no, nie taki nowy) silver bullet, a Fred
>> Brooks w "Mitycznym osobomiesiącu" udowiadnia, że takowe
>> nie istnieją. Zatem każdy, kto próbuje nam udowodnić, że jego
>> Ulubiona Metodologia to lek na całe zło jest skazany na
>> tar & feathers.
>>
>> Agile - nie, dobry proces - tak.
>
> I jak zwykle w usenetowych dyskusjach idzie o nieporozumienie na
> poziomie terminologii. Agile rozumiem jako pewną klasę procesów,
> których istotną cechą jest adaptacja. I to jest cenne, w pewnej klasie
> projektów być na dłuższą metę jest efektywniejsze niż rozwiązanie dane
> "z góry". Oczywiście zawsze można taki proces "zaadaptować" do bardzo
> złego działania.
No bardzo fajnie, ale dla mnie z tego wynika ze agile to jakies puste
haslo - nie niosace ze soba zadnych konkretow.
Zauwaz, ze adaptacja procesu nie jest niczym nowym - dobrze juz od dawna
opisane (przed agile) w publikacjach dot. np CMM. Istotne jest to, ze nawet
w CMM - mimo dosyc sporego poziomu abstrakcji - procesy sa w sposob jasny i
konkretny opisane. To sie nazywa "inzynieria procesow".
Michal
ZbyszekZ
> I jak zwykle w usenetowych dyskusjach idzie o nieporozumienie na
> poziomie terminologii. Agile rozumiem jako pewną klasę procesów,
> których istotną cechą jest adaptacja. I to jest cenne, w pewnej klasie
> projektów być na dłuższą metę jest efektywniejsze niż rozwiązanie dane
> "z góry". Oczywiście zawsze można taki proces "zaadaptować" do bardzo
> złego działania. I tak na końcu są ludzie, którzy (współ)pracują
> dobrze albo źle. Agile - w założeniu - pozwala im bardziej
> przystosować środowisko, żeby mogli pracować najlepiej jak potrafią.
Genrealnie to faktycznie RUP jest agile, aczkolwiek autorzy i fantycy
wszystkich metod typu XP, TDD, FDD, SCRUM i 100 000 innych będa
krzyczeć :-) bo gdzieś słyszałem że najpełniejsza definicja agile to
taka:
każdy choć trochę zarysowany proces nie będący RUP :-)
--
ZZ@private
Piotr Gabryanczyk
z prawda i wynika z braku rzetelnej wiedzy na ten temat.
Opierasz swoje opinie o rzeczy zaslyszane z drugiej reki,
prawdopodobnie z projektow, ktore nie implementowaly agile poprawnie.
Niestety to jest powszechne, ze ludzie wprowadzaja kilka praktyk
agile, bez wiary w sukces, przekrecaja je, robia to na "pol gwizdka".
Winia oni pozniej agile za niepowodzenie ich projektu. Psuja oni
niestety reputacje calego ruchu agile.
Proponuje zebys zapoznal sie z literatura - pelno tego na sieci.
Proponuje zaczac od tego filmu:
http://video.google.com/videoplay?docid=-7230144396191025011
Jesli potrzebujesz wiecej zrodel, lub masz pytania na temat agile
napisz do mnie na priva, a chetnie wyjasnie watpliwosci.
Pozdrawiam,
Piotr Gabryanczyk
On 12 Mar, 18:51, Seweryn Habdank-Wojewódzki <shw_m...@wp.pl> wrote:
> Witam
>
> Piotr Gabryanczyk wrote:
> > Jesli nie jestes zainteresowany Agile Development nie czytaj dalej.
>
> Agile nie! Dobre developowanie tak!
>
> > Osobiscie przeszedlem przez kilka zespolow, ktore mialy siebie same za
> > agile.
>
> Znałem i znam takie zespoły, które pracowały "agile" zanim to się
> rozreklamowało i zamin poudziwniano w programowaniu wszystko co było
> normalne.
>
> > ze uzycie pair-programming jest nierealne okazywalo sie, ze w
> > nastepnym zespole szef sam do tego zachecal.
>
> Wiesz. Zadam Ci pytanie, praktyczne, kiedyś je zadałem jednej Pani
> orędowniczki PP.
>
> Jak pogodzisz programistę -- żarłoka sypiącego jedzenie na klawiaturę, z
> ekranem opalcowanym i ociekającym ketchupem (bo jadł frytki i coś
> tłumaczył) z pedantyczną Panią analityk, która chodzi w żakiecie jest
> elegancka i zadbana?
>
> Załóż, że oboje są świetni i załóż, że wywałka któregokolwiek z zespołu
> kończy się upadkiem projektu.
>
> Co zrobisz?
>
> To nie jest wymysł. Ludzie są różni i przestawianie ich jak pionków na
> szachownicy jest "evil".
>
> Co więcej ta Pani od PP w moich badaniach na efektywność kodowania nie była
> wstanie wykazać lepszości agile niż tego co wszyscy robią. Zasłaniała się
> jakością i maintainowaniem i różnymi błachostkami, ale konkrety nie padły.
> Co mam sądzić o PP?
>
> > Dalo mi to wiare, ze da
> > sie zarzadzac projektem w ten sposob i ze sa zespoly, ktore chca i
> > robia to na codzien.
>
> Zamiast PP wystarczy mieć sensowne meetingi i burze mózgów. PP to wyrzucanie
> pieniedzy w błoto.
>
> > Ciekaw jestem jak wiele z praktyk zawartych w tej metodologii jest w
> > uzyciu w waszych zespolach.
>
> Tylko tyle ile ma sens.
>
> Np. pisanie, że kod się sam dokumentuje jest dobre w projektach za 50 PLN.
>
> To co robiłem i robię to bez obszernego raportu z opisanymi, wynikami,
> wzorami, wykresami, przykładami zastosowania, dyskusją obliczeń,
> objaśnieniem czemu kod jest taki a nie inny nie był projektem zamkniętym.
> Nie był iteracją zamkniętą.
>
> Nie jest tylko ważne co jest napisane, ważne jest to jak jest napisane a
> jeszcze ważniejsze DLACZEGO. Wiele rzeczy ma być w "książce" bo szef
> projektu nie musi czytać każdego komentarza zarówno "DLACZEGO" jak i /*
> wypisz imię */.
>
> > Pochwalcie sie, a moze inni uwierza, ze sie da! :)
>
> Wolę zdrowy rozsądek niż sztuczne reguły.
>
> Jedynie co mi się podoba w agile, to jest sensowne MDD (ale bez pomocy
> softu, który jest kulawy) i TDD, które każdy sensowny programista stosował
> tylko tego nie nazywał.
>
> Pozdrawiam.
>
> --
> |\/\/| Seweryn Habdank-Wojewódzki
> \/\/
Jacek Wieczorek
> Ja juz pisalem Agile, XP: to jest zboczonmy produkt chorej wyobrazni.
> W szczegolnosci, cale pieprzenei o "pair programming" do smieci wloze.
Chciałbym zauważyć, że PP to tylko jedna z wielu praktyk XP. W XP
podstawą są wartości a nie praktyki, które nie są obowiązkowe. Kent
Beck zaleca tylko, aby używać ich jak najwięcej, ale nie jest to
sztywny wymóg.
pozdrawiam
Jacek Wieczorek
Piotr Gabryanczyk
> wszystkie te "procesy" skupiaja sie na samym developmencie pomijajac
> szerszy kontekst.
pl.wikipedia.org/wiki/Miejska_legenda)
Zacytuje czesc agile manifesto:
"Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan "
Tu nie ma nic o developmencie - to jest o wspolpracy z klientem i
robieniu dorego produktu.
Proponuje poczytac o agile wiecej - zerknij do mojej odpowiedzi na
email seweryna.
> Innymi slowy - zebys mogl cos podzielic na fragmenty, to
> to cos musi byc zdefiniowane. Pytanie do specow od agile: kto, kiedy i w
> jaki sposob to robi i kto za to placi?
A jak robisz analize - tez musisz zaczac od jakiegos malego kawalka -
nie analizujesz wszystkiego na raz.
Bierzesz maly kawalek i zamiast go w pelni dokumentowac implemantujesz
demo tego kawaleczka. Nie wiesz nawet jak bardzo takie male demo moze
stymulowac i ulatwiac dalsza analize. Robisz to kawalek po kawalku i
dostajesz natychmiastowy feedback (petla zwrotna).
Pozdrawiam,
Piotr Gabryanczyk
Szymon
>> Wreszcie rozmawiamy rozsadnie. Problem z agile polega jednak na tym, ze
>> wszystkie te "procesy" skupiaja sie na samym developmencie pomijajac
>> szerszy kontekst.
> Nic bardziej mylnego, to kolejna "urban legend" o agile. (http://
> pl.wikipedia.org/wiki/Miejska_legenda)
>
> Zacytuje czesc agile manifesto:
>
> "Working software over comprehensive documentation
> Customer collaboration over contract negotiation
> Responding to change over following a plan "
>
> Tu nie ma nic o developmencie - to jest o wspolpracy z klientem i
> robieniu dorego produktu.
> Proponuje poczytac o agile wiecej - zerknij do mojej odpowiedzi na
> email seweryna.
>
Chodzi Ci o ten mejl w którym piszesz, że to 'zasłyszane rzeczy' a jakby
co to opowiesz więcej na privie? To może potraktuj tę grupę jako priv i
napisz tutaj.
>> Innymi slowy - zebys mogl cos podzielic na fragmenty, to
>> to cos musi byc zdefiniowane. Pytanie do specow od agile: kto, kiedy i w
>> jaki sposob to robi i kto za to placi?
> A jak robisz analize - tez musisz zaczac od jakiegos malego kawalka -
> nie analizujesz wszystkiego na raz.
> Bierzesz maly kawalek i zamiast go w pelni dokumentowac implemantujesz
> demo tego kawaleczka. Nie wiesz nawet jak bardzo takie male demo moze
> stymulowac i ulatwiac dalsza analize. Robisz to kawalek po kawalku i
> dostajesz natychmiastowy feedback (petla zwrotna).
>
> Pozdrawiam,
>
> Piotr Gabryanczyk
A na koniec masz pełno takich demek i nigdzie nie spisany sposób
działania bez jakiejkolwiek dokumentacji i dochodzisz do tego co
obserwuję teraz: totalny burdel, ciągłe działanie niezgodne z tym co
klient sobie wymyślił i odpowiedzi klienta na prośbę o specyfikację:
"aplikacja sama w sobie jest specyfikacją".
--
Piotr Gabryanczyk
> działania bez jakiejkolwiek dokumentacji i dochodzisz do tego co
> obserwuję teraz: totalny burdel, ciągłe działanie niezgodne z tym co
> klient sobie wymyślił i odpowiedzi klienta na prośbę o specyfikację:
> "aplikacja sama w sobie jest specyfikacją".
Po pierwsze twoje "demka" to zaczatek produktu, wiec czesto ich nie
wyrzucasz a rozwijasz z nich prawdziwy produkt.
Druga sprawa - jesli pokazesz klientowi postepy powiedzmy co 2
tygodnie. I co dwa tygodnie klient bedzie mogl powiedziec ci w ktora
strone chce rozwijac produkt to nie wierze zeby skonczylo sie to tak
jak piszesz.
Jesli nawet klient zmienia zdanie czesto to gdy na koniec zapyta o
specyfikacje mozesz mu pokazac backlog kazdej iteracji ze wszystkimi
decyzjami, ktore podjal. Ale nie o to chodzi, pamietaj "Customer
collaboration over contract negotiation"
Tak czy inaczej nic nie ustrzeze cie przed patologicznymi relacjami z
klientem.
Jesli twoj projekt tak wyglada, to znaczy, ze "product manager" nie
robi dobrej roboty i ktos musi to zmienic.
Piotr Gabryanczyk
Szymon
>> A na koniec masz pełno takich demek i nigdzie nie spisany sposób
>> działania bez jakiejkolwiek dokumentacji i dochodzisz do tego co
>> obserwuję teraz: totalny burdel, ciągłe działanie niezgodne z tym co
>> klient sobie wymyślił i odpowiedzi klienta na prośbę o specyfikację:
>> "aplikacja sama w sobie jest specyfikacją".
>
> Po pierwsze twoje "demka" to zaczatek produktu, wiec czesto ich nie
> wyrzucasz a rozwijasz z nich prawdziwy produkt.
>
> Druga sprawa - jesli pokazesz klientowi postepy powiedzmy co 2
> tygodnie. I co dwa tygodnie klient bedzie mogl powiedziec ci w ktora
> strone chce rozwijac produkt to nie wierze zeby skonczylo sie to tak
> jak piszesz.
>
No i widzisz, nie masz racji. Klient tak pokazywał co i jak i teraz się
okazuje, że uważa, że miał co innego na myśli. Specyfikacja, którą
napisał na początku jest wieloznaczna, bo potem było takie agile, zmiany
i klient pokazywał: 'o, a tutaj zróbmy tak'. W efekcie teraz wykonawcy
dostają po dupie, że klient chciał niby coś innego, a na prośbę o
opisanie co to ma być i jak ma działać i jak współdziałać z innymi
elementami systemu i jak te inne elementy mają działać, odpowiedź jest
krótka: "sama aplikacja jest specyfikacją, nic spisanego nie ma".
Efekt:
- testerzy nie wiedzą jak to ma działać
- oczywiście aplikacja zawsze działa dobrze, bo przecież jest zgodna ze
specyfikacją (czyli sama ze sobą)
- klient wie, że nie dostał tego za co płacił
-
> Jesli nawet klient zmienia zdanie czesto to gdy na koniec zapyta o
> specyfikacje mozesz mu pokazac backlog kazdej iteracji ze wszystkimi
> decyzjami, ktore podjal. Ale nie o to chodzi, pamietaj "Customer
> collaboration over contract negotiation"
Czyli co, klient pokazuje palcem, że chce inaczej i to dostaje, a potem
twierdzi, że miał na myśli coś innego? Przecież nic nie jest spisane,
zamiast tego są jakieś nieistotne demka. Jak te demka są testowane?
Testerzy siadają i się domyślają co kto miał na myśli?
> Tak czy inaczej nic nie ustrzeze cie przed patologicznymi relacjami z
> klientem.
Patologia to brak jasnego opisania przez klienta czego chce.
> Jesli twoj projekt tak wyglada, to znaczy, ze "product manager" nie
> robi dobrej roboty i ktos musi to zmienic.
Chrzanić product managera, przecież on musiałby być wielkim fachowcem
nie tyle od kontaktów z klientem, ale od wszystkich technologii i od
każdego elementu kodu żeby mieć wgląd w dokumentację.
Michal Kleczek
>
> Zacytuje czesc agile manifesto:
>
> "Working software over comprehensive documentation
To sie nadaje do softu wielkosci 500LOC robionego przez dwoch ludzi.
> Customer collaboration over contract negotiation
To sie nadaje do developmentu in-house, albo jak klient ma na tyle duzo
kasy, zeby placic na zasadzie "time and material" - a i to nie zawsze.
> Responding to change over following a plan "
To wynika z niezrozumienia co to jest plan, na czym polega i czemu sluzy
proces planowania.
Michal
Wit Jakuczun
Piotr Gabryanczyk <pio...@gmail.com> napisał(a):
> > A na koniec masz pełno takich demek i nigdzie nie spisany sposób
> > działania bez jakiejkolwiek dokumentacji i dochodzisz do tego co
> > obserwuję teraz: totalny burdel, ciągłe działanie niezgodne z tym co
> > klient sobie wymyślił i odpowiedzi klienta na prośbę o specyfikację:
> > "aplikacja sama w sobie jest specyfikacją".
>
> Po pierwsze twoje "demka" to zaczatek produktu, wiec czesto ich nie
> wyrzucasz a rozwijasz z nich prawdziwy produkt.
>
> Druga sprawa - jesli pokazesz klientowi postepy powiedzmy co 2
> tygodnie. I co dwa tygodnie klient bedzie mogl powiedziec ci w ktora
> strone chce rozwijac produkt to nie wierze zeby skonczylo sie to tak
> jak piszesz.
>
Sprobuj. Niesamowite przezycie. Kazdy email od klienta
to poprzedzony dreszczykiem lecacym wzdluz kregoslupa.
Takie tworzenie oprogramowania to jakas mrzonka.
Jak wyceniac projekt nie znajac jego zakresu?
> Jesli nawet klient zmienia zdanie czesto to gdy na koniec zapyta o
Na jaki koniec??? Jak klient nie bedzie mial w umowie powiedziane,
gdzie jest cel to bedzie Cie wodzil za nos do usranej smierci.
Pozdrawiam
--
[ Wit Jakuczun <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions http://www.wlogsolutions.com ]
A.L.
Kent BEck, cytuje: "Yes, project failed, but methodology was right".
Porady Pana K.B. to ja mam na gwozdizu w kiblu powieszone.
A.L.
Piotr Gabryanczyk
To co opisujesz to nie jest agile.
To jest waterfall z jakas proba implementacji przy uzyciu wybranych
technik agile.
Moglibysmy ciagnac te dyskusje w nieskonczonosc, ale lepiej bedzie
jesli poczytasz o agile u fachowcow: Schwaber, Beck, etc. Polecam tez
jakies szkolenie o agile. Przekonasz sie wtedy, co oznacza agile na
prawde.
Piotr
A.L.
Panowie, wiwkszosc rzeczy ktore sie pisze w tym watku to "jak Maly
Jasio wyobraza sobie robienie oprogramowania dla klienta". Totalne
nonsenst, wlcznei z powyzszym, zwlaszcza "pokazyanie klientowi co 2
tygodnie".
Jak klient zobaczy takie badziewie jak sie tutaj pisze, to splunie i
pojdzie gdzie indziej.
Moja firma ma wlasnei "audit" robiony przez potencjalnego klienta. Ow
potencjalny klient zatrudnil firme konsultingowa do oceny naszych
"practices", sposobu projektowania, standardow dokumentacji,
standardow programwoania, QA i paru innych rzeczy. Jak sie klientowi
nei spodoba, to pojdzie gdzie indziej. Gdy klient inwestuje duze
pieneidze w projekt, to chce miec pewnosc ze nie bedzie inwestowal w
jakies badziewie.
Takie "audyty" sa na pozradku dziennym
A.L.
Piotr Gabryanczyk
Michal,
1. To znowu "urban myth". Oczywiscie, ze agile stosuje sie w duzych
projektach.
Przyklady: Simens, Bank of America, i wiele innych.
2. Esencja agile jest dobre planowanie. Sprecyzuj co masz na mysli.
Piotr Gabryanczyk
> Dnia Fri, 14 Mar 2008 04:52:38 -0700 (PDT)
To juz twoja sprawa jakie masz relacje z klientem.
Agile ma wiele technik, ktore pomagaja zapobiegac wodzeniu za nos.
Proponuje poczytac i sprobowac.
Piotr
Piotr Gabryanczyk
> On Fri, 14 Mar 2008 03:55:14 -0700 (PDT), Jacek Wieczorek
>
> >On 12 Mar, 18:31, A.L. <alewa...@zanoza.com> wrote:
> >> Ja juz pisalem Agile, XP: to jest zboczonmy produkt chorej wyobrazni.
> >> W szczegolnosci, cale pieprzenei o "pair programming" do smieci wloze.
>
> >Chciałbym zauważyć, że PP to tylko jedna z wielu praktyk XP. W XP
> >podstawą są wartości a nie praktyki, które nie są obowiązkowe. Kent
> >Beck zaleca tylko, aby używać ich jak najwięcej, ale nie jest to
> >sztywny wymóg.
>
> Kent BEck, cytuje: "Yes, project failed, but methodology was right".
> Porady Pana K.B. to ja mam na gwozdizu w kiblu powieszone.
>
> A.L.
Nie cytuj wypowiedzi wyrwanej z kontekstu.
Podaj zrodlo.
Wit Jakuczun
Piotr Gabryanczyk <pio...@gmail.com> napisał(a):
> To juz twoja sprawa jakie masz relacje z klientem.
> Agile ma wiele technik, ktore pomagaja zapobiegac wodzeniu za nos.
> Proponuje poczytac i sprobowac.
>
Dziekuje, ale to co przytoczyles mnie nie zachecilo...
Pozdrawaim
A.L.
Zarujesz, co nei?... Albo jestes zielony
K.B. prowadzil project C3 dla bodajrze, Chrysler Corporation, i tam
wlasnei tworczo zastosowal XP. Niestety, projekt zniosl przyslowiowe
kubiczne jajo i caly zespol wywalono z hukiem. Wtedy K.B. powiedzial
owe pamietne slowa. Byly one cytowane wszedzie na Internecie; poszukaj
sobie.
A.L.
A.L.
<pio...@gmail.com> wrote:
>
>To juz twoja sprawa jakie masz relacje z klientem.
>Agile ma wiele technik, ktore pomagaja zapobiegac wodzeniu za nos.
>Proponuje poczytac i sprobowac.
>
>Piotr
Prosze Pana, jak Pan juz skonczy studia i zdobedzie troche praktyki,
to wtedy neich Pan sie wypowie na temat "klienta".
A.L.
A.L.
<pio...@gmail.com> wrote:
>
>
>1. To znowu "urban myth". Oczywiscie, ze agile stosuje sie w duzych
>projektach.
>Przyklady: Simens, Bank of America, i wiele innych.
>
Niech Pan nei pieprzy glupot.
A.L.
Paweł Kierski
Argumenty się skończyły? OK - udowadnianie, że czegoś nie ma (np.
Siemens nie stosuje agile) jest w zasadzie niemożliwe. Ale jakimś
argumentem byłoby napisanie, jakie metodologie przykładowy Siemens
stosuje, i że nie są one agile.
Inna odpowiedź to pieprzenie bez sensu. Proszę Pana.
Michal Kleczek
Jakie k..wa planowanie? Na podstawie czego? "User stories"? "Architectural
spikes"? Na 6tyg (2 iteracje po 3 tyg) do przodu? Przeciez Agile Z
ZALOZENIA wyklucza planowanie dlugookresowe!!! Jak okreslamy "punkty
milowe"? Iloscia "user stories"? Jak mozna w ogole planowac cokolwiek nie
majac sprecyzowanego CELU PROJEKTU? A gdzie jest planowanie BUDZETU? Gdzie
jest identyfikacja, wycena i minimalizowanie ryzyka?
Przeciez to mozna wymieniac bez konca.
Promotorzy agile - z mojego doswiadczenia - nie chca odpowiadac na te
pytania. Slysze ciagle
o "praktykach", "synergii", "atmosferze", "adaptacji" etc.
To nie jest inzynieria - to jest myslenie magiczne.
Chyba mi sie znudzil ten watek...
Michal
Piotr Gabryanczyk
Wystarczy, ze twoj klient poczyta statystyki.
Np. tu:
http://www.ambysoft.com/surveys/success2007.html
Michal Kleczek
>>Nie cytuj wypowiedzi wyrwanej z kontekstu.
>>Podaj zrodlo.
>
> Zarujesz, co nei?... Albo jestes zielony
>
> K.B. prowadzil project C3 dla bodajrze, Chrysler Corporation, i tam
> wlasnei tworczo zastosowal XP. Niestety, projekt zniosl przyslowiowe
> kubiczne jajo i caly zespol wywalono z hukiem. Wtedy K.B. powiedzial
> owe pamietne slowa. Byly one cytowane wszedzie na Internecie; poszukaj
> sobie.
Ja tez to kiedys slyszalem, ale przed chwila - w sumie nie wiem po co -
wrzucilem zdanie w googla. Jeden hit - jakies archiwum usenetu - zdanie
jest zacytowane w poscie podpisanym... "A.L." :)
>
> A.L.
Michal
Piotr Gabryanczyk
> A.L. w wiadomości <qh0lt3tdt1jqi5fbbrdrqnhta5m20oi...@4ax.com> pisze:
>
> > On Fri, 14 Mar 2008 06:18:08 -0700 (PDT), Piotr Gabryanczyk
> > <piot...@gmail.com> wrote:
>
> > >1. To znowu "urban myth". Oczywiscie, ze agile stosuje sie w duzych
> > >projektach.
> > >Przyklady: Simens, Bank of America, i wiele innych.
>
> > Niech Pan nei pieprzy glupot.
>
> Argumenty się skończyły? OK - udowadnianie, że czegoś nie ma (np.
> Siemens nie stosuje agile) jest w zasadzie niemożliwe. Ale jakimś
> argumentem byłoby napisanie, jakie metodologie przykładowy Siemens
> stosuje, i że nie są one agile.
>
> Inna odpowiedź to pieprzenie bez sensu. Proszę Pana.
>
> --
> Paweł Kierski
> dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl,
> albo koniecznie chcesz obejść moje filtry 8-)
W zasadzie nie powinienem tego komentowac bo to demagogia.
Co do Siemens'a, to nie ma czego udowadniac wystarczy spojrzec tu:
http://www.romanpichler.com/publication/pdfs/GoingAgileAtSiemensCommunicationsUK.pdf
W BofA sam pracowalem i widzialem je osobiscie, z reszta wystarczy
"pogooglowac".
Pozatym sa setki firm w ktorych sie powiodlo wiec nie bede sie spieral
o drobiazgi.
Piotr
Piotr Gabryanczyk
To nie prawda. Kolejny raz musze powiedziec to kolejna "urban legend"
o agile.
Ludzie zacznijcie czytac o agile, zanim zbudujecie sobie zle
wyobrazenie agile ze strzepkow informacji!
Agile nie wyklucza planowania dlugookresowego - oczywiscie, ze trzeba.
Tak jak powiedziales, zeby zidentyfikowac ryzyko i przedsiewziac kroki
zapobiegawcze.
Agile mowi tylko ze planowanie jest tym bardziej precyzyjne im wiecej
wiesz o projekcie.
Dlatego dlugookresowe planowanie dokladnej funkcjonalnosci o
okreslonej jakosci nie ma sensu, bo ma zbyt wiele niewiadomych.
Piotr
A.L.
wrote:
Myslisz ze ja bede dla ciebie tego szukal?...
A.L.
A.L.
<pio...@gmail.com> wrote:
>Wystarczy, ze twoj klient poczyta statystyki.
>Np. tu:
>http://www.ambysoft.com/surveys/success2007.html
Wyglupiasz zie?... Ale to kiepski wyglup...
A.L.
Piotr Gabryanczyk
Postarajmy sie porozmawiac tak by szanowac sie wzajemnie mimo roznych
pogladow.
Chodzilo mi o zrodlo po to zeby kazdy zainteresowany mogl to
przeczytac w kontekscie.
Piotr
Michal Kleczek
Eee, ja tego nie potrzebuje znalezc... Bardziej widze tu jakis spisek
ukrywajacy ryse na "agile". Google tez jest z nimi.
>
> A.L.
Michal
A.L.
wrote:
>A.L. w wiadomości <qh0lt3tdt1jqi5fbb...@4ax.com> pisze:
>> On Fri, 14 Mar 2008 06:18:08 -0700 (PDT), Piotr Gabryanczyk
>> <pio...@gmail.com> wrote:
>>
>> >
>> >
>> >1. To znowu "urban myth". Oczywiscie, ze agile stosuje sie w duzych
>> >projektach.
>> >Przyklady: Simens, Bank of America, i wiele innych.
>> >
>>
>> Niech Pan nei pieprzy glupot.
>
> Argumenty się skończyły? OK - udowadnianie, że czegoś nie ma (np.
>Siemens nie stosuje agile) jest w zasadzie niemożliwe. Ale jakimś
>argumentem byłoby napisanie, jakie metodologie przykładowy Siemens
>stosuje, i że nie są one agile.
>
Prosze Pana, produkuje sie tu paru "expertow" ktorzy o robieniu
profesjonalnego oprogrammowania maja pojecie z lektury Mlodego
Technika
Ja przypadkiem wiem jak sie robi doprogramowanie dla bankow, i
przypadkiem wiem ze przesuniecie guzika na formie op pol centymetra
wymaga podpisu 3 managerow i 50 stron dokumentacji. Pieniadze to nei
zarty, i wiele rzeczy robionych przez banki jest regulowana przepisami
Rzadowymi ktore to przepisy formuluja rozniez wymagania odnosnie
programowania i standardow dokumentacji i tak dalej.
Wiec niech Pan G. nie opowiada mi o "agile" w bankach.
Podobnie w przemysle telekomunikacyjnym dla ktorego mi sie zdarzylo
pracowac - to nei sa zarty, a software to nei badziewie.
Podobnie to co robie teraz - u sredniej wielkosci klienta software
pzretwarza pare milionow dolarow dziennie, a jak przestanie
porzetwarzac to dzienne straty beda mialy jedno zero wiecej. Ciekawe
kto pojdzie na "agile", "negocjacje z klientem w trakcie projektu",
brak dokumentacji projektu, brak dokumentacji oprogramowania i tak
dalej.
Wiec meich mi Pan G. nie opwiada bzdur, a Pan niech mu nie sekunduje
bo macie Panowie o tym takei pojecie jak ja o zyciu na Marsie
A.L.
Freddie28
> Kanalizacyjnego.
>
> Z faktu ze 99% aplikacji MISO meic baze danych, nei wynika wcale ze to
> co jest wokol bazy danych to jest proste GUI.
www.google.pl - fraza do wyszukania "słownik PL". Inni już to mają więc
może i pora żebyś i ty sobie zainstalował i przestał kaleczyć mowę
ojczystą.
Piotr Gabryanczyk
Apropos,
Jak ty sie nazywasz A.L. ?
Smialo wyrazasz swoje opinie - chyba nie wstydzisz sie powiedziec jak
sie nazywasz?
Michal Kleczek
Sorry - to, co jest napisane wyzej oznacza ze tzw. "agile" to jest belkot
bez zadnej konkretnej tresci. "Nie wyklucza planowania
dlugookresowego", "oczywiscie trzeba zarzadzac ryzykiem" i -
najlepsze - "planowanie jest tym bardziej precyzyjne im wiecej wiesz o
projekcie".
Ja sie nie pytam "czy" tylko "JAK".
Ja sie z tego wypisuje.
> Piotr
Michal
Piotr Gabryanczyk
> On Fri, 14 Mar 2008 14:57:40 +0100, Paweł Kierski <n...@pkierski.net>
> wrote:
>
>
>
> >A.L. w wiadomości <qh0lt3tdt1jqi5fbbrdrqnhta5m20oi...@4ax.com> pisze:
Coz jesli tego trzeba zeby przekonac A.L. to wytaczam:
Tak sie sklada ze od ladnych paru lat pracuje w bankach
inwestycyjnych, w ktorych nacisniecie jednego guzika powoduje
wykonanie transakcji nie na miliony ale na setki milionow. Pewnie sie
zdziwisz A.L. ale te instytucje stosuja agile od wielu lat.
Pracowalem rowniez w kilku bankach w Polsce - rzeczywiscie nie
wygladalo to bardzo rozowo. Nie mniej jednak jest tam sporo ludzi, z
ktorymi swietnie sie wspolpracuje i predzej czy pozniej i agile tam
zawita.
Piotr
Stachu 'Dozzie' K.
>>> >1. To znowu "urban myth". Oczywiscie, ze agile stosuje sie w duzych
>>> >projektach.
>>> >Przyklady: Simens, Bank of America, i wiele innych.
>>> >
>>>
>>> Niech Pan nei pieprzy glupot.
>>
>> Argumenty się skończyły? OK - udowadnianie, że czegoś nie ma (np.
>>Siemens nie stosuje agile) jest w zasadzie niemożliwe. Ale jakimś
>>argumentem byłoby napisanie, jakie metodologie przykładowy Siemens
>>stosuje, i że nie są one agile.
>>
>
> Prosze Pana, produkuje sie tu paru "expertow" ktorzy o robieniu
> profesjonalnego oprogrammowania maja pojecie z lektury Mlodego
> Technika
>
> Ja przypadkiem wiem jak sie robi doprogramowanie dla bankow, i
> przypadkiem wiem ze przesuniecie guzika na formie op pol centymetra
> wymaga podpisu 3 managerow i 50 stron dokumentacji.
Ja również przypadkiem wiem jak się robi oprogramowanie dla banków. Wiem
od osoby, która pracuje w zespole programistów takiego banku. Kod
takiego oprogramowania jest tragiczny, nieudokumentowany i utrzymywany
przez osoby z syndromami ale-o-co-chodzi-przecież-działa,
a-w-czym-przeszkadza-generic-value
i dobry-programista-nie-potrzebuje-dokumentacji. Tak więc trochę nie na
miejscu jest wyciąganie banku jako przykładu dobrego rozwoju softu.
--
Secunia non olet.
Stanislaw Klekot
A.L.
wrote:
>Sorry - to, co jest napisane wyzej oznacza ze tzw. "agile" to jest belkot
>bez zadnej konkretnej tresci. "Nie wyklucza planowania
>dlugookresowego", "oczywiscie trzeba zarzadzac ryzykiem" i -
>najlepsze - "planowanie jest tym bardziej precyzyjne im wiecej wiesz o
>projekcie".
>Ja sie nie pytam "czy" tylko "JAK".
>
>Ja sie z tego wypisuje.
>
To jest bardzo prosye:
a) Jak masz burdel w projekcie
b) jak nei wiacomo co kto robi,
c) jak nei wiadomo co zrobiono a co tzreba zrobic
d) jak nei wiadomo kiedy to sie skonczy
e) jak nei wiadomo czym to sie skonczy
f) jak nei wiadomo do czego jest klasa MojZabDabDupa robi i dlaczego
ma metode aleJaja() i nie wiadomo czy ktos tej klasy uzywa
g) nie wiadomo czym zamuje sie team member Jas z team memberka Zosia
oprocz macania sie w kuchni
TO WLASNIE UZYWASZ METODOLOGII AGILE A MOZE NAWET EXTREME PROGRAMMING
A.L.
Michał 'Khorne' Rzechonek
> Niestety to jest powszechne, ze ludzie wprowadzaja kilka praktyk
> agile, bez wiary w sukces, przekrecaja je, robia to na "pol gwizdka".
> Winia oni pozniej agile za niepowodzenie ich projektu. Psuja oni
> niestety reputacje calego ruchu agile.
Prawda. Sprawa jest trochę podobna do podatku "liniowego",
który dorobił się "złej" etykietki, natomiast podatek "proporcjonalny"
jest już odbierany pozytywnie.
Kłopot polega na tym, że termin "agile" jest najczęściej używany
przez menedżerów do reklamowania swojej firmy i opowiadania
jacy to oni nie są zajebiści. A potem się okazuje, że tego
nie można zrobić w stylu agile, bo cośtam, tego też nie, bo klient,
tego też nie, bo szef się nie zgadza... I lądujemy w dupie.
Dlatego właśnie jestem przeciwnikiem stosowania tego słowa
do opisu "od dawna znanych i stosowanych praktyk które
niedawno zostały skodyfikowane".
--
Khorne
A.L.
<doz...@dynamit.im.pwr.wroc.pl.nospam> wrote:
>Ja również przypadkiem wiem jak się robi oprogramowanie dla banków. Wiem
>od osoby, która pracuje w zespole programistów takiego banku. Kod
>takiego oprogramowania jest tragiczny, nieudokumentowany i utrzymywany
>przez osoby z syndromami ale-o-co-chodzi-przecież-działa,
>a-w-czym-przeszkadza-generic-value
>i dobry-programista-nie-potrzebuje-dokumentacji. Tak więc trochę nie na
>miejscu jest wyciąganie banku jako przykładu dobrego rozwoju softu.
Wie Pan, jak wszyscy w Polsc ebija zony, to nie znaczy ze ja musze
tez. Poza tym, jednak, ja Pana opowiesci miedzy bajki wloze.
A.L.
A.L.
<pio...@gmail.com> wrote:
>
>Coz jesli tego trzeba zeby przekonac A.L. to wytaczam:
>Tak sie sklada ze od ladnych paru lat pracuje w bankach
>inwestycyjnych, w ktorych nacisniecie jednego guzika powoduje
>wykonanie transakcji nie na miliony ale na setki milionow. Pewnie sie
>zdziwisz A.L. ale te instytucje stosuja agile od wielu lat.
>
>Pracowalem rowniez w kilku bankach w Polsce - rzeczywiscie nie
>wygladalo to bardzo rozowo. Nie mniej jednak jest tam sporo ludzi, z
>ktorymi swietnie sie wspolpracuje i predzej czy pozniej i agile tam
>zawita.
>
Przpraszam, ale pozwole sobie nie uwierzyc. Niech Pan raczej
skoncentruje sie na ankiecie do swojej pracy licencjackiej, od czago
zaczal Pan ten watek
A.L.
Stachu 'Dozzie' K.
A ja twoje. Ty nawet nazwiskiem się nie podpisujesz, a twierdzisz że
masz do czynienia z dużymi firmami.
Piotr Gabryanczyk
> On Fri, 14 Mar 2008 07:59:11 -0700 (PDT), Piotr Gabryanczyk
>
Przedstaw sie jesli masz odwage szkalowac innych.
Piotr Gabryanczyk
> On Fri, 14 Mar 2008 15:43:04 +0100, Michal Kleczek <klek...@gmail.com>
Ale nic z tego co wymieniles nie jest agile.
Apropos g) to chyba przegiales. W stanach wykopaliby cie z tej listy.
Wojciech Muła
> Wie Pan, jak wszyscy w Polsc ebija zony, to nie znaczy ze ja musze
> tez. Poza tym, jednak, ja Pana opowiesci miedzy bajki wloze.
Nie docenia Pan polskich programistów. Mój znajomy miał na studiach
praktyki w firmie, która produkuje oprogramowanie dla banków -- mówił,
że w kodzie (notabene pisanym w C) poza informacją w nagłówku o
prawach autorskich i wersji program nie było śladu komentarza: nic,
zero, null.
w.
Wit Jakuczun
Piotr Gabryanczyk <pio...@gmail.com> napisał(a):
> Ale nic z tego co wymieniles nie jest agile.
> Apropos g) to chyba przegiales. W stanach wykopaliby cie z tej listy.
Z tej listy nie da sie wykopac. Nawet jakby byla w stanach...
Zdrowia
--
[ Wit Jakuczun <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions http://www.wlogsolutions.com ]
Michal Kleczek
> Michal Kleczek wrote:
>>>>>> A co ma MVC do bazy danych?
>>>>> 'M' jest od modelu danych. W gruncie rzeczy w systemie
>>>>> bazodanowym można składować zarówno model, jak i kontroler oraz
>>>>> widok.
>>>> Przepraszam, ze jestem upierdliwy, ale co to jest "system
>>>> bazodanowy"?
>>> Podsystem zarządzania bazą danych: system plików, system zarządzania
>>> relacyjną bazą danych, transakcyjny system zarządzania relacyjną bazą
>>> danych, system zarządzania bazą danych zorientowany na obiekty etc.
>>
>> Chcialem sie upewnic, ze chodzi o DBMS. DBMS jak to DBMS jest od
>> zarzadzania bazami danych, a w bazie danych - jak to w bazie danych - sa
>> dane. Nie ma tam ani modelu, ani kontrolera, ani widoku. :)
>
> Taaa, powiedz to twórcom Oracle Application Express ;>
Odpowiedz krotka: oni to dobrze wiedza - nie trzeba im mowic.
Odpowiedz dluzsza:
Tego typu narzedzia tylko chowaja problemy pod dywan. Naiwnym sie wydaje,
ze "wszystko jest w bazie danych wiec jest cool". Identycznie zreszta, jak
gosciom mowiacym "kupilismy ESB - rozwiazalismy problemy integracji".
Np. nie mam zielonego pojecia, jak ten software rozwiazuje problem
stworzenia aplikacji pozwalajacej na korzystanie z bazy danych ludziom
niewidomym. W takiej aplikacji tez jest "MVC".
>
> Pozdrawiam,
> Wojciech Malinowski
Michal
Michal Przybylek
> Kent BEck, cytuje: "Yes, project failed, but methodology was right".
Nie wiem czy czegoś dziwnego można się doszukać w tym stwierdzeniu. Przecież
w socjalizmie pracuje się nie po to, aby robić kasę. W socjalizmie pracuje
się dla samej pracy. Praca jest największą wartością. Jeżeli metodologia
sprawia, że przyjemniej się ludziom pracuje, to metodologia jest właściwa.
Nie dajmy się otumanić tym chorym kapitalistycznym świniom, które wszędzie
widzą tylko kasę i wszystko robią dla kasy. Kasa jest efektem ubocznym
pracy. I to, na szczęście, nie zawsze. Niech żyje ,,pair programming''!
Oczywiście - tylko w parach mieszanych :-)
mp
Michal Kleczek
> Michal Kleczek wrote:
>
> Taaa, powiedz to twórcom Oracle Application Express ;>
Tak na marginesie: na jakiej podstawie (tzn. w jaki sposob) "agile team"
podjemuje decyzje o uzywaniu lub nieuzywaniu tego rodzaju narzedzia?
>
> Pozdrawiam,
> Wojciech Malinowski
Michal
Piotr Dembiński
[...]
> Kłopot polega na tym, że termin "agile" jest najczęściej używany
> przez menedżerów do reklamowania swojej firmy i opowiadania jacy to
> oni nie są zajebiści.
Agility jako łatwość dostosowania się, elastyczność i błyskotliwość --
per analogia do zwinności w sferze fizycznej, samo określenie sugeruje
zwinność organizacyjną.
--
http://www.piotr.dembiński.prv.pl
Piotr Dembiński
[...]
> Kent BEck, cytuje: "Yes, project failed, but methodology was right".
Spora odwaga. Większość speców od zarządzania przedsięwzięciami
programistycznymi zasłania się złą implementacją metodyki.
Piotr Dembiński
[...]
> Bardziej widze tu jakis spisek ukrywajacy ryse na "agile".
Na Agile jest cała masa rys. W gruncie rzeczy -- jeśli porównywać
tradycyjne metodyki do idealnych konstruktów matematycznych, to IMO
metodyka Agile byłaby strukturą fraktalną.
--
http://www.piotr.dembiński.prv.pl
Piotr Dembiński
[...]
> Niech żyje ,,pair programming''!
>
> Oczywiście - tylko w parach mieszanych :-)
Gej z hetero?
Andrzej
> Jesli potrzebujesz wiecej zrodel, lub masz pytania na temat agile
> napisz do mnie na priva,
Witam, jeśli można tutaj, to bardzo bym prosił (materiały/linki). Po to
są archiwa google, aby potomni nie musieli nowych wątków rozpoczynać o
tej samej treści :-)
Dzięki, pzdr.