Starší komentáře ke článku: Trocha toho extrémismu

Zpět na článek | Úvodní stránka Interval.cz

Avatar

Autor komentáře: jakub

Datum vložení: 9.12.2002 0:29:21

ja si myslim, ze popsane rika, jak by to asi bylo idealni (uprimne ta cirkulace programatoru by vsak vyzadovala velmi prisnou disciplinu, ale zaroven vyrovnanost znalosti jednotlivych programatoru).

Nicmene nemohu nezduraznit :) dulezitost prubezne konzultace s clovekem od klienta a idelane jeho castecnou zainteresovanost na projektu. Naprosto idealni je, pokud je to clovek, ktery zadani vymyslel a vi presne, co chce, aby program umel.

K te jednoduchosti me napada snad jen to, ze vzdy je lepsi udelat vec nepatrne komplexneji, nez ji zakaznik pozaduje - ve valne vetsine pripadu pak na upravy dojde a je tak alespon ulehcena cesta.

Avatar

Autor komentáře: Vilém Málek

Datum vložení: 9.12.2002 8:35:24

Co se tyce konzultata ze zadavatelske firmy - XP pozaduje, aby takovy clovek byl v neustalem kontaktu s programatorskym tymem, nejlepe pracoval ve stejne mistnosti. „Oficialni“ konzultace se provadeji jen vyjimecne, prakticky vsechno stoji na kazdodennim pracovnim styku ;-)

Avatar

Autor komentáře: jakub

Datum vložení: 9.12.2002 17:52:45

no, ja to take tak myslel, jako ze se s tim clovekem pravidelne bavim o tom, jak by to melo vypadat. Castost techto rozhovoru se rozvijeji v prime umernosti s velikosti projektu (cim vetsi, tim casteji). Ja tim nemyslim jen konzultace oficialniho charakteru (vady, nedodelky, skluz za planem) ale opravdu baveni se o meritu veci.

Avatar

Autor komentáře: Rs

Datum vložení: 9.12.2002 9:01:48

Knihu EP jsem cetl, je hezka :-) Bohuzel me pripada, ze je postavena pro situace kdy odberatel i dodavatel vedi co chteji a umeji rikat ne ...

Pochopeni kodu zakaznikem - vzdy je potreba rozlisit, co odberatel chce a jak je potreba to udelat.

Avatar

Autor komentáře: Ondrej Ivanic

Datum vložení: 9.12.2002 4:54:10

Programator si nemoze sam otestovat svoj vlastny vytvor. Skupinu testov musi spravit niekto kto neprogramoval... Je celkom zabavne pozerat sa, ako Vam vie jeden jediny clovek zrutit aplikaciu :)

Clovek moze programovat ako len chce aj tak je to podriadene krivke 80/20.

Avatar

Autor komentáře: Vilém Málek

Datum vložení: 9.12.2002 8:38:47

Je videt, ze nejste seznamen s metodami XP - testy provadeji nejen programatori, ale predevsim lide, kteri spolupracuji s vyvojovym tymem na strane zakaznika. Testy jsou pak v zasade dvou typu - rutinni, vytvorene na zaklade modelovych situaci (slouzi k validaci zmen v aplikaci), a provozni, vznikajici na zaklade okamzite potreby (validuji nove prvk v aplikaci a slouzi jako podklad k tvorbe portfolia rutinnich testu).

Avatar

Autor komentáře: J. Novak

Datum vložení: 11.12.2002 14:56:15

Zni to pekne, ale vidim nekolik problemu.

Klient z rad mensich nebo strednich firem vam tezko pujci sveho zamestnance na nekolik tydnu, aby si s vami "jen povidal". Dalsim zajimavym pripadem je outsourcing analytika. Ten se muze dopustit stejneho nepochopeni, jako vy (coby programator).

Zmeny zadani. Hmmm. U nas prameni zejmena z toho, ze klient zkousi, co jsme ochotni za dohodnutou cenu vsechno udelat. Nebo to tak na me pusobi. Nastesti jsem uz presvedcil vedeni, ze nejlepsi je mit presnou smlouvu.

Zbytecne komplikovany produkt. :-) Souhlasim s nekym prede mnou, ze se vetsinou vyplati udelat neco navic, protoze k tomu stejne dojde. Coz samozrejme neznamena, ze vysledkem je zbytecne komplikovany produkt.

Cirkulace programatoru. To znamena, ze musite mit minimalne 4 programatory, kteri zvladaji praci s databazemi na priblizne stejne urovni, stejne jako vyvojare UI, ...

Predpokladam, ze na tyto (nazveme to) "pochybnosti o XP" mate nejake odpovedi, tesim se na ne. Nechci nad XP jen mavnout rukou, ale na druhou stranu je potreba mit jasno i v techto otazkach. Diky.

Avatar

Autor komentáře: Pavel Kolesnikov

Datum vložení: 11.12.2002 15:55:55

Nejdriv obecna odpoved, kterou budu dal uz jen rozmelnovat podle konkretnich namitek: XP Vam nabizi nejake ideje a postupy, ktere je treba aplikovat s rozmyslem. Ne vzdy se postesti, ze mate idealni podminky pro jeho aplikaci.

Zakaznik na pracovisti:
Pokud klienta neumite presvedcit, ze se mu takova mira zapojeni se do projektu vyplati (a verim, ze existuje spousta pripadu - zejmena u vyrazne drobnych projektu - kdy by se klientovi opravdu nevyplatila), kaslete na to.
Zakaznik na pracovisti je hodne extremni priklad, jak dosahnout co nejintenzivnejsi komunikace s klientem. Pokud to nejde, nevadi, presto se snazte komunikovat jak jen to jde, neomezujte se na formalni projektove porady.

Zmeny zadani:
Jiste, dobra smlouva je vzdy zakladem. V clanku proto spis nez obchodni zalezitosti resim technicke aspekty zmen zadani, tj. "jak udrzet na uzde rostouci naroky na zmenu v zavislosti na case".

Zbytecne komplikovany produkt:
Urcite se shodneme na tom, ze nejaka elementarni nenarocna mira zobecneni (napriklad definice konstant na jednom miste :-) bude asi vzdy namiste. A obecne si musime polozit otazku - je pro klienta akceptovatelnejsi - kdyz mu co nejdrive a co nejlevneji dodame funkcni prototyp, nebo naopak ocekava drazsi a zdlouhavejsi produkt, ktery bude mozne s minimalnimi naklady modifikovat v ramci zaruky ci technicke podpory.
Preci jen, klient taky sleduje sve cash-flow, a pokud nam naroky na zmenu v case vyrazne nerostou, pak je pro zakaznika pochopitelne lepsi, kdyz co nejmene plati TED, a rozsireni si muze priobjednavat pozdeji (zejmena pokud mu nas produkt opravdu prinense zisk ci uspory).
Na druhou stranu, pokud si neverime, ze dokazeme zmeny zavadet pozdeji srovnatelne efektivne jako na zacatku, pochopitelne nemuzeme hazardovat. Odvaha je dulezita, ale musi byt podlozena.
Opet ale zalezi na konkretni situaci, v zadnem pripade nehodlam propagovat XP jako univerzalni samospasitelne reseni.

Cirkulace programatoru:
Opet - v mezich moznosti. Pokud si vasi databazovi experti i GUI-ari postavi hlavu a odmitaji se ucit cokoli noveho (a vy si je netroufnete vyhodit :-), asi je cirkulovat nenechate. Osobne si myslim, ze prumerny programator dokaze napsat cokoli, na co pri podnikovych aplikacich narazite. A pokud narazi na problem, jen at se zepta kolegy, ktery je na danou oblast vetsi expert (hle, komunikace :-)
A nebo zkuste zavest parove programovani - to je na vyrovnavani rozdilu v kvalifikaci jako delane.
A nebo je aspon nacpete fyzicky co nejbliz k sobe, pripadne si k nim poridte jako katalyzator jednoho naprumerne zkuseneho a univerzalniho programatora, kteremu jsou postupy XP blizke.

Zkratka je treba brat v uvahu okolni okolnosti. Pokud klientovi pozadavky XP nevyhovuji, nevadi - nasim cilem neni machrovat, jak skvele zvladame XP, ale uspokojit klienta. Pokud se Vas tym metodam XP vzpira, muzete pouzit vice ci mene nasilne presvedcovaci metody nebo proste usoudit, ze pro Vas tym XP neni.

Pokud se rozhodnete XP aplikovat, neradil bych slepe se vrhat do vsech konkretnich postupu jako zakaznik na pracovisti, parove programovani a cirkulace programatoru apod., ale spise vyjit z v clanku zminenych "ctyr zakladnich hodnot". A kdyz z komunikace a zpetne vazby vyplyne, ze nejlepsi by bylo cely projekt realizovat "tradicne", tak proc ne :-)

Avatar

Autor komentáře: jakub

Datum vložení: 11.12.2002 19:54:49

<I>Pokud klienta neumite presvedcit, ze se mu takova mira zapojeni se do projektu vyplati (a verim, ze existuje spousta pripadu - zejmena u vyrazne drobnych projektu - kdy by se klientovi opravdu nevyplatila), kaslete na to.
Zakaznik na pracovisti je hodne extremni priklad, jak dosahnout co nejintenzivnejsi komunikace s klientem. Pokud to nejde, nevadi, presto se snazte komunikovat jak jen to jde, neomezujte se na formalni projektove porady. </I>

sorry, ze kopiruji, ale souhlasim s kazdym jednotlivym slovem ;)

Avatar

Autor komentáře: J. Novak

Datum vložení: 13.12.2002 12:56:19

Aniz bych kdy studoval XP, mam dojem, ze vetsina tymu nektere zasady pouziva (nebo vetsinu? ;-)).

At uz se jedna o prubezne testovani, komunikaci s klienty (btw. osobne mam vetsinou problem s tim, ze klient komunikuje mene, nez bych potreboval), komunikaci uvnitr tymu.

Narazil jsem zatim na jednu zajimavou vec - oni si ti programatori nechteji psat komentare do zdroj. kodu, a pak jim dlouho trva, nez se "do toho dostanou". Mne se treba libi doxygen a pouzivam jej, ale vsetsina lidi, co jsem tu mel/mam pisi komentare jen v nejnutnejsich pripadech (stojim jim za zady ;-)).

Jinak diky za odpoved, v podstate me nicim neprekvapila, jen jsem byl zvedav, jestli to muze fungovat v praxi. Proto jsem to nazval idealy.

Avatar

Autor komentáře: Pavel Kolesnikov

Datum vložení: 13.12.2002 13:08:46

XP se snazi stavet na prirozenych hodnotach, ktere jsou spouste lidi vlastni, takze verim, ze jste se s takovymi tymy mohl casto setkat, aniz by o XP kdy cokoli slysely. Stejne tak se ale stava, ze jsou tymy, kde prevazuji lide se sklony k izolovane praci ci akademickym diskusim, pripadne kteri jsou zvykli vse resit ve formalni rovine. Osobne mam ale take stesti vice na ten prvni typ lidi.

Mimochodem, co se tyce komentaru - cim vic lidi pracuji spolecne, tim vic si ty komentare ci jednotny coding style na sobe zacnou vynucovat (a pokud k teto potrebe nedojdou, mate asi opravdu velmi sehrany tym, ale stejne bych se je k tomu snazil dokopat ;)

Zpět na článek | Úvodní stránka Interval.cz