On Tuesday, July 24, 2012 12:47:27 PM UTC+1, Andrzej Jarzabek wrote:
> On Tuesday, 24 July 2012 08:55:21 UTC+1, Roman W wrote: >
> > Ale TDD to nie Agile. Mozna miec TDD bez Agile.
>
> Och, na tej zasadzie cokolwiek to nie Agile i Agile to nie cokolwiek.
> Można mieć TDD bez agile i agile bez TDD, można mieć iteracje bez
> agile i agile bez iteracji i tak dalej. Nie ma żadnej konkretnej praktyki,
> która musi koniecznie być w agile żeby było agile i nie ma żadnej
> konkretnej praktyki, która powoduje, że jesteś agile.

No ale wiesz, z tego wynika, ze Agile to religia.

RW

do góry

Użytkownik <l...@g...com> napisał:

> Myślę, że to dobra metodyka, zwłaszcza w zespołach o małym doświadczeniu.

IMHO jest dokladnie odwrotnie.
Naprawde doswiadczone osoby (mimo wszelakich Agiles i innych SCRUMow) zwykle sie
dogadaja.
W zespolach niedoswiadczonych taki kolejny "socjalizm" (niczym GPL:) gdzie to
deccyduje
"wiekszosc wyborcza" moze wylac dziecko z kapiela, bo czasenm to wlasnie ten jeden
doswiadczony ma racje, a nie cala "demokratyczna" reszta.
IMHO jesli juz to SCRUM nadaje sie do utrzymania _juz gotowego wyrobu_,
czyli mowiac po ludzku - poprawy bledow (bo tu niekedy wprzega sie
przeintelektualizowane stare metodyki z calym ich nadmiarowym bagazem).
W tworzeniu nowych powaznych produktow/systemow to cale
"spryciarstwo" IMHO w szerszej czasowo perspektywie zwyczajnie sie nie nadaje.

PS: Owszem, jestem ostroznym zwolennikiem pair programming (zaraz mnie A.L.
zjedzie:),
ale w przypadku np. przyjecia nowego neidoswiadczonego pracownika (intern itp).
Wtedy az przykro niekedy patrzec, ze nie ma taki gosc swego "mentora/mistrza"
coby goszybko wdrozyl w zastane srodowisko i na skroty pokazal "osochodzi u
nas".
Czyli taki zdrowy uklad. "Mistrz" (czasowo) wdraza/uczy "czeladnika", ale nic
ponad to.

PS1: Dla mych przyszlych pracodawcow:
"Oświadczam, że pomimo iz mam swoje w/w zdanie, absolutnie się z nim nie zgadzam" :)

AK


AK

do góry

Użytkownik "Adam Przybyla" <a...@r...pl> napisał:

> dzieki TDD udalo mi sie to prawie od razu zauwazyc i zwalczyc.
> To naprawde dziala. Z powazaniem

TDD ?
A to aby czasem nie zwykle stare dobre (od zawsze znane) testy integracyjne ?

AK

do góry

Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:

> nie ma żadnej konkretnej praktyki, która powoduje, że jesteś agile.

Jest taka praktyka.
Wtedy gdy uda mi się odzyskać choć część wypłaty...

AK

do góry

W dniu 2012-07-24 15:24, AK pisze:
> Użytkownik <l...@g...com> napisał:
>
>> Myślę, że to dobra metodyka, zwłaszcza w zespołach o małym doświadczeniu.
>
> IMHO jest dokladnie odwrotnie.
> Naprawde doswiadczone osoby (mimo wszelakich Agiles i innych SCRUMow)
> zwykle sie dogadaja.
> W zespolach niedoswiadczonych taki kolejny "socjalizm" (niczym GPL:)
> gdzie to deccyduje
> "wiekszosc wyborcza" moze wylac dziecko z kapiela, bo czasenm to wlasnie
> ten jeden
> doswiadczony ma racje, a nie cala "demokratyczna" reszta.

Jest nawet takie założenie w Scrumie - kompetencje zespołu muszą być
wystarczające. Czyli w praktyce - wysokie.

> IMHO jesli juz to SCRUM nadaje sie do utrzymania _juz gotowego wyrobu_,
> czyli mowiac po ludzku - poprawy bledow (bo tu niekedy wprzega sie
> przeintelektualizowane stare metodyki z calym ich nadmiarowym bagazem).
> W tworzeniu nowych powaznych produktow/systemow to cale
> "spryciarstwo" IMHO w szerszej czasowo perspektywie zwyczajnie sie nie
> nadaje.

Z doświadczenia - nie ma znaczenia. Nawet nieco odwrotnie - utrzymywanie
aplikacji, która ma błędy wyskakujące jak diabełek z pudełka,
a dodatkowo kiepsko napisanej (czytaj - trudnej do zmiany) jest
w Scrumie trudne. Z definicji nie da się takich zdarzeń zaplanować,
również planowanie poprawek jest kiepskie, nawet w horyzoncie krótkich
sprintów.

W długiej perspektywie tworzenia projektu - znów z doświadczenia -
okazuje się, że wiele biznesowych "must to have" po miesiącu (na
początku następnego sprintu) okazuje się być już nie takie "must" 8-)
A to znaczy, że nie pisaliśmy kodu do szuflady.

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

do góry

Dnia Tue, 24 Jul 2012 07:28:10 +0000, Adam Przybyla napisal:

> To naprawde dziala.

Wiele rzeczy działa, a nie trzeba ich stosować wszędzie.

Edek

do góry

Użytkownik "Paweł Kierski" <n...@p...net> napisał:

> Z doświadczenia - nie ma znaczenia. Nawet nieco odwrotnie - utrzymywanie
> aplikacji, która ma błędy wyskakujące jak diabełek z pudełka,

Mowilem o sytuacji klasycznej czyli "planowanych" fixes/small enhancements
(niekiedy wiele lat "planowanych":) czyli gdy np. ClearQuest rządzi
developerami supportu.

AK

do góry

On Tuesday, July 24, 2012 2:53:40 PM UTC+1, Paweł Kierski wrote:

> Jest nawet takie za�o�enie w Scrumie - kompetencje zespo�u musz� by�
> wystarczaj�ce. Czyli w praktyce - wysokie.

Troche to przypomina przepis na zupe z gwozdzia.

RW

do góry

W dniu 2012-07-24 16:18, Roman W pisze:
> On Tuesday, July 24, 2012 2:53:40 PM UTC+1, Paweł Kierski wrote:
>
>> Jest nawet takie za�o�enie w Scrumie - kompetencje zespo�u musz� by�
>> wystarczaj�ce. Czyli w praktyce - wysokie.
>
> Troche to przypomina przepis na zupe z gwozdzia.

Albo tautologię, która - o dziwo - często nie jest brana pod uwagę:
"Żeby mieć produkt, trzeba mieć ludzi, którzy potrafią go stworzyć." -
tylko tyle i aż tyle. Wprawdzie Comarch potrafi to robić inaczej, ale
to chyba wyjątek od reguły.

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

do góry

W dniu 2012-07-24 16:03, AK pisze:
> Użytkownik "Paweł Kierski" <n...@p...net> napisał:
>
>> Z doświadczenia - nie ma znaczenia. Nawet nieco odwrotnie - utrzymywanie
>> aplikacji, która ma błędy wyskakujące jak diabełek z pudełka,
>
> Mowilem o sytuacji klasycznej czyli "planowanych" fixes/small enhancements
> (niekiedy wiele lat "planowanych":) czyli gdy np. ClearQuest rządzi
> developerami supportu.

To żaden problem - skoro wiadomo, to traktuje się te poprawki jak każde
inne ficzery do zaimplemetowania. Można pewnie wtedy znacznie skrócić
sprint, jeśli granulacja zadań jest lepsza.

Do klasycznego ogarniania ciągłego "pożaru w burdelu" lepszy wydaje się
Kanban.

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

do góry