jeśli przeczytacie wszystkie odpowiedzi, wszystkie się zgadzają. możesz twierdzić, że jesteś zwinny bez robienia TDD, ponieważ „zwinny” jest rozmytym manifestem, a nie konkretną metodologią. Ale nie widziałem żadnej odpowiedzi poniżej, która brzmiałaby „och tak, pierwszy test nie jest konieczny” ;-)
Steven A. Lowe
Można się obejść bez TDD, ale po co kaleczyć się i przejść 7 mil po śniegu?
Job
3
@Job - właśnie o to mi chodzi. Chociaż „zwinny” nie określa wyraźnie wykonywania TDD, czy w rzeczywistości jest ogólnie akceptowane, że „zwinność” obejmuje „wykonywanie TDD” (lub przynajmniej testowanie jednostkowe)?
CraigTP
2
Dlaczego tak bardzo zależy ci na „zwinności” ??? Czy nie masz powodów do zmartwień, takich jak pisanie oprogramowania, które zachwyca klientów?
xpmatteo,
1
@ShadowChaser Rozumiem, co mówisz, ale przez chwilę grałem w adwokata diabła w sprawie Agile Point # 1, gdybym był w zespole, który rozwijał się w stylu wodospadu, ale mieliśmy świetną komunikację i współpracę między członkami tego zespół, czy to sprawiłoby, że jesteśmy zwinni?
CraigTP
Odpowiedzi:
50
Tak, tak, tak, milion razy tak.
Zwinność to filozofia, TDD to specyficzna metodologia.
Gdybym chciał być naprawdę wybredny, mógłbym po prostu wskazać, że istnieje wiele odmian xDD - które ich zwolennicy wyjaśnią w głębi, nie są TDD - ale nadal są one zasadniczo związane z testem, więc oszustwo.
Więc powiedzmy to - możesz być zwinny bez robienia programowania „najpierw testuj” (spójrz na sposób, w jaki działa Scrum - nigdzie nie ma żadnych szczegółów na temat pisania kodu). Spójrz na tablicę Kanban, spójrz na wszelkiego rodzaju zwinne metodologie.
Czy chcesz testy jednostkowe? Oczywiście, że tak, z różnych powodów - i możesz argumentować, że nie możesz być zwinny bez testów jednostkowych (choć podejrzewam, że możesz) - ale nie musisz ich najpierw pisać, aby być zwinny.
I na koniec, równie prawdą jest, że mógłbyś wykonać Test First bez zwinności i mocne argumenty za przeprowadzeniem testu najpierw bez względu na ogólną filozofię programistów.
Wygląda na to, że inni (z bardziej SOLIDNYM przedstawicielem) mają podobną opinię ...
+1 za to jesteś zwinny w ogólnym działaniu, nie dlatego, że używasz tej czy innej metodologii.
10
Testy jednostkowe muszą być zwinne. Po prostu nie musisz ich najpierw pisać.
Macneil
6
@Mcneil: Nie musisz pisać testów jednostkowych, aby „być zwinnym”. TDD i UT same w sobie są świetnymi praktykami, ale nie są wymagane ani nawet wspomniane w zwinnym manifeście.
Martin Wickman
4
@Marin: brak rozwoju metod w ogóle są wymienione w manifeście
Steven A. Lowe
4
Właśnie rozpocząłem pracę w dużej firmie korzystającej z SCRUM do prowadzenia projektów. Projekt, nad którym pracuję, to SCRUM (poprawnie!), Ale kod nie zawiera testów jednostkowych. Brak testów jednostkowych nie wpływa na umiejętność korzystania z SCRUM ani na zwinność, ale wpływa na moją pewność co do jakości kodu, a także szybkie wprowadzanie zmian (z pewnością). Biorąc pod uwagę brak dokumentacji, która jest tworzona w Agile, myślę, że pisanie testów jako pierwszy, ostatni lub w środku jest ogromną korzyścią z pozostania Agile (do zmiany).
Rob Gray
19
„Bycie zwinnym” oznacza po prostu przestrzeganie wartości i zasad manifestu zwinnego . Nic w tym dokumencie nie wspomina o TDD ani nawet testach jednostkowych w tym zakresie.
Tak, możesz być zwinny bez przeprowadzania testów TDD i testów jednostkowych.
@Martin: dobrze powiedziane - w manifeście nie określono żadnych praktyk programistycznych. To deklaracja misji, a nie metodologia.
Steven A. Lowe
4
@Martin: Istnieje różnica między procesem zwinnym a zasadami zwinności. Jeśli potrafisz nazwać zwinny proces, który nie ma testów, zrób to.
Macneil
@Macneil: Scrum nie ma testów.
Martin Wickman,
2
@Martin: ponownie Scrum jest metodą zarządzania projektami , a nie metodologią tworzenia oprogramowania. Scrum jest zwykle używany z metodologią Agile Development, taką jak XP, ale nie jest jego substytutem
Steven A. Lowe
@Steven: Dziękuję za wyjaśnienie mojej odpowiedzi, że Scrum nie zawiera praktyk programistycznych, takich jak testowanie. Myślę, że punkt ten jest już dobrze ugruntowany :-)
Martin Wickman
11
Tak ,
Spójrz na jedną z zwinnych wartości:
Osoby i interakcje dotyczące procesów i narzędzi
To powinno już na nie odpowiedzieć. TDD to pewna metodologia, proces. Rzeczywiście proces, który może być wykorzystany w zwinnych procesach programistycznych, ale nic więcej. Myślę, że może TDD jest najnowocześniejszy, kiedy jest zwinny. Myślę jednak, że koncepcja zwinności nadal będzie w stanie przetrwać, nawet jeśli TDD zostanie zastąpione innymi praktykami.
Podsumowałbym to tak:
Dzisiaj TDD jest standardem defacto dla bycia zwinnym
Jeśli wrócisz do oryginalnego źródła, http://en.wikipedia.org/wiki/Extreme_Programming TDD jest podstawą procesu; testy zastępują specyfikacje wymagań i przypadki użycia wodospadu, służą jako żywa dokumentacja i przykłady funkcjonowania itp. Są niezbędne.
Jednak jest tak wiele różnych smaków „zwinnych” unoszących się wokół, że jest całkiem możliwe, że jeden z nich unika TDD
EDYCJA: @ Murph interpretacja pytania wydaje się być preferowana. Cholera, nawet go głosowałem, to dobra odpowiedź. Jednak , ja utrzymać swoją pozycję, że Agile Manifesto jest zbiorem zasad, a nie metodologii rozwoju. Nie widzę sensu w mówieniu „o tak, jestem zwinny” bez faktycznego wdrażania praktyk, które przynoszą korzyści. W szczególności:
Działające oprogramowanie jest podstawową miarą postępu.
i
Zwinne procesy promują zrównoważony rozwój. Sponsorzy, programiści i użytkownicy powinni mieć możliwość utrzymywania stałego tempa w nieskończoność.
Dla mnie te dwie zasady sugerują, jeśli nie wymagają TDD - przynajmniej nie znam innego sposobu, aby je osiągnąć bez niego!
EDYCJA 2: tak, technicznie można później napisać testy; ale nadal uważam test-pierwszy / TDD za fundamentalny. Nie dlatego, że nie możesz „być zwinny” bez niego, ale dlatego, że będziesz z nim bardziej zwinny. Test „najpierw test / test” jest o wiele bardziej wydajnym podejściem niż test później / test po przemyśleniu. Opisy testów są wymaganiami . Nie odkładaj ich na później ;-)
EDYCJA 3: W końcu zorientowałem się, co tak bardzo mnie martwi w bardzo dobrze napisanej odpowiedzi Murpha. Chodzi o to, że można „być zwinnym”, nie robiąc tego . A „robienie tego” (jak pokazano powyżej) prawie wymaga TDD.
Nigdzie na tej stronie nie podano TDD ani Test First, z wyjątkiem linku do powiązanej strony.
Murph
2
Pracowałem jako programista ekstremalny w latach 2000-2001. Tak, pisaliśmy testy jednostkowe, ale prawie zawsze najpierw pisaliśmy kod, a następnie testowaliśmy go później.
Michael Shaw
1
Zły wybór słów. Powtórzmy to: Zwinność to nie tylko programowanie ekstremalne; Scrum i Kanban mogą być również postrzegane jako zwinne metodologie i żadne z nich nie wymusza stosowania TDD tak jak XP
t3mujin
2
@Murph: pierwsze zdanie było najważniejsze. @Ptolemy: to źle zrobiłeś ;-) @ t3mujin, chyba żartujesz!
Steven A. Lowe
4
+1: Jestem spóźniony na przyjęcie, ale to jedyna przydatna odpowiedź. Powiedzenie, że możemy wykonywać TDD bez testów, jest jak powiedzenie, że możemy zdać egzamin na kierowcę bez wiedzy na temat prowadzenia pojazdu. Tak, jest to możliwe, ale prawie nie. Jak powiedział Michael Feathers , „Legacy Code to kod bez testów”. A kod, który z definicji jest trudny do utrzymania, jest cholernie trudny do pracy, gdy używasz zwinnego, iteracyjnego procesu.
rsenna
2
Ściśle mówiąc, jesteś zwinny, stosując się do zwinnego manifestu . W praktyce baza kodu nie jest zwinna, chyba że ma dobre pokrycie testowe. Możesz wykonywać TDD i pisać testy przed / w trakcie opracowywania funkcjonalności lub pisać testy funkcjonalności po jej opracowaniu. Zwykle jest to jednak łatwiejsze i bardziej skuteczne, gdy robi się to TDD.
Możesz być zwinny, ale prawdopodobnie jest miejsce na ulepszenia.
Jedną z zasad zwinnych jest to, że musisz być w stanie reagować na zmiany. Oznacza to, że nie wiesz z góry, co musisz zbudować. Gdybyś śledził proces wodospadu, wiedziałbyś x miesiące wcześniej dokładnie, co musisz zbudować, i możesz zaprojektować poszczególne komponenty oprogramowania, aby każdy z nich uczestniczył w jakimś większym schemacie, docierając do produktu końcowego (przynajmniej byś pomyślał, że to było tak). Ale ponieważ zwinny nakazuje, że nie wiesz, co to jest produkt końcowy, nigdy nie wiesz, do czego zostanie użyty kod, a co ważniejsze, kiedy zostanie on zmieniony.
Dlatego potrzebujesz dokładnego zestawu testów, aby upewnić się, że funkcje, które już zbudowałeś, będą nadal działać po zmodyfikowaniu podstawy kodu.
Ale to samo nie jest TDD. Jeśli napiszesz testy po napisaniu kodu, nie będzie to TDD. Ale TDD pomaga w innym aspekcie, zapobiega nadprodukcji.
W moim zwinnym zespole borykam się z programistami piszącymi kod, który ich zdaniem przyda się w późniejszym etapie projektu. Gdyby to był rozwój wodospadu, byłoby to prawdopodobnie w porządku, ponieważ dodawali wsparcie dla czegoś w planie projektu na następne x miesięcy.
Ale jeśli przestrzegasz zwinnych zasad, nie powinieneś pisać tego kodu, ponieważ nie masz pojęcia, czy będzie to konieczne. Funkcja zaplanowana na przyszły tydzień może zostać nagle odłożona na czas nieokreślony.
Jeśli poprawnie przestrzegasz zasady TDD, to jeden wiersz kodu nie może istnieć, zanim test nie podyktuje tego wiersza kodu (osobiście mogę napisać trywialny kod bez testowania), a jeśli zaczniesz od napisania testu akceptacyjnego, wówczas zaimplementujesz tylko dokładnie to, co jest potrzebne do zapewnienia wymaganych funkcji.
TDD pomaga więc uniknąć nadprodukcji, pozwalając zespołowi być jak najbardziej efektywnym, co jest również podstawową zasadą zwinności.
Działające oprogramowanie jest podstawową miarą postępu
Czy potrafisz być zwinny bez robienia TDD (programowanie testowe)?
Krótka odpowiedź: tak.
Dłuższa odpowiedź: Istnieje wiele naprawdę dobrych odpowiedzi na to pytanie i bardzo dobre referencje. Nie będę próbował omawiać tych kwestii.
Z mojego doświadczenia wynika, że Agile polega na wybraniu odpowiedniego poziomu Lean-ness dla danego projektu. Co mam na myśli przez Lean-ness? I dlaczego włączam to do tej odpowiedzi?
Lean nie oznacza wycinania wszystkiego, co możliwe z twojej metody. Jak zauważył jeden z naszych kolegów, nie musisz uwzględniać TDD ani testu jednostkowego w swoich zachowaniach. Jednak w kontekście projektu może się okazać, że może być korzystne.
Pomyślmy o łańcuchu dostaw dla dużego, nienazwanego detalisty z AK. Jest konsument. Idą do sklepu. Sklep odbiera różne produkty za pośrednictwem ciężarówki. Prawdopodobnie ciężarówki dostają te produkty z magazynu. Magazyn jest zapełniany przesyłkami różnych producentów. Producenci z kolei sami mają cały łańcuch dostaw.
Co się stanie, gdy dyrektorowi generalnemu ds. Wysyłki w powyższym łańcuchu dostaw powiedziano, że dostanie premię roczną w wysokości 1 miliona USD za każdy rok, w którym ma mniej niż 10 ciężarówek we flocie? Natychmiast pokroi flotę na 9 ciężarówek. W tym „okropnym” scenariuszu spowoduje to zwiększenie ilości towarów przechowywanych w magazynie (zwiększenie kosztów w tym węźle). I „zagłodzi” fronty sklepu.
Tak więc cały łańcuch dostaw cierpi, jeśli lokalna optymalizacja jest dozwolona bez uwzględnienia całości.
Powrót do TDD i UT. TDD jest mechanizmem wyrażania wymagań. System MUSI wykonać te ograniczenia. Słusznie. TDD może zastąpić zachowanie wymagań aplikacji Case Drive Development lub zachowanie wymagań User Driven Development. Ma tę zaletę polegającą na połączeniu obciążeń roboczych testu jednostkowego i wymagań. Korzyścią jest zmniejszenie całkowitego obciążenia pracą. Nie jest tak, jeśli ogólne obciążenie pracą łańcucha dostaw wzrośnie (poprawmy jakość).
I tak zapytałeś: czy potrafisz być zwinny bez robienia TDD (testowanie rozwoju)?
Oczywiście że możesz. Innym, a może lepszym pytaniem jest: - Jeśli zastosuję TDD do tego projektu, czy spowoduje to ogólnie bardziej wydajne dostarczanie oprogramowania, czy mniej wydajne?
Cytując ulubionego autora ... JRR Tolkien
Władca Pierścieni. Drużyna Pierścieni. Str. 94 „I powiedziane jest również”, odpowiedział Frodo, „Nie idź do elfów po radę, bo zarówno oni nie, jak i tak”.
W końcu ... to zależy. Musisz odpowiedzieć na pytanie. Która ścieżka najskuteczniej doprowadzi Cię do pożądanych celów.
Jeśli miałbyś zaprojektować zamek za pomocą Agile. Pisałeś fragmenty, które mają określone funkcje i zachęcasz użytkownika do korzystania z części funkcjonalnych, dostosowując przyszły projekt do reakcji użytkownika. Więc budujesz loch i komunikujesz się z opiekunem lochu, testujesz fundamenty ziemi i lochu. Zbudujesz parapety i zapytasz strażników nocnych, czy są dobre. Zbudowałbyś ściany i kazałbyś żołnierzom sprawdzić wartość obrony. Zbudowałbyś kuchnię, a kucharze ją obejrzą. Podczas tego procesu każda dotychczasowa część działałaby oprócz obecnej struktury. Kiedy skończysz loch, możesz wprowadzić więźniów do środka. I tak dalej. Ale kiedy w końcu ukończyłeś zamek, okazuje się, że więźniowie uciekli.
Zamek TDD
Dzięki TDD pojawiasz się z więźniami i sprawdzasz, czy uciekną. Następnie piszesz komórki więzienne, dopóki nie będą mogły uciec. Następnie przebuduj kod, usuwając niepotrzebne komórki i usuwając paski znajdujące się w niewłaściwej lokalizacji, i ponownie przetestuj. Więźniowie nie uciekli. Nie musisz komunikować się z dozorcą. I możesz dostarczyć cały zamek, kiedy skończysz wszystko. W tym momencie więzień mówi, że loch potrzebuje więcej komórek, a teraz musisz wykopać więcej fundamentów.
Zwinny zamek TDD
Jeśli połączysz Agile i TDD. Zobaczysz, czy więźniowie uciekli, a następnie zapytaj strażnika, co jest potrzebne. Mówi, że potrzebujesz więcej komórek. Zabrałbyś przypadkowych ludzi, by udawać więźniów i sprawdził, czy uciekną. Jeśli nie, pokażesz to więzieniu, a on jest z tego zadowolony. Następnie zaczynasz budować attyki.
Wniosek
Więc oba rozwiązują różne problemy. Zwinne pomaga w zmienianiu wymagań w oparciu o odkrywanie potrzeb użytkowników, gdy widzą, jak produkt rozwija się na etapie procesu, w którym najłatwiej jest go dostosować. Polega ona na wypuszczeniu stabilnych dodatków w oderwaniu od ogólnego projektu.
TDD rozwiązuje problem przewidywania awarii. Wykrywanie i korygowanie awarii w momencie, w którym najłatwiej je naprawić. Polega ona na testowaniu stabilnych, odłączonych od siebie jednostek kodu w podziale na ogólny projekt.
Łatwo jest zobaczyć TDD jako rozszerzenie Agile, ponieważ oba postępują zgodnie z tym samym schematem, postępem i przeglądem sterowanym jednostkami. Różnica polega na tym, że jednostki w Agile działają jak dotąd zewnętrznie jako całość, podczas gdy jednostki w TDD działają jako część i mogą nie wytwarzać funkcjonującego produktu do oceny zewnętrznej. Oba procesy regulują różne potrzeby (użyteczność vs. poprawność). Ponieważ oba działają w procesie rozwoju w jednostkach, oba procesy przeglądu mogą zachodzić w podobnych punktach, przy czym TDD jest bardziej precyzyjnie podzielony.
Notatki
Same testy jednostkowe nie oznaczają, że korzystasz z TDD. TDD oznacza przeprowadzenie testu przed wyprodukowaną jednostką i korzystanie z testu w miarę rozwoju w celu potwierdzenia jednostki. Testy jednostkowe bez TDD mogą być użyte, aby upewnić się, że nie unieważniasz wcześniej zbudowanej funkcjonalności.
Posiadanie sprintu i innych spotkań nie czyni cię zwinnym. Cel manifestu sprawia, że jesteś zwinny. Możesz rozbić cele wodospadu na sprinty za pomocą jednostek pracy, bez spełniania zobowiązania do faworyzowania ludzi nad procesami.
Z definicji TDD i Agile. Twoje testy jednostkowe będą rządziły jednostkami niedostarczalnymi, więc TDD będzie jeździć szybciej niż Agile. A jeśli zastosujesz oba, Twoje cykle Agile będą zawierać jeden lub więcej cykli TDD (jeśli każda jednostka zostanie przetestowana).
Z tego, co rozumiem: nie udaje ci się zwinnie, nie opracowując użytecznej / znaczącej jednostki dla użytkownika. Jednostka może mieć znaczenie, nawet jeśli przyspieszy produkt. Ale w jaki sposób Agile wyjaśnia refaktoryzację dla łatwiejszej konserwacji? Nie opisałem tego wystarczająco, by na to odpowiedzieć.
Nie udaje ci się TDD, jeśli nie przejdzie testu jednostkowego. Tworzenie kodu, który nie produkuje poprawnie funkcji.
Zwinny zmusza Cię do rozwiązywania i ograniczania ryzyka związanego z harmonogramem i jakością przy każdej iteracji. tzn. TDD nie musi być uważany za zwinny .
TDD jest jednak ogromną techniką ograniczania ryzyka jakościowego, szczególnie w przypadku projektu z dużą liczbą iteracji lub osób. W takim projekcie TDD doda pewne ryzyko związane z harmonogramem we wczesnych iteracjach, ponieważ musisz również napisać przypadki testowe. Jednak TDD zapewnia ogromne oszczędności kosztów w późniejszych iteracjach, ponieważ stale zmniejsza ryzyko związane z jakością. tzn . zalecane jest TDD.
Odpowiedzi:
Tak, tak, tak, milion razy tak.
Zwinność to filozofia, TDD to specyficzna metodologia.
Gdybym chciał być naprawdę wybredny, mógłbym po prostu wskazać, że istnieje wiele odmian xDD - które ich zwolennicy wyjaśnią w głębi, nie są TDD - ale nadal są one zasadniczo związane z testem, więc oszustwo.
Więc powiedzmy to - możesz być zwinny bez robienia programowania „najpierw testuj” (spójrz na sposób, w jaki działa Scrum - nigdzie nie ma żadnych szczegółów na temat pisania kodu). Spójrz na tablicę Kanban, spójrz na wszelkiego rodzaju zwinne metodologie.
Czy chcesz testy jednostkowe? Oczywiście, że tak, z różnych powodów - i możesz argumentować, że nie możesz być zwinny bez testów jednostkowych (choć podejrzewam, że możesz) - ale nie musisz ich najpierw pisać, aby być zwinny.
I na koniec, równie prawdą jest, że mógłbyś wykonać Test First bez zwinności i mocne argumenty za przeprowadzeniem testu najpierw bez względu na ogólną filozofię programistów.
Wygląda na to, że inni (z bardziej SOLIDNYM przedstawicielem) mają podobną opinię ...
http://www.twitter.com/unclebobmartin/status/208621409663070208
(Link w tweecie to pełna odpowiedź na LinkedIn)
źródło
„Bycie zwinnym” oznacza po prostu przestrzeganie wartości i zasad manifestu zwinnego . Nic w tym dokumencie nie wspomina o TDD ani nawet testach jednostkowych w tym zakresie.
Tak, możesz być zwinny bez przeprowadzania testów TDD i testów jednostkowych.
Nie poleciłbym tego jednak ...
źródło
Tak ,
Spójrz na jedną z zwinnych wartości:
To powinno już na nie odpowiedzieć. TDD to pewna metodologia, proces. Rzeczywiście proces, który może być wykorzystany w zwinnych procesach programistycznych, ale nic więcej. Myślę, że może TDD jest najnowocześniejszy, kiedy jest zwinny. Myślę jednak, że koncepcja zwinności nadal będzie w stanie przetrwać, nawet jeśli TDD zostanie zastąpione innymi praktykami.
Podsumowałbym to tak:
Dzisiaj TDD jest standardem defacto dla bycia zwinnym
Istnieją sposoby na zwinność bez TDD
źródło
mówię
Nie [tak]
Jeśli wrócisz do oryginalnego źródła, http://en.wikipedia.org/wiki/Extreme_Programming TDD jest podstawą procesu; testy zastępują specyfikacje wymagań i przypadki użycia wodospadu, służą jako żywa dokumentacja i przykłady funkcjonowania itp. Są niezbędne.
Jednak jest tak wiele różnych smaków „zwinnych” unoszących się wokół, że jest całkiem możliwe, że jeden z nich unika TDD
EDYCJA: @ Murph interpretacja pytania wydaje się być preferowana. Cholera, nawet go głosowałem, to dobra odpowiedź. Jednak , ja utrzymać swoją pozycję, że Agile Manifesto jest zbiorem zasad, a nie metodologii rozwoju. Nie widzę sensu w mówieniu „o tak, jestem zwinny” bez faktycznego wdrażania praktyk, które przynoszą korzyści. W szczególności:
i
Dla mnie te dwie zasady sugerują, jeśli nie wymagają TDD - przynajmniej nie znam innego sposobu, aby je osiągnąć bez niego!
EDYCJA 2: tak, technicznie można później napisać testy; ale nadal uważam test-pierwszy / TDD za fundamentalny. Nie dlatego, że nie możesz „być zwinny” bez niego, ale dlatego, że będziesz z nim bardziej zwinny. Test „najpierw test / test” jest o wiele bardziej wydajnym podejściem niż test później / test po przemyśleniu. Opisy testów są wymaganiami . Nie odkładaj ich na później ;-)
EDYCJA 3: W końcu zorientowałem się, co tak bardzo mnie martwi w bardzo dobrze napisanej odpowiedzi Murpha. Chodzi o to, że można „być zwinnym”, nie robiąc tego . A „robienie tego” (jak pokazano powyżej) prawie wymaga TDD.
źródło
Ściśle mówiąc, jesteś zwinny, stosując się do zwinnego manifestu . W praktyce baza kodu nie jest zwinna, chyba że ma dobre pokrycie testowe. Możesz wykonywać TDD i pisać testy przed / w trakcie opracowywania funkcjonalności lub pisać testy funkcjonalności po jej opracowaniu. Zwykle jest to jednak łatwiejsze i bardziej skuteczne, gdy robi się to TDD.
źródło
Możesz być zwinny, ale prawdopodobnie jest miejsce na ulepszenia.
Jedną z zasad zwinnych jest to, że musisz być w stanie reagować na zmiany. Oznacza to, że nie wiesz z góry, co musisz zbudować. Gdybyś śledził proces wodospadu, wiedziałbyś x miesiące wcześniej dokładnie, co musisz zbudować, i możesz zaprojektować poszczególne komponenty oprogramowania, aby każdy z nich uczestniczył w jakimś większym schemacie, docierając do produktu końcowego (przynajmniej byś pomyślał, że to było tak). Ale ponieważ zwinny nakazuje, że nie wiesz, co to jest produkt końcowy, nigdy nie wiesz, do czego zostanie użyty kod, a co ważniejsze, kiedy zostanie on zmieniony.
Dlatego potrzebujesz dokładnego zestawu testów, aby upewnić się, że funkcje, które już zbudowałeś, będą nadal działać po zmodyfikowaniu podstawy kodu.
Ale to samo nie jest TDD. Jeśli napiszesz testy po napisaniu kodu, nie będzie to TDD. Ale TDD pomaga w innym aspekcie, zapobiega nadprodukcji.
W moim zwinnym zespole borykam się z programistami piszącymi kod, który ich zdaniem przyda się w późniejszym etapie projektu. Gdyby to był rozwój wodospadu, byłoby to prawdopodobnie w porządku, ponieważ dodawali wsparcie dla czegoś w planie projektu na następne x miesięcy.
Ale jeśli przestrzegasz zwinnych zasad, nie powinieneś pisać tego kodu, ponieważ nie masz pojęcia, czy będzie to konieczne. Funkcja zaplanowana na przyszły tydzień może zostać nagle odłożona na czas nieokreślony.
Jeśli poprawnie przestrzegasz zasady TDD, to jeden wiersz kodu nie może istnieć, zanim test nie podyktuje tego wiersza kodu (osobiście mogę napisać trywialny kod bez testowania), a jeśli zaczniesz od napisania testu akceptacyjnego, wówczas zaimplementujesz tylko dokładnie to, co jest potrzebne do zapewnienia wymaganych funkcji.
TDD pomaga więc uniknąć nadprodukcji, pozwalając zespołowi być jak najbardziej efektywnym, co jest również podstawową zasadą zwinności.
źródło
Czy potrafisz być zwinny bez robienia TDD (programowanie testowe)?
Krótka odpowiedź: tak.
Dłuższa odpowiedź: Istnieje wiele naprawdę dobrych odpowiedzi na to pytanie i bardzo dobre referencje. Nie będę próbował omawiać tych kwestii.
Z mojego doświadczenia wynika, że Agile polega na wybraniu odpowiedniego poziomu Lean-ness dla danego projektu. Co mam na myśli przez Lean-ness? I dlaczego włączam to do tej odpowiedzi?
Lean nie oznacza wycinania wszystkiego, co możliwe z twojej metody. Jak zauważył jeden z naszych kolegów, nie musisz uwzględniać TDD ani testu jednostkowego w swoich zachowaniach. Jednak w kontekście projektu może się okazać, że może być korzystne.
Pomyślmy o łańcuchu dostaw dla dużego, nienazwanego detalisty z AK. Jest konsument. Idą do sklepu. Sklep odbiera różne produkty za pośrednictwem ciężarówki. Prawdopodobnie ciężarówki dostają te produkty z magazynu. Magazyn jest zapełniany przesyłkami różnych producentów. Producenci z kolei sami mają cały łańcuch dostaw.
Co się stanie, gdy dyrektorowi generalnemu ds. Wysyłki w powyższym łańcuchu dostaw powiedziano, że dostanie premię roczną w wysokości 1 miliona USD za każdy rok, w którym ma mniej niż 10 ciężarówek we flocie? Natychmiast pokroi flotę na 9 ciężarówek. W tym „okropnym” scenariuszu spowoduje to zwiększenie ilości towarów przechowywanych w magazynie (zwiększenie kosztów w tym węźle). I „zagłodzi” fronty sklepu.
Tak więc cały łańcuch dostaw cierpi, jeśli lokalna optymalizacja jest dozwolona bez uwzględnienia całości.
Powrót do TDD i UT. TDD jest mechanizmem wyrażania wymagań. System MUSI wykonać te ograniczenia. Słusznie. TDD może zastąpić zachowanie wymagań aplikacji Case Drive Development lub zachowanie wymagań User Driven Development. Ma tę zaletę polegającą na połączeniu obciążeń roboczych testu jednostkowego i wymagań. Korzyścią jest zmniejszenie całkowitego obciążenia pracą. Nie jest tak, jeśli ogólne obciążenie pracą łańcucha dostaw wzrośnie (poprawmy jakość).
I tak zapytałeś: czy potrafisz być zwinny bez robienia TDD (testowanie rozwoju)?
Oczywiście że możesz. Innym, a może lepszym pytaniem jest: - Jeśli zastosuję TDD do tego projektu, czy spowoduje to ogólnie bardziej wydajne dostarczanie oprogramowania, czy mniej wydajne?
Cytując ulubionego autora ... JRR Tolkien
W końcu ... to zależy. Musisz odpowiedzieć na pytanie. Która ścieżka najskuteczniej doprowadzi Cię do pożądanych celów.
Do TDD lub nie do TDD. To pozostaje pytanie. :-)
PS - Ponownie zamieszczam tę odpowiedź na innej stronie. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en
źródło
W porównaniu do inżynierii zamku.
Zwinny Zamek
Jeśli miałbyś zaprojektować zamek za pomocą Agile. Pisałeś fragmenty, które mają określone funkcje i zachęcasz użytkownika do korzystania z części funkcjonalnych, dostosowując przyszły projekt do reakcji użytkownika. Więc budujesz loch i komunikujesz się z opiekunem lochu, testujesz fundamenty ziemi i lochu. Zbudujesz parapety i zapytasz strażników nocnych, czy są dobre. Zbudowałbyś ściany i kazałbyś żołnierzom sprawdzić wartość obrony. Zbudowałbyś kuchnię, a kucharze ją obejrzą. Podczas tego procesu każda dotychczasowa część działałaby oprócz obecnej struktury. Kiedy skończysz loch, możesz wprowadzić więźniów do środka. I tak dalej. Ale kiedy w końcu ukończyłeś zamek, okazuje się, że więźniowie uciekli.
Zamek TDD
Dzięki TDD pojawiasz się z więźniami i sprawdzasz, czy uciekną. Następnie piszesz komórki więzienne, dopóki nie będą mogły uciec. Następnie przebuduj kod, usuwając niepotrzebne komórki i usuwając paski znajdujące się w niewłaściwej lokalizacji, i ponownie przetestuj. Więźniowie nie uciekli. Nie musisz komunikować się z dozorcą. I możesz dostarczyć cały zamek, kiedy skończysz wszystko. W tym momencie więzień mówi, że loch potrzebuje więcej komórek, a teraz musisz wykopać więcej fundamentów.
Zwinny zamek TDD
Jeśli połączysz Agile i TDD. Zobaczysz, czy więźniowie uciekli, a następnie zapytaj strażnika, co jest potrzebne. Mówi, że potrzebujesz więcej komórek. Zabrałbyś przypadkowych ludzi, by udawać więźniów i sprawdził, czy uciekną. Jeśli nie, pokażesz to więzieniu, a on jest z tego zadowolony. Następnie zaczynasz budować attyki.
Wniosek
Więc oba rozwiązują różne problemy. Zwinne pomaga w zmienianiu wymagań w oparciu o odkrywanie potrzeb użytkowników, gdy widzą, jak produkt rozwija się na etapie procesu, w którym najłatwiej jest go dostosować. Polega ona na wypuszczeniu stabilnych dodatków w oderwaniu od ogólnego projektu.
TDD rozwiązuje problem przewidywania awarii. Wykrywanie i korygowanie awarii w momencie, w którym najłatwiej je naprawić. Polega ona na testowaniu stabilnych, odłączonych od siebie jednostek kodu w podziale na ogólny projekt.
Łatwo jest zobaczyć TDD jako rozszerzenie Agile, ponieważ oba postępują zgodnie z tym samym schematem, postępem i przeglądem sterowanym jednostkami. Różnica polega na tym, że jednostki w Agile działają jak dotąd zewnętrznie jako całość, podczas gdy jednostki w TDD działają jako część i mogą nie wytwarzać funkcjonującego produktu do oceny zewnętrznej. Oba procesy regulują różne potrzeby (użyteczność vs. poprawność). Ponieważ oba działają w procesie rozwoju w jednostkach, oba procesy przeglądu mogą zachodzić w podobnych punktach, przy czym TDD jest bardziej precyzyjnie podzielony.
Notatki
źródło
Zwinny zmusza Cię do rozwiązywania i ograniczania ryzyka związanego z harmonogramem i jakością przy każdej iteracji. tzn. TDD nie musi być uważany za zwinny .
TDD jest jednak ogromną techniką ograniczania ryzyka jakościowego, szczególnie w przypadku projektu z dużą liczbą iteracji lub osób. W takim projekcie TDD doda pewne ryzyko związane z harmonogramem we wczesnych iteracjach, ponieważ musisz również napisać przypadki testowe. Jednak TDD zapewnia ogromne oszczędności kosztów w późniejszych iteracjach, ponieważ stale zmniejsza ryzyko związane z jakością. tzn . zalecane jest TDD.
źródło