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! :)
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.
On Wed, 12 Mar 2008 09:55:14 -0700 (PDT), Piotr Gabryanczyk
<piot...@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.
On 12 Mar, 17:55, Piotr Gabryanczyk <piot...@gmail.com> wrote:
> 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.
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ł.
Seweryn Habdank-Wojewódzki w wiadomości <fr97hp$l8...@news.vectranet.pl> pisze: [...]
> > 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 n...@pkierski.net dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl, albo koniecznie chcesz obejść moje filtry 8-)
Paweł Kierski wrote: > Seweryn Habdank-Wojewódzki w wiadomości <fr97hp$l8...@news.vectranet.pl> > pisze: > [...] >> > 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.
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 Kleczek w wiadomości <frasl5$pl...@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. 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-)
-- Paweł Kierski n...@pkierski.net dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl, albo koniecznie chcesz obejść moje filtry 8-)
> 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.
Paweł Kierski wrote: > Michal Kleczek w wiadomości <frasl5$pl...@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 Kleczek w wiadomości <frasl5$pl...@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.
>> 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.
>>> 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 Kleczek w wiadomości <fravk2$72...@mx1.internetia.pl> pisze: [...]
> > 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 n...@pkierski.net dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl, albo koniecznie chcesz obejść moje filtry 8-)
Michal Kleczek w wiadomości <frb1vj$bo...@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.
> [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.
-- Paweł Kierski n...@pkierski.net dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl, albo koniecznie chcesz obejść moje filtry 8-)
>> 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"?
> Agile i XP to nic nie znaczące "buzzwords" służące w 90% za
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.
Michal Kleczek w wiadomości <frb3pf$tc...@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".
-- Paweł Kierski n...@pkierski.net dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl, albo koniecznie chcesz obejść moje filtry 8-)
Paweł Kierski wrote: > Michal Kleczek w wiadomości <frb1vj$bo...@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".
Paweł Kierski wrote: > Michal Kleczek w wiadomości <frb3pf$tc...@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 Kleczek w wiadomości <frb4m5$8q...@mx1.internetia.pl> pisze: [...]
> >> 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 n...@pkierski.net dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl, albo koniecznie chcesz obejść moje filtry 8-)
Michal Kleczek w wiadomości <frb4t0$kp...@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?
-- Paweł Kierski n...@pkierski.net dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl, albo koniecznie chcesz obejść moje filtry 8-)
Paweł Kierski wrote: > Michal Kleczek w wiadomości <frb4t0$kp...@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?
Michal Kleczek w wiadomości <frb5i7$v1...@mx1.internetia.pl> pisze:
> Paweł Kierski wrote:
> > Michal Kleczek w wiadomości <frb4t0$kp...@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?
On Thu, 13 Mar 2008 13:05:03 +0100, Paweł Kierski <n...@pkierski.net> wrote:
>Michal Kleczek w wiadomości <frb4t0$kp...@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!"
Paweł Kierski wrote: > Michal Kleczek w wiadomości <frb5i7$v1...@mx1.internetia.pl> pisze: >> Paweł Kierski wrote:
>> > Michal Kleczek w wiadomości <frb4t0$kp...@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.L. w wiadomości <t77it31lflv8fcvmcmu4lbobjavpddg...@4ax.com> pisze: [...]
> "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-)
-- Paweł Kierski n...@pkierski.net dodaj "[nomorespam]" w temacie jeśli piszesz z domeny innej niż .pl, albo koniecznie chcesz obejść moje filtry 8-)
|
