Czy jest możliwe prawidłowe nazwanie siebie (lub zespołu) „Agile”, jeśli nie wykonasz TDD (Test-Driven Development)?

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

@unclebobmartin: http://t.co/huxAP5cS Chociaż nie jest niemożliwe wykonanie Agile bez TDD i OOD, jest to trudne. Bez TDD współczynnik iteracji ...

(Link w tweecie to pełna odpowiedź na LinkedIn)

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

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

• Istnieją sposoby na zwinność bez TDD

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:

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.

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

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

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

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