Temat: TDD, testowanie i inne takie

Z mojej perspektywy:

Jakubie, musisz przestać bo w poniedziałek powiem klientowi, że już nie będę dla niego pracował dopóki się nie zastanowi co dokładnie chce osiągnąć w ciągu najbliższych kilku miesięcy... i to może się źle skończyć ;D

A ja własnie to mówię klientom, zawsze im mówię, że projekt nie mający celu ma nikłe szanse powodzenia, i co ciekawe z reguły słuchają (czasami nie, ale wtedy ja rezygnuję); Jakub ma tu na prawdę wiele racji, a rolą analityka jest nie tylko "zapisać to co mówi Klient" (bo to potrafi dyktafon), rola analityka jest właśnie zrozumieć cel Klienta albo mu powiedzieć, że "celu projektu nie wykryto" i pomóc w tym Klientowi.

Ale muszę przyznać, że teraz już chyba rozumiem twoją niechęć do Scruma/metodyk zwinnych. Niestety masz rację sporo racji ale to też zależy od kontekstu.

to w wielu przypadkach zależy od zwykłej uczciwości

Wyobraź sobie start-up albo projekt gdzie klient jeszcze dokładnie nie czego tak na prawdę chcą użytkownicy.

o tym na końcu powiem

W tym momencie trzeba "spróbować" kilku rzeczy (funkcjonalności), żeby wybrać tę która najbardziej zaciekawi użytkownika.
W tym momencie Scrum ma znaczną przewagę nad "Waterfallem".

nie zawsze, z "waterfall" nie raz wychodzi analiza ryzyka, że "tym razem może nie warto"... albo "może przemyślmy to jeszcze raz"...

Bardzo podobnie w przypadku, kiedy w projekcie jest bardzo dużo zależności od innych dostawców.

to się nazywa brak panowania nad projektem

Można sobie zaplanować wszystko super, przeprowadzić analizę, zrobić projekt i co z tego jak okaże się po niedługim czasie, że dostawca zrobić coś podobnego ale nie do końca, i nie w tym terminie, który zakładaliśmy?

to tylko planowanie i zarządzanie ryzykiem (PMI/Price2), ale plan bez oceny ryzyk i alternatywnych działań jest "bublem" a nie planem...

W wypadku, kiedy przewidywalność jest jeszcze mniejsza niż ta "oczekiwana" przez Scrum jeszcze lepiej sprawdziłby się pewnie Kanban.

hm................ ;)

BTW chyba należałoby zmienić tytuł tego tematu na coś o metodykach prowadzenia projektu ;D

tez tak sądzę ;)

W sumie wychodzi na to (co mogę potwierdzić obserwacjami), że metodyki zwinne to sytuacja gdy obie strony umowy nie wiedzą jak i mimo to łapią się za niemożliwe z fałszywą nadzieją, że druga strona wie jak i ze się uda. Nie dotyczy start-upów bo wtedy jest to jawnie wyartykułowane.

Od siebie powiem tak: winą za uwalone projekty IT z zasady w takich wypadkach obarczam biznes, to tu się planuje i zarządza ryzykiem (powinno się), winę developera widzę raczej w podejściu "co z tego, że nic nie wiadomo, w końcu klient płaci T&M i to jego problem"... ale tu wina zależy od tego "co obiecał Developer", jeżeli tylko to, że "dołoży wszelkich starań" to jest rozgrzeszony :) a Klient ma projekt badawczy R&D :) nawet jeśli o tym nie wie...Jarek Żeliński edytował(a) ten post dnia 01.11.12 o godzinie 12:34

Temat: TDD, testowanie i inne takie

nie można winić biznesu, skoro nie zna się na IT :)

p.s.
więcej planować i myśleć, a mniej kombinować SCRUM'ować itd...

AnKa

Temat: TDD, testowanie i inne takie

Anna Bizera:
nie można winić biznesu, skoro nie zna się na IT :)

na własnym biznesie powinien....

p.s.
więcej planować i myśleć, a mniej kombinować SCRUM'ować itd...

:)

Temat: TDD, testowanie i inne takie

Wydaje mi się, że potrzeba nie lada umiejętności interpersonalnych żeby uświadomić klienta o tym, że źle planuje swój projekt, po to żeby klient nie zrezygnował z naszych usług.

W tym momencie, kółko się już chyba zamyka i dalsze wypowiedzi z mojej strony już nie mają sensu.

Podsumowując:
1. Jeśli miałbym pracować nad (bardzo) dużym projektem to byłbym w stanie pracować bez żadnego "ale" w Waterfall-u. Ale i tak szedłbym raczej w stronę przynajmniej szybkiego prototypowania.

2. Jeśli miałbym pracować z klientem, który nie wie dokładnie czego chce i do tego nie jest skłonny do zmiany podejścia to Scrum.

3. Jeśli jesteśmy w totalnym chaosie to najprawdopodobniej Kanban. A później być może Scrum?

4. Ta dyskusja zmotywowała mnie do tego, żeby więcej wymagać od klienta w kwestii dostarczania wymagań i planowania rozwoju produktu, który dla niego tworzy mój zespół.

Dziękuję za bardzo interesujące informacje :)Damian Sromek edytował(a) ten post dnia 01.11.12 o godzinie 22:14

Temat: TDD, testowanie i inne takie

Anna Bizera:
Fajną dyskusję prowadzicie - ile w niej praktyki?

Mam zwyczaj nie wypowiadać się o rzeczach, których nie spróbowałem i/lub o których nie posiadam sporej wiedzy.

Dlatego możesz być pewna, że moje uwagi w tym temacie wynikają z praktyki i dużego zainteresowania Agile-em itp ;)

Temat: TDD, testowanie i inne takie

Jakubie, musisz przestać bo w poniedziałek powiem klientowi, że już nie będę dla niego pracował dopóki się nie zastanowi co dokładnie chce osiągnąć w ciągu najbliższych kilku miesięcy... i to może się źle skończyć ;D

Jeśli tego nie zrobisz to "Twój klient" nie będzie się zastanawiać co chce osiągnąć , bo nie będzie mu to się opłacać (po co "ja" mam myśleć, skoro "on" może pracować).

Pomyśl sobie, że Twoja praca jest warta tyle, co "fantazje nieuczesane" klienta.

Ale muszę przyznać, że teraz już chyba rozumiem twoją niechęć do Scruma/metodyk zwinnych. Niestety masz rację sporo racji ale to też zależy od kontekstu.

Wyobraź sobie start-up albo projekt gdzie klient jeszcze dokładnie nie czego tak na prawdę chcą użytkownicy.

"klient jeszcze dokładnie nie czego tak na prawdę chcą !? " :>

Mam w nosie klientów (użytkowników) klienta :)

Umowę podpisuje się z klientem, a nie z "klientami klienta" / użytkownikami.

W tym momencie trzeba "spróbować" kilku rzeczy (funkcjonalności), żeby wybrać tę która najbardziej zaciekawi użytkownika.
W tym momencie Scrum ma znaczną przewagę nad "Waterfallem".

Pod względem finansowym (dla wykonawcy) czy "efektywności pracy" ?

Bardzo podobnie w przypadku, kiedy w projekcie jest bardzo dużo zależności od innych dostawców.
Można sobie zaplanować wszystko super, przeprowadzić analizę, zrobić projekt i co z tego jak okaże się po niedługim czasie, że dostawca zrobić coś podobnego ale nie do końca, i nie w tym terminie, który zakładaliśmy?

czy miałeś kiedyś sytuację, że ktoś / kiedyś / coś "super zaplanował" i po "niedługim czasie" ten "super plan" okazał się nietrafiony ?

... nawet "super plany" mogą okazać się głupie. Oczywiście, w takich sytuacjach, super analitycy pozostają super analitykami / projektantami / specjalistami etc ....

BTW chyba należałoby zmienić tytuł tego tematu na coś o metodykach prowadzenia projektu ;D

Znowu ? po co ? ;)

Temat: TDD, testowanie i inne takie

temat testów jest ogólnoświatowy :)
http://www.linkedin.com/groups/How-Resolve-Testing-Bot...

Temat: TDD, testowanie i inne takie

O refaktoryzacji... schodzimy na waterfall vs agile:)
O tdd i testowaniu... to samo:P
Może rzeczywiście to pora na osobny wątek? Tylko, że co z tego by wyszło? Lubię takie dyskusję, ale nie ukrywajmy - są czysto akademickie.
Zgodzę się z Jakubem, że agile to "zmiany, zmiany, zmiany" i chciałbym, aby projekt miał z góry wszystko ustalone, ale tak nie jest, a ja na to wpływu niestety nie mam. Dlatego też wybór padł na Scrum'a, pomaga zapanować w jakimś stopniu nad chaosem.

Mimo wszystko chciałbym jeszcze raz spróbować do tych testów wrócić. Z mojej perspektywy, czyli osoby, która prowadzi projekt wg Scrum'a, testowanie przydaje się, bo:
- w przypadku wprowadzenia zmian wiem, że przez przypadek nie wpłynąłem negatywnie na wcześniejszą funkcjonalność
- mam pewność, że wszystko działa zgodnie z założeniami
- eliminuje błędy projektu np. jeżeli muszę namęczyć się przy testowaniu i używać nie-wiadomo-jakiej magii oznacza to, że źle przemyśleliśmy funkcjonalność przed implementacją (jeżeli mamy odpowiednią osobę/osoby odpowiedzialne za projekt, to ten punkt można usunąć)

Dlaczego tdd:
- zwiększa wiedzę programistów na temat produktu, ponieważ zastanowienie się nad testami przed implementacją, sprawia, że nie podchodzą do problemu, jak informatycy, ale jak użytkownicy
- ma się większą motywację do pisania testów (jak już jest funkcjonalność, to często część testów się pomija)

Jakie widzę minusy:
- gdyby nie owa zmiana (ta stała agile'owa) z pewnością nie produkowalibyśmy tylu testów jednostkowych, co przekłada się na szybszą implementację (przy agileowych projektach ta oszczędność wcześniej czy później zazwyczaj się mści)
- tdd nie przynosiłoby tak istotnych korzyści, ponieważ wiedzę na temat projektu mamy kompletną przed przystąpieniem do implementacji

A jakie plusy i minusy testowania i tdd widzą nie-agileowcy?Sebastian Malaca edytował(a) ten post dnia 02.11.12 o godzinie 09:28

Temat: TDD, testowanie i inne takie

Jeśli chodzi o TDD to nie wyobrażam sobie nie mieć jakichkolwiek testów automatycznych w dużym projekcie.
Na samą myśl o tym, że sporą częścią zespołu mięliby być "testerzy-klikacze" to aż mnie ciarki przechodzą.

Polecam przeczytać książkę, którą wspominam w tym poście:
http://damiansromek.pl/2012/05/31/growing-object-orien...

Jest w niej bardzo fajny przykład podejścia Agile-owego + TDD.

Temat: TDD, testowanie i inne takie

Sebastian Malaca:
Zgodzę się z Jakubem, że agile to "zmiany, zmiany, zmiany" i chciałbym, aby projekt miał z góry wszystko ustalone, ale tak nie jest, a ja na to wpływu niestety nie mam. Dlatego też wybór padł na Scrum'a, pomaga zapanować w jakimś stopniu nad chaosem.

Jak także zgadzam się z Jakubem, Agile/SCRUM to jazda samochodem z Klientem na pokładzie bez wiedzy co jest celem, jedyne co wiemy to to, że "chodzi o jakieś fajne miejsce" tylko, że kto inny prowadzi samochód )developer) a kto inne ocenia 'fajność miejsca" (Klient).

To z czym ja "walczę" w projektach eliminacja przejazdów taksówką, gdzie taksówkarz przyjął zamówienie nie znając celu, liczy sobie za każdy kilometr, i co godzinę pyta Klienta "czy to miejsce jest fajne, ale jakby coś to możemy dalej jechać".... Tak zwane zwinne metodyki postrzegam jako próby uporządkowania tego bezsensu...

Dobry taksówkarz podobno nie bierze kursu jak nie zna celu i nie ma znajomości terenu (jak duży, to ma mapę i plan dojazdu). Z drugiej strony są głosy, że taksówkarz jest od wożenia a nie od ustalania celu podróży i z tym w sumie także można się zgodzić, ale wobec tego najpierw jednak może warto by taksówkarz określił, do której grupy taksówkarzy się zalicza i jasno mówił o tym Klientom, bez tego wielu Klientów słusznie czuje, że zostali oszukani w momencie gdy zabrakło im pieniędzy na dalsza jazdę i nadal nie nigdzie dotarli ...

Mimo wszystko chciałbym jeszcze raz spróbować do tych testów wrócić.

Wraca jak bumerang kwestia, jak rozumiem, kluczowa: co jest testowane w testach? Bo sam fakt, że kod się nie wysypuje oraz to, że 2+2=4 nie znaczy, że to oprogramowanie spełnia jakiekolwiek wymagania poza tym, że się nie wysypuje... czyli w pewnym sensie "wielkie oprogramowanie" może spełniać wszystkie wymagania poza-funkcjonalne (a te dość łatwo spisać) i żadnych funkcjonalnych....Jarek Żeliński edytował(a) ten post dnia 02.11.12 o godzinie 10:11

Temat: TDD, testowanie i inne takie

ja mam prośbę, czy mógłbyś raz użyć jakiegoś konkretnego przykładu, a nie kolejnej metafory taksówki, fontanny na rowerze czy innej? :)

jakiś taki prosty przykład wymagania funkcjonalnego, które da się opisać w dokumentacji a nie da się przetestować testem jednostkowym?

Temat: TDD, testowanie i inne takie

Kamil Mikołajczyk:
ja mam prośbę, czy mógłbyś raz użyć jakiegoś konkretnego przykładu, a nie kolejnej metafory taksówki, fontanny na rowerze czy innej? :)

Nie da się inaczej, bo manifest Agile to kilka luźno powiązanych ze sobą, nic nie znaczących, zdań.

jakiś taki prosty przykład wymagania funkcjonalnego, które da się opisać w dokumentacji a nie da się przetestować testem jednostkowym?

definicje wymagań funkcjonalnych i poza-funkcjonalnych są dostępne i są proste:
http://pl.wikipedia.org/wiki/Wymaganie_(in%C5%BCynieri...

problem polega na dwóch "prostych" rzeczach, specyfikacja wymagań powinna być:
- skończoną i kompletnych listą niesprzecznych elementów (czyli nie odkrywamy wymagań dopiero w trakcie projektu!)
- niezmienna w czasie (trwania implementacji)

rozumiem, że zaraz wzbudzi oburzenie pojęcie "niezmiennna w czasie" ale własnie tak ma być, jeżeli wymagania są zmienne w czasie (implementacji) to znaczy, że albo okres od rozpoczęcia do wdrożenia jest zbyt długi albo wymaganie zostało źle określone.

Przykład:
- system ma pozwalać na wystawianie faktur VAT zgodnie z ustawą (tu także wzór faktury)
- dostępność tej usługi powinna być nie mniejsza niż 9,xxx % czasu

Wiemy, ze ewentualne nowe przepisy (zmiana ustawy opisującej faktury) wchodzą w życie po ustalonym okresie od ogłoszenia, to znaczy, że wymagania na fakturę są niezmienne w tym okresie. Dalej: jeżeli implementacja ma trwać dłużej projekt nie ma sensu.

To tylko wymagania, za mało by cokolwiek "kodować"! Więc tworzymy scenariusz przypadku użycia (dialog aktor-system). To także za mało by cokolwiek kodować! Potrzebny jest model dziedziny. Jeżeli dostaniemy tylko "diagram klas przypominający diagram ERD" to nadal nic nie wiemy i nie ma co kodować! Potrzebne są klasy z operacjami: Bingo: mamy materiał do testów jednostkowych (klasy i interfejsy klas). Teraz możemy sprawdzić poszczególne klasy. Problem? Skąd pewność że to razem ma sens? No to potrzebny test, który powie, że Faktura z Systemu to potrzebna Faktura zgodna z ustawą. Albo schematy jak klasy współdziałają (diagram sekwencji) a jak ktoś nie potrafi, to musi powstać kod i trzeba go przetestować czyli sprawdzić czy powstanie faktura (dużo kosztowniejsze niż diagramy sekwencji).

A w czym problem? Jeżeli klient powie, że chce podnieść jakość obsługi klientów i sprzedaży to jakoś logicznie należy dotrzeć (śladowanie wymagań) do wniosku: potrzebna usługa wystawiania faktur VAT.

Jeżeli ktoś wyartykułował na pałę: chcemy mieć system fakturowania, to ktoś powinien zapytać "dlaczego akurat faktury" i zweryfikować czy aby na pewno to jest celem projektu. Jeżeli uznamy to za dobrą monetę, a sponsor projektu i tak ma "w głowie" cel "podnieść konkurencyjność" to jak powstaną te faktury i tak urodzi się kolejne oczekiwanie związane z "podniesieniem konkurencyjności" bo faktury to za mało (albo w ogóle nie o to chodzi, tylko o mycie rąk przy pakowaniu towaru),

Tak więc same testy jednostkowe niczego nie testują (poza jakością kodowania) dopóki nie sprawdzimy, że te kilka czy kilkanaście przetestowanych każda z osobna klas, da w efekcie poprawna fakturę VAT.

Pamiętajmy, że silniki (setki części) są dobre nie dlatego, że każda część z osobna jest dobra, silnik jest dobry jeżeli uda się go uruchomić i wykaże on wymagany moment obrotowy na wale ...

Temat: TDD, testowanie i inne takie

Damian Sromek:
Jeśli chodzi o TDD to nie wyobrażam sobie nie mieć jakichkolwiek testów automatycznych w dużym projekcie.
Na samą myśl o tym, że sporą częścią zespołu mięliby być "testerzy-klikacze" to aż mnie ciarki przechodzą.

Polecam przeczytać książkę, którą wspominam w tym poście:
http://damiansromek.pl/2012/05/31/growing-object-orien...

Jest w niej bardzo fajny przykład podejścia Agile-owego + TDD.

od siebie dodam bardzo dobrą moim zdaniem książkę (honorowe miejsce na mojej półce ;)):
http://www.amazon.com/Large-Scale-Software-Architectur...

Temat: TDD, testowanie i inne takie

Nie da się inaczej, bo manifest Agile to kilka luźno powiązanych ze sobą, nic nie znaczących, zdań.

Niestety nie mogę się zgodzić.
Te "nic nie znaczące zdania" nabierają bardzo dużo sensu, kiedy już się spróbuje Agile-u.
Im dłużej w nim siedzisz tym większy ich sens.
Wiem z własnego doświadczenia.

Tak więc same testy jednostkowe niczego nie testują (poza jakością kodowania) dopóki nie sprawdzimy, że te kilka czy kilkanaście przetestowanych każda z osobna klas, da w efekcie poprawna fakturę VAT.

Pamiętajmy, że silniki (setki części) są dobre nie dlatego, że każda część z osobna jest dobra, silnik jest dobry jeżeli uda się go uruchomić i wykaże on wymagany moment obrotowy na wale ...

No i tutaj mamy podobną sytuację w rozumieniu TDD jak w przypadku Scrum-a, który niby nie wymaga analizy i projektu.
TDD powinno zacząć się od testów akceptacyjnych zgodnie z "User story", które wzięliśmy do sprintu.
W ten sposób określamy co tak na prawdę mamy zaimplementować a nie w jaki sposób.
Pozwala oszczędzić masę problemów przed napisaniem choćby linijki kodu produkcyjnego.

Temat: TDD, testowanie i inne takie

Nie polemizuje, można się spotkać, obgadać pierwsze user story, zacząć coś kodować, nawet pokazać ekran do tego user story, zrobić sprinta i scruma, potem drugie user story, a potem odkryć, że czwarte jest jakieś sprzeczne z poprzednimi (w końcu klient nam daje co mu się uda dać) i przemodelować całość lub kleić dalej.... na pewno jest to jakaś metoda...

Temat: TDD, testowanie i inne takie

Samo TDD, czyli pisanie testów przed implementacją kodu, jest wartościową techniką w przypadku stosowania metod zwinnych przy prowadzeniu projektów. Dlaczego?
Jeżeli przed pierwszą linijką kodu przeprowadzona została by analiza i programistom zostałby przedstawiony kompletny projekt aplikacji, to zakładam, że zawierałby on również odpowiednią (minimalną) ilość scenariuszy użycia, które pozwoliłyby określić, czy funkcjonalność spełnia wymagania.
W takim wypadku, testy przed implementacją nie dają większych korzyści, ponieważ czy nie sprowadza się to (testy przed kodem) do tworzenia scenariuszy użycia? Więc jaka jest korzyść, gdy te scenariusze są już gotowe?
Co innego, gdy prowadzimy projekt wg metodyk zwinnych. Zazwyczaj (nigdy?) nie mamy przeprowadzonej tak dogłębnej analizy i kompletnego projektu, więc pisanie testów przed implementacją pozwala jeszcze raz zastanowić się nad wszystkim i spojrzeć na US jak użytkownik, a nie programista.

Zastanawiam się jeszcze nad stwierdzeniem @Jarka, że:

testy jednostkowe niczego nie testują (poza jakością kodowania)
dopóki nie sprawdzimy, że te kilka czy kilkanaście przetestowanych każda z osobna
klas, da w efekcie poprawna fakturę VAT.

i po części muszę się zgodzić.
Prawda jest taka, że dopóki nie napiszemy testów, które sprawdzą, czy zaimplementowana funkcjonalność spełnia wymagania, to tak naprawdę mamy tony linijek kodu, który mówi nam, że klasy zachowują się tak, jak sobie to założyliśmy (czyli niewiele).
Jednak, jeżeli mamy projekt danej funkcjonalności, to na jego podstawie wiemy, jak konkretne klasy powinny się zachowywać i testy jednostkowe sprawdzające poprawność tych zachowań pozwalają nam stwierdzić, że zmierzamy w dobrym kierunku.

Temat: TDD, testowanie i inne takie

Jednak, jeżeli mamy projekt danej funkcjonalności, to na jego podstawie wiemy, jak konkretne klasy powinny się zachowywać i testy jednostkowe sprawdzające poprawność tych zachowań pozwalają nam stwierdzić, że zmierzamy w dobrym kierunku.

i idźmy dalej: jedna funkcjonalność jest ok, druga także nam dobrze wyszła ale prędzej czy później odkrywamy, że one korzystają ze wspólnych klas dziedzinowych:





w efekcie klasy sterujące z jednej strony są hermetyzowane ale odkrycie w trakcie projektu nowych "encji" lub nowych cech już istniejących (np. coś było proste a nagle okazuje się złożonym agregatem) powoduje, że testy jednostkowe pilnują nam zgodności interfejsu ale jego poszerzenie wymaga także ingerencji w testy, taki zwinny projekt staje się szybko jednym wielkim pasmem refaktoryzacji... zanim produkt trafi do klienta....Jarek Żeliński edytował(a) ten post dnia 04.11.12 o godzinie 10:29

Temat: TDD, testowanie i inne takie

Sebastian Malaca:
O refaktoryzacji... schodzimy na waterfall vs agile:)
O tdd i testowaniu... to samo:P
Może rzeczywiście to pora na osobny wątek? Tylko, że co z tego by wyszło? Lubię takie dyskusję, ale nie ukrywajmy - są czysto akademickie.

:D

Pisz za siebie; nie wiem jak w przypadku innych uczestników, ale _swoje_ wnioski wysnuwam na podstawie _swoich_ doświadczeń.

Czy wszystko to o czym tu piszesz jest tylko i wyłącznie rezultatem "eksperymentu myślowego" ? :)

Zgodzę się z Jakubem, że agile to "zmiany, zmiany, zmiany" i chciałbym, aby projekt miał z góry wszystko ustalone, ale tak nie jest,

Jak pracuje się z kompetentnymi ludźmi to "jest". Zapewniam Cię.

a ja na to wpływu niestety nie mam. Dlatego też wybór padł na Scrum'a, pomaga zapanować w jakimś stopniu nad chaosem.

Aha, czyli ludzie którzy nie potrafili dokładnie określić celu projektu, mogą dobrze dobrać metody jego realizacji. Super. To wielkie szczęście pracować w zespole, którego "głowa" najwyraźniej nie ma pojęcia o niczym (nawet o tym, czego chce) ale jednocześnie zna sposoby na rozwiązanie problemu swojej niekompetencji. :D

Mimo wszystko chciałbym jeszcze raz spróbować do tych testów wrócić. Z mojej perspektywy, czyli osoby, która prowadzi projekt wg Scrum'a, testowanie przydaje się, bo:

Pozwala zweryfikować, czy dana rzecz spełnia jakieś warunki.
Bardzo przydatne kiedy się coś projektuje i chce się mieć pewność, że wszystko zadziała "tak jak zaplanował".

- w przypadku wprowadzenia zmian wiem, że przez przypadek nie wpłynąłem negatywnie na wcześniejszą funkcjonalność

Nieprzechodzący test daje informacje tylko taką, że "coś działa niezgodnie z założeniami".
Jakie konkretne wnioski można wysnuć na podstawie takiej informacji w kontekście "zmiany" i braku konkretnych założeń (planów / projektu) ?

Dlaczego tdd:

Ponieważ daje złudzenie posiadania kompetencji; efektywnego realizowania projektu.

A jakie plusy i minusy testowania i tdd widzą nie-agileowcy?

Testowania - pozwala zweryfikować fakt czy dana rzecz spełnia swoją rolę.
TDD - daje poczucie bycia kompetentnym ludziom niekompetentnym przez co Ci ludzie pozostaną "na zawsze" niekompetentni. To znaczy: ograniczenie konkurencji, możliwość windowania cen poważnym klientom. Chyba stanę się wielkim zwolennikiem ogólnie pojętych metod agile ;)

Temat: TDD, testowanie i inne takie

Jakub Wojt:
Testowania - pozwala zweryfikować fakt czy dana rzecz spełnia swoją rolę.
TDD - daje poczucie bycia kompetentnym ludziom niekompetentnym przez co Ci ludzie pozostaną "na zawsze" niekompetentni. To znaczy: ograniczenie konkurencji, możliwość windowania cen poważnym klientom. Chyba stanę się wielkim zwolennikiem ogólnie pojętych metod agile ;)

Zależy jak postrzegasz TDD - jeżeli uważasz, że dzięki testom twój kod będzie bezbłędny to trzymaj się jak najdalej od TDD.
Jakiekolwiek testy nie informują o tym, że kod nie zawiera błędów a jedynie to, że spełnia zadane w teście warunki.
Tyle i tylko tyle.

Temat: TDD, testowanie i inne takie

Myślę, że dalsza dyskusja (np. z Jakubem) nie ma sensu.
Dlaczego?

Ponieważ nie ma sensu żeby np. Jakub zmieniał cokolwiek w swoich projektach jeśli obecnie odnoszą one sukcesy.
W takim razie po co mu Agile, TDD itd.?

Tak samo projekty, które świetnie sobie radzą w podejściu Agile-owym nie powinny nagle przechodzić na Waterfall, tylko dlatego, że wg kogoś Waterfall jest "bardziej pro".

Agile zachęca do szukania rozwiązań problemów, które rzeczywiście przyprawiają nas o (lekki) ból głowy. Dlatego jeśli nie ma problemów to nie ma sensu cokolwiek zmieniać.

Z tego co można wywnioskować po wypowiedziach Jakuba to pracuję dla super klientów, z super analitykami, super projektantami, super programistami i wszystkim super, więc w takim środowisku rzeczywiście głupim byłoby wdrażanie nowych technik.
Nic tylko pozazdrościć.