On 20/05/2011 08:35, Michal Kleczek wrote:
> Andrzej Jarzabek wrote:
>
>> 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").

Dlatego testuje się przez _wszystkie_ iteracje. Np. jeśli masz release
po trzech miesiącach od rozpoczęcia kodowania, to to, co masz w tym
release jest już testowane od trzech miesięcy.

Problem z testowaniem "od A do Z" polega na tym, że metaforycznie masz
swoje A, swoje Z i jakieś literki pomiędzy, ale nie wiesz ile w ogóle
jest literek w alfabecie. W dodatku alfabet zmienia się w miarę rozwoju
oprogramowania. Dlatego też wszystkie literki, o których wiesz,
testujesz automatycznie za każdą iteracją, a może nawet codziennie, ale
cały czas masz równolegle tesowanie ręczne polegające na szukaniu, czy
są jeszcze jakieś literki między A i Z, o których się nie pomyślało.

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

Jasne.

> I dalej - ze wzgledu na te koszty nie
> mozna sobie pozwolic na to, zeby robic to zbyt czesto

Jak się robi porządnie, to się ma przeznaczone zasoby tylko do
testowania danego produktu. Jak go nie testujesz, to te zasoby leżą
odłogiem i kosztują z grubsza tyle samo.

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

Jak najbardziej. Z tym że jednak wykrywać i poprawiać należy również.

Ale w Agile jak najbardziej zwraca się bardzo dużą uwagę na praktyki
pozwalające na unikanie błędów: coding standards, refactoring, simple
design itd.

> Tyle, ze te metody prowadza - mniej lub bardziej - do modelu kaskadowego

Właśnie niekoniecznie.

> (ew. do powaznego wydluzenia iteracji).

Też niekoniecznie. Shore&Warden proponują iteracjęę trwającą tydzieeń i
rygoorystyczne trzymanie się tego.

> Np. unikanie bledow w rozpoznaniu wymagan polega na _dokladniejszym_
> wyspecyfikowaniu tych wymagan i _dokladniejszej_ weryfikacji specyfikacji

Agile proponuje dokładniejszą specyfikację uzyskać w ten sposób, że
programista jak nie wie co dalej robić, to rozmawia z customerem (lub
analitykiem) i on mu to specyfikuje. Jako metodę dokładniejszej
weryfikacji proponuje się pokazanie customerowi działającego prototypu i
spytanie czy właśnie o to chodziło.

> - nie oplaca sie robic oprogramowania _zanim_ sie skonczy specyfikacje,
> bo to strata czasu i pieniedzy na robienie czegos, co potencjalnie
nie jest
> nikomu potrzebne.

Przecież to, co jest w specyfikacji też potencjalnie nie jest nikomu
potrzebne. Na szybko z co najmniej dwóch powodów:
a) było potrzebne w momencie tworzenia specyfikacji, ale już nie jest
b) nigdy nie było potrzebne, ale analityk popełnił błąd i wpisał, bo
uznał że potrzebne.

W agile masz tę zaletę, że najdalej na początku danej iteracji, w której
to coś jest implementowane, customer potwierdził że tak, na pewno jest
potrzebne, a co więcej jest to jedna z najważniejszych rzeczy, jakie
zostały do zrobienia.

> I to, ze w ramach analizy wymagan robi sie prototypy, nie powoduje
> automatycznie, ze te prototypy staja sie gotowym produktem

Co to znaczy "stają się"? Że są w takiej postaci releasowane? Nikt tego
nie postuluje. Staje się, w sensie że jest wykorzystywany do tworzenia
produktu, owszem. Przy wszystkich krytykach do agilee, że to czy tamto
jest wyrzucaniem pieniędzy, to pisanie działającego programu, który robi
to co trzeba, po to, żeby go wyrzucić i napisać to samo od nowa też jest
jednak marnowaniem pieniędzy.

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

Tu jest trochę fałszywe założenie, że taniej jest pisać kod niższej
jakości od kodu wysokiej jakości. Może być tańsze tylko o tyle, że
możesz do tego wykorzystywać słabszych programistów którym gorzej
płacisz, ale to raczej nie jest szczególnie dobre podejście do agile.

Poza tym do wyrównywania (w górę) poziomu kodu masz takie praktyki jak
coding standards, collective code ownership i pair programming (lub code
review).

Są też co prawda sytuacje, gdzie ma sens pisanie throwaway code, bo z
jakichś tam powodów łatwo jest zrobić jakiś prototyp, a trudno go
będziee wcielić do produktu końcowego (bo jest np. wykonany w jakiejś
niekompatybilnej technologii). I metodologie agile przecież też tego nie
zabraniają, co najwyżej lekko zniechęcają (na zasadzie jeśli nie masz
realnych problemów, żeby zrobić inaczej, to zrób raczej tak, żeby się
nadawało do produkcji albo przynajmniej do refaktoryzacji).

> probowac, by te prototypy mialy konstrukcje i jakosc produktu koncowego, bo

Oczywiście, że nie. Po to masz refactoring.

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

No moment, ale pracujemy przecież cały czas z klientem. Czyli jest
powiedzmy wczesne zebranie zespołu, na którym siedzi customer
representative, i jest rozmowa o tym, w jakiej technologii wykonać.
Jeśli pada propozycja C#, to raczej padnie pytanie, czy można na pewno
założyć, że produkt będzie pod .NET, a .NET jest tylko pod Windows
(istnienie Mono na potrzeby dyskusji pominiemy). Od przedstawiciela
klienta raczej będzie się w tym momencie wymagało potwierdzenia, że
można takie założenie poczynić no i oczywiście trafia to do bieżącej
dokumentacji projektu. Jeśli klient potem zmieni zdanie, to mu można w
tej sytuacji powiedzieć, że nie zrobimy albo że trzeba będzie to z
punktu widzenia terminów i kosztóww potraktować jako robienie od nowa.