пропозиції роботи
konto usunięte
Temat: TDD, testowanie i inne takie
Maciej R.:
Witam wszystkich,
Calkiem przypadkiem natknalem sie na dyskusje tutaj prowadzona i po przeczytaniu niektorych postow jestem wrecz zatrwozony
istote agile stanowią 4 zdania. na dobra sprawę to nawet nie są zdania. nie ma czym sie trworzyc.
oziomem
wiedzy na temat Agile'a/Scrum'a reprezentowanym przez wypowiadajace sie tutaj osoby, zwlaszcza te, ktore uwazaja sie za team liderow czy analitykow. Dlatego tez postanowilem zabrac glos i rzucic troche swiatla na pojecia, ktore wydaja sie byc dla niektorych czarna magia czy szamanizmem, a w grunice rzeczy sa banalnie proste, tylko zapewne nieumiejetnie zrozumiane.
Zacznijmy od tego skad w ogole czerpiecie informacje o Scrumie? Z wikipedii? Z ksiazki? Od kolegi? Byliscie na jakims szkoleniu ze Scruma? Pracowaliscie w Scumie jakis rozsadny okres czasu, powiedzmy, ze min. rok? Jesli tak, to w jakich rolach?
Nikt tutaj nie wydaje sie zdawac sobie sprawy po co tak naprawde Scrum jest wprowadzany i przez kogo. Otoz Scrum jest zwykle wprowadzany odgornie, przez management, bo to management musi widziec korzysci z jego wprowadzenia. A jakie to korzysci? Przede wszystkim TRANSPARENTNOSC! Inaczej przezroczystosc, widocznosc. Widocznosc czego? Postepu i problemow. Metodologia jest skonstruowana tak, zeby w kazdym momencie wiadomo bylo na czym sie stoi, a ewentualne przeszkody byly mozliwie najszybciej wykryte.
Polecam zapoznac sie np. z wykladem Kena Schwabera, zwanego jednym z "ojcow Scrum'a": http://www.youtube.com/watch?v=IyNPeTn8fpo
Zwlaszcza czesc od 13:34 do 15:06, gdzie mowi mniej wiecej o tym co napisalem powyzej.
Jezeli chodzi zas o TDD, to jego rozumienie jest zupelnie naturalne. Zanim chcesz cos napisac, musisz wiedziec jak to ma dzialac. Jezeli wiesz jak to dziala, to na zasadzie prostych przykladow z zadanym wejsciem, musisz wiedziec jakie jest oczekiwane wyjscie - i to jest juz test. Dlaczego wiec nie spisac najpierw tego testu, skoro jest juz on znany zanim rozpocznie sie implementacja? Takie podjescie wymusza bardzo dobra praktyke jaka jest programowanie przez prototypowanie, czy programowanie top-down, tylko z uzyciem interfejsow bez zadnej implementacji na poczatek.
Z TDD powiazane jest inne ciekawe, acz jeszcze mlode pojecie, executable specification, czyli tzw. wykonywalna specyfikacja. Widac, ze wiele jezykow dazy w tym celu - by stac sie rowniez meta-jezykami. W ten sposob, byc moze w niedalekiej przyszlosci, juz na etapie formulowania wymagan analitycy beda musieli programowac w meta-jezykach, co ma znacznie przyspieszyc przejscie od specyfikacji do implementacji. A w tym miejscu az prosi sie o uzycie TDD w postaci czegos w rodzaju "meta-testow akceptacyjnych". No ale to jeszcze poki co piesn przyszlosci.
To tyle ode mnie, bo nad kazdym z tematow mozna by sie duzo rozwodzic, a nie chce mi sie bawic w szkoleniowca, tylko wyeksponowac podstawowe bledy w pojmowaniu ideologii Scrum'a.
