On 22/05/2011 12:47, Maciej Sobczak wrote:
> On 21 Maj, 15:03, Andrzej Jarzabek<a...@g...com> wrote:
>

> Problem w tym, że jeżeli już masz cały pokój ludzi z dużym
> doświadczeniem, to właściwie nie ma znaczenia, jaki to będzie proces.
> I tak to zrobią dobrze i to jest właśnie ten nieuchwytny czynnik
> ludzki.

Nie zgodzę się, proces ma też znaczenie. No i przede wszystkim od
procesu może zależeć, czy ci ludzie w ogóle znajdą się w jednym pokoju.

>> Ach, widzisz, tylko tak się składa, że istnieje taka szkoła
>> projektowania jak "simple design"/"incremental design", która mówi, że
> [...]
>> Robienie w tym momencie większego projektu uważam za błąd.
>
> A kto mówi, że on ma być większy? On ma być wystarczający. W
> szczególności brak projektu nie jest wystarczający.

W szczególności może być tak, że wystarczyć może zastanowienie się przez
chwilę przed rozpoczęciem pisania. Czy koncepcja w głowie programisty
powstała przez zastanawianie się przez 15 minut nazwiesz "projektem" czy
nie,to kwestia semantyki. Na pewno taki "projekt" nie jest sprzeczny z
agile.

> Dla przykładu, mój ostatni projekt na papierze nie zawierał formalnych
> diagramów. Były ze dwa (!) obrazki w stylu prezentacji power pointa,
> ale ani kawałka UMLa ani niczego podobnego. Był za to *dokładniejszy*
> opis protokołu oraz interakcji w skali makro, była też bardziej
> dokładna analiza konsekwencji różnych fakapów, bo projekt
> dotyczył systemu krytycznego. Całość była napisana tak, żeby inny
> senior, niezwiązany z projektem ale poproszony o ocenę, powiedział, że
> się przekonał.

Ale też nikt nie mówi, że nie należy takich projektów robić na
"papierze" (czy to by oznaczało dokument w wordzie z diagramem w visio
czy rysunek na flip chart'ie.

> Ja wcale nie sugeruję tutaj żadnego RUPa czy czegoś w tym stylu.

No popatrz, a są tacy, którzy nawet proponują pełnego waterfalla.

> Twierdzę natomiast, że wystartowanie od razu z wersją demo jest słabe
> i zwiększa ryzyko, że na wersji demo się skończy. Twierdzę też, że TDD
> jest słabe, bo rzeczy naprawdę ważnych nie potrafi uchwycić.

1. TDD to nie tylko unit testy.
2. Automatyczne (i inne) testy potrafią wychwicić naprawdę ważne rzeczy.
Nie wszystkie ważne rzeczy, ale przynajmniej niektóre ważne rzeczy.
Jeśli tobie się nie zdarzyło, to możesz mi uwierzyc na słowo.
3. Agile/XP to nie tylko TDD.
4. Czasem lepiej skończyć na wersji demo niż po kilku miesiącach
usłyszeć, że to nie jest to, o co chodziło.