Jakich argumentów mogę użyć, aby „sprzedać” koncepcję BDD zespołowi niechętnemu do jej przyjęcia?

Jestem trochę głośnym zwolennikiem metodologii Behavior Driven Development (aka BDD). BDD stosuję od kilku lat i przy tworzeniu aplikacji DotNet wybrałem StoryQ . Mimo że od wielu lat przeprowadzam testy jednostkowe i wcześniej przeszedłem na podejście testowe, odkryłem, że czerpię znacznie więcej korzyści z używania frameworka BDD, ponieważ moje testy wychwytują cel wymagań w stosunkowo niewielkim stopniu wyczyść język angielski w moim kodzie, a ponieważ moje testy mogą wykonywać wiele asercji bez kończenia testu w połowie - oznacza to, że mogę zobaczyć, które konkretne asercje przejdą / nie przejdą na pierwszy rzut oka bez debugowania, aby to udowodnić.

To naprawdę był wierzchołek góry lodowej, ponieważ zauważyłem również, że jestem w stanie debugować zarówno kod testowy, jak i kod implementacyjny w bardziej ukierunkowany sposób, dzięki czemu moja produktywność znacznie wzrosła i że mogę więcej łatwo ustalić, gdzie wystąpi awaria, jeśli zdarzy się problem, aby dotrzeć do kompilacji integracji ze względu na dane wyjściowe, które trafiają do dzienników kompilacji. Ponadto, StoryQ api ma piękną, płynną składnię, łatwą do nauczenia i którą można zastosować na niezwykłą liczbę sposobów, nie wymagając żadnych zewnętrznych zależności, aby z niej korzystać.

Biorąc pod uwagę wszystkie te korzyści, pomyślałbyś, że łatwo będzie przedstawić tę koncepcję reszcie zespołu. Niestety, inni członkowie zespołu niechętnie patrzą nawet na StoryQ, aby ocenić ją właściwie (nie mówiąc już o zabawie nad pomysłem zastosowania BDD) i przekonali się do próby usunięcia wielu elementów StoryQ z naszych własnych podstawowych ram testowania, nawet chociaż pierwotnie wspierali korzystanie z StoryQ, i nawet jeśli kod, który chcą usunąć, nie wpływa na żadną inną część naszego systemu testowego. Spowodowałoby to znaczne zwiększenie ogólnego obciążenia pracą i naprawdę byłoby sprzeczne z rzeczywistością, ponieważ dzięki praktycznemu doświadczeniu jestem przekonany, że jest to lepszy sposób na pracę w testach w naszym konkretnym środowisku pracy i może prowadzić tylko do większej poprawa jakości naszego oprogramowania, biorąc pod uwagę, że „ Odkryłem, że łatwiej jest trzymać się testu za pomocą BDD. W celu dalszego wyjaśnienia, większość testów jednostkowych, które mamy tendencję do bycia dość kruchymi i trudnymi w utrzymaniu, jest efektem wstecznym po latach źle zastosowanych testów, w których niechęć do trzymania się procesu testowego spowodowała, że ​​programiści powrócili do starych nawyków i wykonaj wszystkie testy pod koniec projektu (te same osoby twierdzą, że są zwinne!).

Pytanie naprawdę sprowadza się do następującego:

1. Jakich argumentów mogę użyć, aby naprawdę uświadomić sobie, że lepiej byłoby, gdyby ten zespół użył StoryQ lub przynajmniej zastosował metodologię BDD?
2. Czy możesz wskazać mi jakieś niepotwierdzone dowody, których mogę użyć na poparcie mojego argumentu za przyjęciem BDD jako naszej standardowej metody wyboru?
3. Jakie przeciwstawne argumenty mogą ci się przydać, co może sugerować, że moje życzenie zachęcenia zespołu do przyjęcia BDD może być błędne? Tak, cieszę się, że udowodniono mi błąd, pod warunkiem, że argument jest słuszny.

UWAGA : Nie zalecam przepisywania naszych testów w całości, ale raczej rozpoczęcie pracy w inny sposób dla wszystkich przyszłych prac testowych, a najlepiej w sposób, w jaki angażujemy naszych klientów.

A dla tych, którzy chcą dowiedzieć się więcej o BDD, przydatne mogą być następujące linki:

• http://dannorth.net/introducing-bdd/
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/Introduction

_{Dla osób zainteresowanych bardziej szczegółami, jesteśmy małym zespołem złożonym z 4 osób, który pracuje nad około 5 dużymi projektami. „Badanie pilotażowe” dotyczące BDD trwało początkowo przez około 2 miesiące, a następnie kolejne około 4 miesiące. Zespół zgodził się, że powinienem kontynuować pracę w ten sposób i że będę przeprowadzał własne próby. Zajmuję się BDD od około 2 lat, odkąd zakończył się okres próbny, podczas gdy inni stali się bardzo dobrzy w rozwiązywaniu problemu. Zamiast zmuszać do „konfrontacji” w tej sprawie, szukam sposobów, aby delikatnie przekonać zespół, aby odszedł od swoich zbiorowych zaległości i znalazł czas na zrobienie czegoś.}

Jakich argumentów mogę użyć, aby naprawdę uświadomić sobie, że lepiej byłoby zastosować StoryQ, a przynajmniej zastosować metodologię BDD?

„Klient tego chce”.

IMO chcesz sprzedać BDD swoim klientom / ekspertom domeny przynajmniej tyle samo, co zespołowi programistów.

BDD to wspólny proces zewnętrzny, w który zaangażowanych jest wielu interesariuszy. Korzyści z BDD to nie tylko dla programistów automatyczne wnioskowanie kodu testowego z testów akceptacyjnych, ale także kreatywna współpraca między pracownikami technicznymi i biznesowymi w celu stworzenia cennych, dobrze określonych specyfikacji zamierzonego zachowania systemu.

Umożliwienie klientom / analitykom biznesowym dostępu do interfejsu, w którym mogą oni uruchamiać każdą specyfikację wykonywalną, kontrolować ich status i obserwować postęp w ich wdrażaniu, jest również ogólnie mile widziane.

Dan North przedstawił prezentację na temat tego, jak sprzedać BDD firmie: http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

1. W zespole niechętnie adoptującym BDD prawdopodobnie nie ma „argumentów”, których można by użyć do „przekształcenia” kolegów w adopcję na pełną skalę.
    
   Myślę, że najlepsze, co możesz zrobić, to przekonać ich, aby spróbowali („test dymu”, „próba na sucho”, „projekt pilotażowy”) - szczególnie jeśli dasz jasno do zrozumienia, że ​​porzucisz pomysł, jeśli wyniki testów są negatywne.
2. Twoje podejście do znalezienia niepotwierdzonych dowodów idealnie pasuje do pomysłu przekonania zespołu, aby spróbował. W tym celu po prostu przeszukałem w sieci coś takiego jak „Historia sukcesu napędzanego zachowaniem” i wybrałem to, co jest dla mnie łatwiejsze w użyciu.
3. Myślę, że istnieje kilka kontrargumentów, które mogą sugerować, że chęć konwersji wysiłków zespołu na BDD może być błędna.
    
   Żadne z nich nie jest szczególnie konstruktywne, szczególnie z punktu widzenia „rzecznika zmian”, ale niestety prawdopodobnie będziesz musiał poradzić sobie z dokładnie taką retoryką ( BTDTGTTS ):
    
   • nie możesz zagwarantować, że ogólna wydajność zespołu wzrośnie
   • nie możesz zagwarantować, że wysiłki włożone w przyjęcie BDD zapewnią znaczny zwrot z inwestycji
   • zespół radził sobie wystarczająco dobrze bez BDD, ryzyko zmiany obecnego podejścia nie jest uzasadnione
   • Google (lub Microsoft lub IBM - wystarczy wpisać nazwę każdego „szanowanego” dostawcy oprogramowania) radzi sobie dobrze bez BDD, co „dowodzi”, że BDD nie jest konieczne
   • podejścia inne niż BDD nie miały uczciwych szans w testach porównawczych
   • BDD może być ogólnie OK, ale dla tego i tego modułu / projektu nie ma zastosowania

Z mojego doświadczenia wynika, że ​​najmniej bolesnym sposobem odpowiedzi na argumenty przeciwne, takie jak wymienione powyżej, było przeprowadzenie ograniczonego kontrolowanego testu dla proponowanej zmiany.

Status „Ograniczone testowanie” zasadniczo unieważnia trzy z czterech powyższych argumentów, z wyjątkiem jednego o „szanowanym dostawcy”, któremu można by przeciwdziałać, dostarczając niepotwierdzone dowody sukcesu (niepotwierdzone dowody prawdopodobnie nie będą działać na „wielką zmianę”, ale na ograniczone testy są wystarczająco dobre).

Jeśli zmiana jest naprawdę opłacalna, a przebieg testowy jest odpowiednio ułożony, zauważysz pozytywne zmiany w podejściu do zespołu i kierownictwa, dzięki czemu przejście do zmiany na pełną skalę będzie płynne i bezbolesne.

Kolejną zaletą ograniczonego uruchomienia testowego jest to, że pozwala on wyjaśnić i dostosować szczegóły procesu docelowego bez powodowania zbyt dużych problemów i przy mniejszym ryzyku „utraty reputacji” pomysłu. Za każdym razem, gdy brałem udział w takich testach , byłem mile zaskoczony, gdy dowiedziałem się, jak płynnie było przejść na adopcję na pełną skalę, mając najważniejsze szczegóły określone i wyjaśnione podczas testu.

Może być czas na rekrutację kierownictwa. Jeśli próbowałeś i zobaczyłeś solidne wyniki, ale zespół się nie zgadza, kierownictwo może być zaangażowane.

Jest to szczególnie prawdziwe, jeśli krzywdzą najbardziej produktywnego członka zespołu firmy. Przygotuj się na luz. Możesz zacząć od skontaktowania się z zarządem i starania się, aby zespół przestał cię podcinać, wyjmując twoje przypadki testowe.