Andrzej Jarzabek wrote:

> On Thu, 19 May 2011 12:55:34 +0200, Paweł Kierski<n...@p...net>
> wrote:
>> Iteracje mogą być dłuższe, a nie każda musi się kończyć testowaniem
> od
>> A do Z, a np. tylko nowych ficzerów. Tu pewnie zwolennicy Kanbana
>
> Oczywiście, że każda iteracja jest testowana od A do Z. Automatycznie.

Sek w tym, ze to jest tylko _udawanie_ testowania. Nie da sie _dobrze_
przetestowac niebanalnego oprogramowania w czasie jednej iteracji (o
dlugosci proponowanej przez "agile"). A juz tym bardziej zalozenie, ze
testuje sie "na biezaco", wiec na zakonczenie iteracji mamy juz
"przetestowane" jest po prostu smieszne.

Co wiecej - trzeba sobie zdac sprawe z tego, ze _prawdziwe_ testowanie b.
duzo kosztuje (nie tylko ze wzgledu na czas, lecz takze ze wzgledu na
zasoby, ktore sa potrzebne do tego). I dalej - ze wzgledu na te koszty nie
mozna sobie pozwolic na to, zeby robic to zbyt czesto - stad stosuje sie
metody pozwalajace _unikac_ bledow (a nie je wykrywac i poprawiac) - to jest
po prostu tansze i - co wiecej - pozwala osiagnac jakosc, ktorej nie da sie
osiagnac testujac/poprawiajac.
Tyle, ze te metody prowadza - mniej lub bardziej - do modelu kaskadowego
(ew. do powaznego wydluzenia iteracji). Np. unikanie bledow w rozpoznaniu
wymagan polega na _dokladniejszym_ wyspecyfikowaniu tych wymagan i
_dokladniejszej_ weryfikacji specyfikacji - nie oplaca sie robic
oprogramowania _zanim_ sie skonczy specyfikacje, bo to strata czasu i
pieniedzy na robienie czegos, co potencjalnie nie jest nikomu potrzebne. I
to, ze w ramach analizy wymagan robi sie prototypy, nie powoduje
automatycznie, ze te prototypy staja sie gotowym produktem - a to znowu z
tego powodu, ze prototypy robi sie najtaniej jak mozna i ich jakosc jest
daleka od jakosci oczekiwanej od produktu koncowego. Nie ma tez sensu nawet
probowac, by te prototypy mialy konstrukcje i jakosc produktu koncowego, bo
dopoki nie skonczymy analizy wymagan, moze sie okazac, ze nieuwzglednione do
tej pory wymagania beda wymagac calkowitej zmiany konstrukcji
oprogramowania. Co wiecej - zapewnienie odpowiedniej jakosci wymaga
_kosztownego_ i dlugotrwalego testowania, wiec zataczamy kolo.

U podstaw "metodyk agile" lezy (mniej lub bardziej jawne) zalozenie, ze da
sie tak robic oprogramowanie, ze koszt jego modyfikacji nie wzrasta w miare
jego rozrastania sie. Co jest zalozeniem po prostu absurdalnym - jezeli np.
na poczatku podejmiemy decyzje o tworzeniu tego oprogramowania dajmy na to w
C# (bo zespol uznal, ze tak najlepiej) a potem okaze sie, ze klient
zapomnial nam powiedziec o tym, ze to ma dzialac na Solarisie (z jakichs tam
powodow), to jak niby mamy zrobic "refaktoring" nie przepisujac tego
oprogramowania w calosci???

--
Michal