On 24/01/2010 19:21, Er wrote:
> crtm81 pisze:
> > Moj tez sie nie zna, ale uwaza sie za znawce. Przychodzi do mnie z
> > jakims zadaniem i sie kompromituje.
>
> Czy my nie pracujemy razem?
> ;)

Mam nadzieje, ze nie jestes moim szefem :)

do góry

crtm81 pisze:
> On 24/01/2010 19:21, Er wrote:
>> crtm81 pisze:
>> > Moj tez sie nie zna, ale uwaza sie za znawce. Przychodzi do mnie z
>> > jakims zadaniem i sie kompromituje.
>>
>> Czy my nie pracujemy razem?
>> ;)
>
> Mam nadzieje, ze nie jestes moim szefem :)

Zmierzałem raczej do tego, że może mamy wspólnego szefa ;)

do góry

W dniu 2010-01-24 14:16, Depesz pisze:
> Uzytkownik "crtm81"<w...@d...rada.pl> napisal w wiadomosci
> news:hjfj5q$5or$1@achot.icm.edu.pl...
>> Witam,
>>
> Uciekaj jak najszybciej z tej firmy bo nic dobrego z tego nie wyniknie. Przy
> takiej polityce firmy, zarabiasz na siebie (i ofc na szefa) zrealizowanymi
> projektami. Jakosc wykonanej pracy ma mniejsze znaczenie, liczy sie tylko
> ilosc zamowien spadajacych na firme. W takim przypadku ogranicza sie lub
> calkowicie rezygnuje z niektorych etapow wytwarzania oprogramowania
> (zbieranie wymagan, testowanie itp), byle tylko zrealizowac wiecej zamowien.
> Programista sam sobie jest sterem, zeglarzem i okretem, bo firmie nie oplaca
> sie stworzyc zespolu projektowego z podzialem rol.

Na początek zastrzegam - też lubię pracować w zespole, w którym jest
czas, miejsce i pieniądze dla dobrych praktyk: podziału ról,
testowania, zbierania wymagań i ich biznesowej selekcji.

A teraz uwaga, będzie herezja: model zbliżony do "zróbmy jakkolwiek,
cokolwiek, byle najdalej na dzisiaj" w niektórych przypadkach daje
biznesowy sukces, przynajmniej w bliskim horyzoncie. Oczywiście na
dłuższą metę nie da się tak rozwijać projektu, który ma jako tako
ustalone wymagania i odbiorcę - w końcu utrzymywanie jakość, kosz
utrzymania projektu i prób jego rozwoju staną się zaporowe dla klienta.
Ale czasem dokładnie tego zleceniodawca/pracodawca od nas może wymagać.
Praca z tak ograniczonymi zasobami czasu i informacji też może być
ciekawa, ale... nie na dłuższą metę. No i pochwalić się dobrą robotą
raczej nie będzie można, a i o rozwoju własnym lepiej zapomnieć.

--
Paweł Kierski
n...@p...net

do góry

W dniu 2010-01-25 23:02, Paweł Kierski pisze:
> Na początek zastrzegam - też lubię pracować w zespole, w którym jest
> czas, miejsce i pieniądze dla dobrych praktyk: podziału ról,
> testowania, zbierania wymagań i ich biznesowej selekcji.
>
> A teraz uwaga, będzie herezja: model zbliżony do "zróbmy jakkolwiek,
> cokolwiek, byle najdalej na dzisiaj" w niektórych przypadkach daje

Ja od paru lat pracuje w metodologi agile - cos podobnego do extreme
programing i nie narzekam. Ale cel chocby ustnie - emailem zawsze
okreslamy i calosc projektu iterujemy od kad dolaczylem do zespolu.

do góry

arturbac pisze:
> W dniu 2010-01-25 23:02, Paweł Kierski pisze:
>> Na początek zastrzegam - też lubię pracować w zespole, w którym jest
>> czas, miejsce i pieniądze dla dobrych praktyk: podziału ról,
>> testowania, zbierania wymagań i ich biznesowej selekcji.
>>
>> A teraz uwaga, będzie herezja: model zbliżony do "zróbmy jakkolwiek,
>> cokolwiek, byle najdalej na dzisiaj" w niektórych przypadkach daje
>
> Ja od paru lat pracuje w metodologi agile - cos podobnego do extreme
> programing i nie narzekam.

O ile XP to konkretna spisana metodyka, to "agile" jest grupą, kategorią
metodyk i warto by powiedzieć w której konkretnie.

Nie weź tego zbyt osobiście, ale agile to szalenie wygodne hasło,
wszędzie gdzie nie mam żadnej metody(-ki) można powiedziec "bo my
własnie pracujemy w agile", "pracujemy w metodzie 'podobnej' do XP".
Jak mówi reklama, "prawie" robi różnicę.

Co nie zmienia faktu, że są tacy którzy rzeczywiście używają
"ukonstytuowanych" XP lub innych konkretnych opisanych metod z grupy
'agile', ale te masy naciagające słowa jak z gumy popsuły znaczenie tego
słowa.

do góry

On 26/01/2010 07:36, Jacek Czerwinski wrote:

> O ile XP to konkretna spisana metodyka, to "agile" jest grupą, kategorią
> metodyk i warto by powiedzieć w której konkretnie.
>
> Nie weź tego zbyt osobiście, ale agile to szalenie wygodne hasło,
> wszędzie gdzie nie mam żadnej metody(-ki) można powiedziec "bo my
> własnie pracujemy w agile", "pracujemy w metodzie 'podobnej' do XP".
> Jak mówi reklama, "prawie" robi różnicę.

My pracujemy wg. metody eXtreme Working :)
W znaczeniu doslownym oczywiscie

"Prawie" robi roznice, ale lepsze to niz totalny chaos.

do góry

On 25/01/2010 23:02, Paweł Kierski wrote:

> A teraz uwaga, będzie herezja: model zbliżony do "zróbmy jakkolwiek,
> cokolwiek, byle najdalej na dzisiaj" w niektórych przypadkach daje
> biznesowy sukces, przynajmniej w bliskim horyzoncie. Oczywiście na
> dłuższą metę nie da się tak rozwijać projektu, który ma jako tako
> ustalone wymagania i odbiorcę - w końcu utrzymywanie jakość, kosz
> utrzymania projektu i prób jego rozwoju staną się zaporowe dla klienta.
> Ale czasem dokładnie tego zleceniodawca/pracodawca od nas może wymagać.
> Praca z tak ograniczonymi zasobami czasu i informacji też może być
> ciekawa, ale... nie na dłuższą metę. No i pochwalić się dobrą robotą
> raczej nie będzie można, a i o rozwoju własnym lepiej zapomnieć.
>

IT to dosc ryzykowny biznes i takie praktyki sa uzasadnione na poczatku
projektu, chocby po to, zeby wybadac reakcje potencjalnych klientow.

Ale po jakims czasie, jak aplikacja zaczyna sie rozrastac, wypadaloby
pomyslec o jakosci. Nie tylko zwieksza to szanse na sprzedaz, ale tez
ulatwia rozwoj. Poza tym jezeli produkt ma szanse sie sprzedawac, to
pieniadze wydane na jego dopracowanie sa dobra inwestycja.

do góry

W dniu 2010-01-26 07:36, Jacek Czerwinski pisze:
> arturbac pisze:
>> Ja od paru lat pracuje w metodologi agile - cos podobnego do extreme
>> programing i nie narzekam.
>
> O ile XP to konkretna spisana metodyka, to "agile" jest grupą, kategorią
> metodyk i warto by powiedzieć w której konkretnie.

zdaje sobie sprawe.

> Nie weź tego zbyt osobiście, ale agile to szalenie wygodne hasło,

bo oddaje istote ?

> wszędzie gdzie nie mam żadnej metody(-ki) można powiedziec "bo my
> własnie pracujemy w agile", "pracujemy w metodzie 'podobnej' do XP".
> Jak mówi reklama, "prawie" robi różnicę.

No ale liczy sie cel -> zyje z tego, a nie to jak sie go osiaga i czy
zgodnie z ogolna ideologia dla nas bardziej liczy sie efektywnosc takze.

> Co nie zmienia faktu, że są tacy którzy rzeczywiście używają
> "ukonstytuowanych" XP lub innych konkretnych opisanych metod z grupy
> 'agile', ale te masy naciagające słowa jak z gumy popsuły znaczenie tego
> słowa.

Pracujemy w metodzie "podobnej do XP" wedle wlasnych regol.
Nie bedzie to dokladnie XP ani nic inengo bo team siedzi przed kompami w
EU i nikt nie wnika gdzie akurat jestem, Tricity, Kopenhadze czy Krakowie.
Poza tym pewne reguły są luźne bo nie liczy się u nas czas realizacji
ale perfekcja więc poślizgi w iteracjach są z góry "planowane". Nie
robimy w parach ale pojedynczo. W parach tylko elementy zazebiajace
rozne elementy skladowe. Jak w XP w wiekszosci przypadkow iteracji
rozwiazanie w ogole nie jest znane i dostepne publicznie. Testy nie sa
mozliwe do napsiania tj efektywniejsze jest testowanie interecyjne
produktu jako calosci, kierujac sie kryterium uzytkowym przyszlego
klienta, od tego sa osobni ludzie. Klientem jest rynek i przezycie
produktu ktory na nim jest wiec klient i kontakt z nim jest imitowany
przez nasza kreatywnosc w zakresie kierunkow rozwoju. Specyfikacja
najwazniejszych elementow powstaje, szczegolnie tam gdzie sa trudne do
ponownego wejscia w nie. itd itp.

Czyli : Dostosowanie do produktu, specyfiki pracy i celu naszego
dzialania a nie do metodologi, z reszta moje porownanie do XP jest tylko
porownaniem nikt nigdy miedzy nami tego tak nie nazywal.

Ale czy to oznacza ze moja metodologia pracy nie jest rodem z agile
dlatego że nie staram się trzymać konkretnej nazwanej ?

do góry

arturbac pisze:

>
> Ale czy to oznacza ze moja metodologia pracy nie jest rodem z agile
> dlatego że nie staram się trzymać konkretnej nazwanej ?

dzięki za wypowiedź. Osobicie dobrze się czuję, jeśli zasady (choćby
własne, jak w rodzinie) są jawne, dobrze jak spisane, bo jednak spisanie
ma coś z konstytucji.

Zasady są żywe (a nie martwe), jeśli dają siłę by powiedzieć "nie", np.
"ale jak mamy kodować, jak szkielet pakietów (klas, funkcjonalności ...
) nie został okreslony!".

Obrazowo: choćby własne, ale dające się przypiąć pinezką do szafy.

do góry

W dniu 2010-01-26 18:10, crtm81 pisze:
> On 25/01/2010 23:02, Paweł Kierski wrote:
>
>> A teraz uwaga, będzie herezja: model zbliżony do "zróbmy jakkolwiek,
>> cokolwiek, byle najdalej na dzisiaj" w niektórych przypadkach daje
>> biznesowy sukces, przynajmniej w bliskim horyzoncie. Oczywiście na
>> dłuższą metę nie da się tak rozwijać projektu, który ma jako tako
>> ustalone wymagania i odbiorcę - w końcu utrzymywanie jakość, kosz
>> utrzymania projektu i prób jego rozwoju staną się zaporowe dla klienta.
>> Ale czasem dokładnie tego zleceniodawca/pracodawca od nas może wymagać.
>> Praca z tak ograniczonymi zasobami czasu i informacji też może być
>> ciekawa, ale... nie na dłuższą metę. No i pochwalić się dobrą robotą
>> raczej nie będzie można, a i o rozwoju własnym lepiej zapomnieć.
>>
>
> IT to dosc ryzykowny biznes i takie praktyki sa uzasadnione na poczatku
> projektu, chocby po to, zeby wybadac reakcje potencjalnych klientow.
>
> Ale po jakims czasie, jak aplikacja zaczyna sie rozrastac, wypadaloby
> pomyslec o jakosci. Nie tylko zwieksza to szanse na sprzedaz, ale tez
> ulatwia rozwoj. Poza tym jezeli produkt ma szanse sie sprzedawac, to
> pieniadze wydane na jego dopracowanie sa dobra inwestycja.

Zgadzam się w ogólności. Chodziło mi raczej o pokazanie, że jest
możliwy taki model, w którym zarabia się niemal wyłącznie na projektach
"w stanie początkowym". I nie chodzi o startupy, które się pisze,
sprzedaje, a nabywca musi je przepisać gdy liczba użytkowników wzrasta
wykładniczo. Komu zależy na jakości kodu i jego procesu wytwórczego
w zabawkach klasy tamagochi?

--
Paweł Kierski
n...@p...net

do góry