On 21 Maj, 15:03, Andrzej Jarzabek <a...@g...com> wrote:

> > Nie zapobiegam im ani testami z automata ani ręcznymi.
>
> Znaczy, nie robisz żadnych testów,

Czytaj cały post zanim odpiszesz.

> Ej, ale jak rozumiesz "się nie da"? Że testy spowodują, że w ogóle
> błędów nie będzie, no to rzecz jasna. Ale skoro i tak będą, to klienta
> może interesować, czy będzie ich mniej czy więcej, czy będą występować
> częściej, czy rzadziej.

Tak. Dlatego staram się mieć dobry projekt - po to, żeby błędów było
mniej.

Testy oczywiście są. Ale robię z nich fetyszu i nie stawiam ich w
centrum procesu.

> Nie tylko unit testy można odpalać z automata. Można automatycznie
> testować całe systemy, nawet GUI.

Nie, nie można.
Tzn. nie twierdzę, że nie ma na świecie rozwiązań, które to obiecują
(więc nie pokazuj mi linków do tych rozwiązań :-p ).
Twierdzę tylko, że nie można.

> > Wybij sobie z głowy taki pomysł, że jakakolwiek (pseudo)metodologia
> > pozwoli niedoświadczonym ludziom robić dobre projekty.
>
> Oczywiście! Stąd moje zastrzeżenie do waterfall, że te wszystkie
> metodologie analizowania i projektowania to i tak machanie rękami wokół
> tego, że szacunki opierają się na doświadczeniu osoby z odpowiednim
> doświadczeniem.

Ostatecznie tak to wygląda.

> > Dotyczy to
> > każdej dziedziny inżynierskiej, nie tylko IT. Doświadczenia nie da się
> > niczym zastąpić a jeśli już to doświadczenie jest, to należy z niego
> > skorzystać przy planowaniu co i jak należy zrobić.
>
> Zgoda! I to nie jest tak, że w agile nie ma planowania. Jest planowanie,
> i podstawą planowania jest to, że się zbiera osoby z odpowiednim
> doświadczeniem w jednym pomieszczeniu.

Właśnie nie jestem o tym przekonany. Mam wrażenie, że agile stał się
wyjątkowo atrakcyjny właśnie dla młodego pokolenia, przez swoją mniej
lub bardziej jawnie wyrażoną obietnicę, że programowanie może być
znowu "cool". Każdy chce, żeby było cool, więc im bardziej coś wygląda
cool, tym lepiej. I tak powstają niezliczone odmiany "procesów" agile
- szybciej, niż można je uwiarygodnić przez faktyczne doświadczenie.

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.

> 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.

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ł.
Ja wcale nie sugeruję tutaj żadnego RUPa czy czegoś w tym stylu.
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ć.

> > Testy, oczywiście, są. Ale jak już pisałem - bywa, że są do dupy i
> > dają fałszywe poczucie bezpieczeństwa.
> > Problem z agile/xp/itd. polega na tym, że niestety nie daje żadnych
> > kryteriów oceny ani obrony przed taką możliwością a przez to prowadzi
> > do fałszywego poczucia bezpieczeństwa.
>
> O, super to ująłeś, mogę pożyczyć? "Analiza, projekt - bywa, że są do
> dupy i dają fałszywe poczucie bezpieczeństwa. Problem z
> waterfall/iterative polega na tym, że nie dają żadneej obrony przed taką
> możliwością, a przez to prowadzą do fałszywego poczucia bezpieczeństwa."

Spoko. Możesz pożyczyć, bo to jest prawda i istnieje również w wersji
"there is no silver bullet". Mogę jedynie powiedzieć, że naciąłem się
z testami, bo już nie raz zaprowadziły mnie (albo kogoś z mojego
otoczenia) w buraki natomiast nigdy nie naciąłem się z projektowaniem
- bo zawsze projekt był wartością dodaną, która wyznaczyła kierunek
prac i którą można było uwiarygodnić (albo wyprostować!) jeszcze przed
napisaniem pierwszej linijki kodu.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com